バイアスを取り除いて爆速でプロトタイプ検証したい〜プロトタイプを切り離して、UIパズルテストしてもらった
「一度作成したプロトタイプに固執して壊せない。」
「途中経過のプロトタイプを見せると完成図として意見が出てしまう。」
プロトタイプの検証にはいくつかの罠があるように思います。
プロトタイプをいち早く作ることで、ローコストかつ早い段階でより具体的な議論ができるメリットがあります。一方で完成度の高いプロトタイプを作るとそれに固執されてしまうデメリットもあるとも思います。
抽象度の高いプロトタイプとしては、手書きのプロトタイプを代表していくつかありますが、今回抽象度を下げてイメージがしやすい状態でバイアスを取り除けないものかと考え、プロトタイプを切り離してユーザテストを実施してみました。
UIパズルを使ったユーザーテストの流れ
テスト前に通常通り業務ヒアリングする
まずはBtoB領域のサービスであるため、どのようなチームでどのような業務を行っているかの業務フローをヒアリングしていきました。また、サービス利用者の中からリクルーティングしたため、現状どのようにサービスを活用しているのかヒアリングしていきました。
事前にターゲットを定めて対象者をリクルーティングしていますが、この役割だからこの要素が欲しい、というのを関連づけるためにも大事なプロセスと考えています。
また私自身がテスト実施時の発話の解像度をあげるためでもあり、テスト対象者がテスト実施時に具体業務を踏まえて実施できるためでもありました。
UIパズルの概要を説明する
UIパズルを実施する前に、テスト対象者には事前にヒアリングした業務に準えてテストしていただきたい旨をお伝えしました。また、パズルの要素については軽く概要をを共有しました。
UIパズルの実施
UIパズルの要素の中から、気になったものを手に取り「どのような時に欲しい情報なのか」「なぜ欲しいのか」などを発話しながら要素を組み立ててもらいました。
実際に出来上がったものがこちら。
欲しい要素から順に次々とパズルの要素が配置されていきました。すぐに手に取るものから、少し考えて配置するものもありました。
また、テスト中に対話していると事前に用意した要素では足りない要素がありました。その要素については、事前に用意していた白紙にペンで直接描いて、追加要素として配置しました。
Do / Don't
UIパズルを使ってユーザーテストをする上で、気をつけていたことがあります。
Do
具体的な業務を想定して実施してもらうこと
出来上がったパズルそのものより、パズルを配置した時の発話に着目する
Don't
完成したパズル自体を最終形態と考える
要素の「必要/不要」に囚われる
ある程度デザインを作成しているため、要素の見栄えや形によって左右されてしまうことも想定されます。そのため、完成したものに固執せずあくまでプロトタイプがない場合よりも解像度の高い発話として扱うことにしました。
UIパズルを活用してよかったこと
要素の優先度がわかった
UIデザインをする上で、要素の優先度はとても重要です。UIパズルを実施すると、UI要素ピースの中から「これはまさに欲しいですね」と言って手を取ったもの、最後に空いたスペースを埋めるがごとく手を取ったものでは優先度が大きく違うことを認識することができました。
全体図でなく要素として発話されるため、同時に複数の要素を検証できた
プロトタイプを見せると一枚絵のような状態であるため、複数の要素を作った時に要素単体の評価ではなく全体の評価になっていたなと今回UIパズルテストを実施してみて気付かされました。
UI要素ピース一つひとつに対して発話が得られたため、作成したUIに対して個別でユースケースと優先度をヒアリングすることができたと思います。
思い切りプロトタイプを壊せた
これが一番大きな収穫だったと思います。冒頭で書きましたが。UIは壊すほど良いものに近づくと思っているものの、私自身一度作成ver.1プロトタイプに抜けだしづらくなっていました。
過去にプロトタイプをユーザーに見せて検証したことがありますが、作成したプロトタイプをそのまま見せると、それが作成途中であっても見た目の良し悪しで印象が左右されてしまうことがありました。できるだけ左右されないように業務フローのヒアリングに時間を割いて最後に補足でプロトタイプを見せたりしていましたが、バイアスを取り除くにはスキルや慣れが必要だなと難しさを感じていました。
そのため、UIパズルを用意したことで優先度と要素ごとの利用シーンに集中でき、ver1プロトタイプを思い切り壊すことができたと思います。
この記事が気に入ったらサポートをしてみませんか?