More than 5 years have passed since last update.

エンジニアによるエンジニアのための UX デザイン開発実践ガイド検証編

Last updated at 2018-08-02Posted at 2018-08-02

検証

要点

この段階は、プロトタイプが自分たちの仮説通りに理解してもらえるか、または使ってもらえるかを検証する段階です。

実際に、自分たちのソリューションが正しいのかをユーザーにインタビューしてテストします。

この段階はエンジニアの仕事で言うと、テストを書いている段階です。
テストは UXD の改善のサイクルを回す上でとても重要な位置づけをされています。基本的にこの段階の結果から、修正箇所を発見して該当のプロセスに立ち返るというのを繰り返します。
エンジニアもテストを書かないままサービスをリリースすることは無いと思います。 UXD でもその考えは踏襲されています。

しかし、上品なエンジニアはテストを書いてからコードを書くと思いますが、 UXD はプロトタイプを作ってから常にテストします。何もない状態でユーザーにインタビューしてテストしても、ユーザーはイメージがつかないことが理由です。
UXD ではユーザーに、使っている「時間」や「空間」を想起するようなテストを行います。文字だけだと、辻褄が合わないこともなんとなく理解されてしまいますが、ビジュアル化してストーリーと一緒にテストするとより具体的でリアルなフィードバックが得られます。

用意するものは「インタビューガイド」と、「プロトタイプ」です。ここで言う「プロトタイプ」は、「製作」の段階のプロトタイピングで作ったアウトプットです。
テストを行う前にこの「検証」の段階で、「何を検証したいのか」と「プロトタイプがキャンバスの MVP を満たしているのか」をテストする前に確認して下さい。ここがおざなりになっていると、改善のサイクルに立ち返る時に困ります。

少し話が変わりますが、一回目からユーザーに刺さるサービスを作れたら苦労はしないです。
価値マップ、ペルソナ、 CJM 、キャンバス、全てが後でまた作り直す想定で、この「検証」までスピーディーに進めたほうが良いと思います。結局のところ、どんなに時間をかけて、どんなに精緻に作っても、詳細のモデリングや仮説が間違っていたらやり直しになります。ならば、ここの段階までなるべく早くで進めて、実際に自分たちの考えをユーザーに確認するサイクルを回すほうが、結局確度が高いものになりやすいと思います。
リーン開発の重要なところですが、「失敗から多くを学び、改善する」を繰り返します。その際に、改善するのは、調査からやり直すかもしれないし、ユーザーモデリング、サービス設計をやり直しすかもしれないです。

UXD ではユーザーからのフィードバックで適切なプロセスに立ち返る必要あるのです。

この章の残りは下記の点を詳細に書きます。

テスト設計
インタビューガイド
フィードバック

テスト設計

ユーザーテストはユーザーをテストするのではなく、ユーザーにテストしてもらうテストです。（ココ重要！）
ユーザーは特殊な状況に置かれて、いつも以上に負荷がかかっていることを認識しないといけません。なので、その負荷を取り除くために最善を尽くすように配慮します。一方で、テストするための前提条件の説明は丁寧にインプットします。ユーザーに利用状況を想像してもらいながら、使ってもらうことが重要です。

テストの具体的な話をする前に、まずはテストするに当たっての目的をしっかり定義することをおすすめします。
タスク設計をしていく際に目的が無いとタスクの優先順位を付けることができないし、そもそもタスクのスコープを切ることもできません。いきなり全部使ってもらって理解度を試すのではなく、テストの目的沿った部分を確実にテストするようにしましょう。このことにより、ユーザーの想定外の行動に対して、臨機応変に記録と質問の取捨選択ができるようになると思います。

また、テストの人数はリソース次第ですが、だいたい4~5人です。
統計的に4~5人で、ユーザーから得られる80％の意見が集まると言われています。無闇にテストするユーザーを増やすのではなく、4~5人のテストをした後に、改善してまた4~5人のテストをした方が早いし正確です。

エキスパートレビュー（ER）

