ajike switch

ajike switchの更新をメールでお伝えします!

8年以上ajikeが蓄積したデザイン思考とUXデザインの知見を発信し続けるブログ<ajike switch>の更新情報を無料でメールにてお知らせ致します。

×

MVPに達していないプロダクトを使用したユーザーテストで有効な結果を出す方法〜ワイヤーフレームは検証に値するか〜

こんにちは。
ディレクターの小池です。

最近担当した案件でユーザーテストを行ったのですが、その際に弊社の神田からある指摘を受けました。
それは

「ワイヤーフレームを使ったユーザーテストで果たして有効な結果が得られるのか?」

ということです。
これの意味する所は何でしょうか?

ワイヤーフレームはMVP(Minimum Viable Product)に達していない?

MVP(Minimum Viable Product)とは・・・?
日本語に訳すと、「必要最低限の能力を兼ね備えたプロダクト」という意味になります。
開発が始まってから、プロダクトにユーザーニーズを満たす能力が無いと判明した場合修正に膨大な工数がかかるため、プロトタイプを様々な方法で検証することで戦略や仮説の精度を図ります。
特にユーザーテストは、被験者に普段利用しているようにプロダクトを触ってもらう事でインサイトを引き出す事が目的のため、検証に使うプロトタイプが「MVP」に達してるかどうかが特に重要になります。

言い回しは違いましたが、神田の言わんとしていたことはこの見出しと同じ事です。
つまり、一般ユーザーが使用する事を想定していない設計図であるワイヤーフレームは、ユーザー行動のデータを収集するためにはまだ最低限の完成度を備えていないという事です。例えば、下の図を見て下さい。

3

ワイヤーフレームはあくまで設計図なので、当然色も付いていませんし、ボタンのUIもタップし易いような配慮はされていません。
そのようなプロトタイプでユーザー行動を把握しようとしても、ユーザーは普段使うような行動をスムーズに行えないため、観察する価値がある行動を見せてはくれないのではないか?という所が、ワイヤーフレームを使用したユーザーテストの効果に懐疑的な意見が出て来る原因だと思います。
確かに、ワイヤーフレームはMVPに達しているとは言えませんので、実際のユーザーを想定したデータのすべてを集める事は難しいです。

それでもワイヤーフレームでユーザーテストがやりたい理由

前の項ではワイヤーフレームでのユーザーテストの効果があまり期待出来ないという事を書きましたが、それでもどうにかワイヤーフレームの段階でユーザーテストを行いたい理由があります。
それは、デザインが出来た段階で初めてユーザーテストを行い、発見された課題が大きかった場合デザインを修正するのが大変だからです。ワイヤーフレームの段階でクリティカルな課題が発見出来ていれば、修正にかかるデザイン工数を削減できますし、デザイン完成後のユーザーテストで更に有効なデータを集める事が出来ます。

MVPに達していないプロダクト=工事中の店舗

MVPに達していないプロトタイプで検証が上手く行かない理由を工事中の店舗に例えてみましょう。

【例】

検証したいこと

・会計の場所は適切か

・ニーズが高い商品を目立つ位置に設置できているか

タスク

・欲しい商品を1つ選んで会計まで進む

2

MVPに達していないという事は前提として、

・所々工事中のエリアがある

・道がきちんと整形されていない

・陳列のわかりやすさをアップさせるための工夫はまだされていない

ということです。
当然、テストの途中にタスクを実行してゴールまで達する方法は歩く人によって違いますから、ほとんどの道が出来ていない状態で「歩き方のパターン」をすべて検証することは出来ませんし、それありきで被験者にタスク設定してしまうと、工事中のエリアに知らずに足を踏み入れて混乱するということにもなりかねません。

上記を踏まえて大事なのは、

1.工事中のエリアは歩かないように指示を出す

2.装飾がまだ無いので、「部屋の雰囲気」や「視覚的なわかりやすさ」は検証しない

3.プロダクトの完成度が引き起こすユーザーの混乱は事前に予想する

4.完成度に応じたタスクを被験者に設定する

の3つです。
検証する対象がまだ未完成であるため、あらかじめ検証する項目や範囲を決めておく必要があります。
例えば、「色分けがされていないために商品の位置がわからず混乱した」という課題が出た場合は前提として検証対象外という事になります。

これを踏まえて、課題を改善施策として実行します。

1

課題を3段階に分類する

前項では、
「MVPに達していないプロトタイプでユーザーテストをする場合は検証することとしないことをあらかじめ決めておく」

ということを例を取り上げて説明しました。
その後の流れとしては、発見された課題をどのセクションから見直すかをあらかじめ設定することです。

私がワイヤーフレームでユーザーテストで行った課題の分類は下記の通りです。

1.ユーザー行動仮説の課題
【課題の例】
・ユーザーのインサイトが仮説と違った
・トップページにランディングすると予想していたが、実は記事詳細からの回遊がメインだった

2.情報設計の課題
【課題の例】
・スクロールで情報取得すると予想していたが、スクロールされなかった
・ナビゲーションから遷移すると予想していたが、ほとんど利用されなかった

3.デザイン課題
【課題の例】
・ボタンが目立たなくて気づかれなかった
・色が地味でコンテンツをもっと見たいというモチベーションが湧かなかった

1の課題が発見された場合は、ジャーニーマップやギャップ分析の資料を修正し、必要な機能を定義します。
2の課題が発見された場合は、WFを修正しユーザー行動を阻害している要因を改善します。
3の課題は、ワイヤーフレームでは検証できません。しかしもし発見、予測された場合はデザイン制作前の成果物(クリエイティブブリーフ)に反映します。

クリエイティブブリーフとは?

プロジェクトのゴールからズレないように、チーム全体で共通認識を持つために制作するドキュメント

compass_desig

関連記事:http://www.ajike.co.jp/switch/creativebrief/

 

このように、課題の種類によってどこのセクションで修正を加えるかをあらかじめ決めておく事で、「プロダクトの完成度が不足している事が原因で出てきた課題」を修正内容から除外することが可能になります。

まとめ

いかがでしたでしょうか?
ユーザーテストは、小規模なものでもプロダクトの課題発見に絶大な効果があり、早く行えば行う程後のセクションでの修正工数増加を防止する事ができます。
しかし、MVPに達していないプロトタイプでは満足な検証内容を得られないというジレンマもあります。
今回は、ワイヤーフレームを使用したユーザーテストでも一定の効果を得るために気をつけるべきポイントをご紹介しました。

1.検証することとしないことを、プロダクトの完成度に応じてあらかじめ決めておく

2.プロダクトの完成度に応じて、被験者に与えるタスクの具体度をコントロールする

3.発見された課題をどのセクションで解決するかをあらかじめ定義しておく

これらに気をつけてユーザーテストに臨む事によって、完成度が不足したプロトタイプでも一定の検証効果が期待できます。
上手く行けば、その後のデザインフェーズにおいて出て来る課題を、すべてではないにしろワイヤーフレームの時点で潰しておく事も可能ではないでしょうか。

それではまたお会いしましょう。

servi