ユーザーで実際にテストする前に、エキスパートレビュー（ER）をします。
ER とは、社内やチーム内でプロトタイプの問題点の洗い出しをすることです。この段階は、プロトタイプを作ったチーム外からも協力をしてもらって、なるべくプロトタイプを客観的に見るようにする必要があります。

そして、自分たちで使ってみて「分かりにくい」、「難しい」、「使いにくい」、「気づかない」、「読みにくい」などの問題点をブレストしていきます。
ストーリーボードなどの ER は「ここ本当にこう感じるの？」みたいなコンセプトの是非を問うようなブレストをします。

そのブレストした中で、明らかに問題なものは改善に回し、ユーザーに使ってもらって判断したいものピックアップします。

ここで上がった問題点をベースにユーザーテストのタスク設計をおこないます。

タスク設計

ユーザーテストの結果自体はユーザーインタビューと違い、具体的で端的なものになるように設計する必要があります。
そのことにより、ユーザーの発言録と ER でた問題点の関連を探りやすくできます。

なので、定量的に計れるようにタスク設計と検証軸が必要であります。
ただ、コンセプトレベルの検証では、具体的な検証軸を設定できないので、課題の有無やユーザーの共感度を詳細に深掘りしていきます。また、検証するものが実際のプロダクトに近ければ近い程、より具体的な検証軸を用意します。つまり、 プロダクト > デザインモック > コンセプト の順番に具体的なタスク設計をします。
例えば下記のような軸を用いてユーザーのプロトタイプの理解度を見ます。

タスク完了までの時間
タスク完了までのページ遷移
タスク完了までのエラー数
タスク完了後のアンケート

注意が必要なのは、タスクの内容自体は定量的な判断になります。しかし、そこからの改善案のインパクトは人数が少ないので、なんとも判断がつかないものになります。
5人中1人から出た結果は、サービスにとても大きなインパクトを与える改善の可能性もありますが、ほとんどの人が気にならないような改善である可能性もあります。逆を言えば、どの結果もフラットに見る必要があります。チーム内で優先順位を決めて結果の改善に努めるが重要になります。

また、リクルーティングしてユーザーテストする場合は、ユーザーとの約束の制限時間があったりします。
往々にしてユーザーは自分たちの想像を超えた行動をします。その場合、時間が約束の時間を超えそうなケースが起こると思います。その時のために、予めタスクには目的に応じて、優先順位を付けておくと良いです。そして、「最低でもここまで！」みたいなタスクを決めておいて、時間内にテストが終わるようにタスクをコントロールすると良いと思います。

観察ポイント

テスト中の観察ポイントも予め設計しておく必要があります。

テストが始まると観察者が何を観察すれば良いのか分からないということが起こります。
ユーザーは色々喋ったり、手を動かしたり、黙り込んでしまったりします。これらの全てを観察するのはほぼ無理だと思います。

特に初めての頃は、タスク設計で設定した評価軸ばかりに目がいってしまい、大切なユーザーのリアクションを見逃しやすいです。
具体的には「何もできなくて詰まっている」や、「悩んでいる」などのリアクションが操作中のどこで起こったのかしっかり記録していれば改善点が見つけやすいです。
なので、 ER の段階でユーザーの起こすだろうリアクションに対して、観察ポイントを設定しておくことはとても有用となります。予め想定されるリアクションは全てチェックリストにして観察時に、何を見れば良いのかはっきりさせておくと良いと思います。それでも、想定外のリアクションが来たら、観察者が目的に準じて取捨選択するようにすると良いと思います。

また、ちゃんとしたテストになると録画ビデオなどを設定しますが、見返すことはほとんどありません。（保証します。笑）
なぜなら、1回が30分あるし、全員が集まって見直す機会などないです。

テストが終わったらすぐにメンバーで集まって、タスク結果と観察ポイントの共有をし、次の改善アクションのフィックスまでさせてしまうのがおすすめです。

インタビューガイド

インタビューはタスク設計の時とは逆で、 コンセプト > デザインモック > プロダクト の順番に精巧に準備します。
具体的な検証軸を持てない分、ここでユーザーからのフィードバックを吸い上げます。

ここで行うインタビューは「調査」の段階のインタビューとステップは同じです。インタビューガイド作って、インタビュー相手の意図や目的を探ります。
ただ、大きく違うのは、新たにニーズを探っているのではなく、自分たちの仮説を検証しているということです。インタビュー相手との場作りやインタビュー相手の情報を聞きつつも、本題は自分の課題を MVP を使って検証するところに主眼あります。

テストのためのインタビューガイドは

課題の有無
課題の切実度
ソリューションの適切度

の、順番で聞き出すようにすると良いです。
これらの項目は後にプロセスに立ち返る時の指標になります。なので、自分の仮説がどこの段階でユーザーに刺さらなかったのかを掴むことを意識して下さい。

注意が必要なのは、インタビューアーの発言です。
タスクの説明やインタビューの中でユーザーをリードしてしまうような単語や行動を用いるとテストに多大な影響を与えます。
僕が実際に行ったテストでも、サービスに表記されている単語をインタビューアーがそのままタスク説明の際に使っていしまい、タスクの完了スピードへ大きく影響を与えてしまったということがありました。
インタビューアーは多くを語りすぎてもいけません。これを防ぐためにも、予めインタビューアーが使ってはいけない禁止ワードを設定して、タスク説明のスクリプトを用意することをおすすめします。

また、この節の冒頭で述べたように、プロダクトのようにほとんど完成品に近い場合は、インタビューをしません。
しかしながら、プロダクトをユーザーが何を考えて使っているかは、改善の重要なインサイトになります。なので、何を考えて使っているかを理解するために思考発話法を利用すること多いです。

思考発話法は、ユーザーに考えていることを話してもらいながらプロトタイプを使ってもらう手法です。この方法を使って、ユーザーの意見を吸い上げて改善につなげていきます。
ただ、注意が必要なのは、思考発話法は「発話」という負荷をかけていることになります。負荷をかけてしまっている以上、普段の使い方や意見とは違う可能性があります。
こういった理由から、思考発話法を避けて、ユーザーの本来使っている様子からボトムアップ処理を考える方法とる時もあります。

ただ、最初のうちは思考発話法を使うのが簡単で分かりやすいと思います。
やらないよりやったほうが良いのは、火を見るより明らかです。また、ユーザーテストが一番学びが多いです。手法にこだわらないで、何事も実践するのが良いと思います。

フィードバック

アジャイルやリーンと同じように UXD は常にアップデートされていくものです。
なので、検証した後は適切なプロセスに立ち返って、デザイン自体にフィードバックを与えるということが必要になります。

1つ大きな指標として、自分の仮説が「課題の有無」、「課題の切実度」、「ソリューションが適切度」のどこで止まってしまったのかは明確な判断軸になりえます。
それぞれの立ち返るプロセスの対応を下記に示します。

課題の有無 -> 調査
課題の切実度 -> 分析
ソリューションの適切度 -> 製作

重要なのは、「自分のサービスは素晴らしいんだ！」みたいなバイアスを排除して、中性的に自分の仮説が良かったのか、悪かったのかを分析していくことです。

また、テスト結果をどのようにフィードバックするかは、本当にテスト次第です。
テストがインタビューがメインの場合は、「分析」の段階と同じように KJ 法を使ってユーザーモデリングをアップデートして、その後のプロセスにもアップデートを加えていく方法もあります。
また、「提供価値や正しいようだが手段が違うみたい」っていう時は「製作」の段階に立ち返ってキャンバスの課題をアップデートして、 TO_BE の CJM 書き直したりします。
そして、インタビューがほとんどなくい場合は、設定したのタスクの評価軸に照らし合わせながら UI や情報構造、リンク構造のアップデートをしたりします。

エンジニアによるエンジニアのための UX デザイン開発実践ガイド 検証編

検証

要点