UX調査早見表
ユーザー調査はデザインサイクルのどの時点でも実施できる。この手法と活動のリストは、どれをいつ行うかを決めるのに役立つ。
ユーザーエクスペリエンス調査という手法は、データと知見を生み出すのに優れている。また、UXの活動を継続的に行うことで正しいことを実現できるようになる。研究開発と並行して、UXの活動を継続していくことで、チームの努力がより効果的で価値のあるものになるのだ。一方、デザインプロセスのどの段階であれ、さまざまなUX手法を使うことで、製品開発の取り組みを正しい方向に進め、想像上のニーズではなく、真のユーザーニーズに一致させることができる。
我々が最も多く受ける質問の1つに、「自分たちのプロジェクトでいつユーザー調査を行うべきか」というのがあるが、これには3つの答えがある：
- 今現在がどの段階であれ、ユーザー調査を実施すればよい。調査は早ければ早いほど、結果が製品に与える影響は大きいし、（タイムマシンがない限り）進行中のプロジェクトに対して何かできる最短の日というのは今日だからだ。
- すべての段階でユーザー調査を実施すればよい。以下に示すように、プロジェクト計画がどんなに合理的なものであっても、各段階で学ぶべき有益なことはあるし、調査のステップを一つ一つ踏んでいくことで、調査にかけたコスト以上に製品の価値が高まるからだ。
- （最も大きな影響を与えられる）プロジェクトの初期にほとんどのユーザー調査を実施するが、プロジェクトの後半にもちょっとした補足調査を行えるように予算を確保しておく。このアドバイスは有用と思われる調査ステップの予算をすべては確保できないというよくあるケースに適用される。
以下の図表は、プロジェクトのさまざまな段階で利用できるUXの手法とUX活動を示したものである。
プロジェクトはそれぞれ異なるため、段階は必ずしもきっちり区分けできるわけではないが、あるサイクルが終わると、次のサイクルが始まるということになる。
重要なことは、膨大な活動リストを厳密な順番で実行するのではなく、このどこかから始めて、学びながらどんどん進んでいくことだ。
UX調査手法
| 発見 |
|
|---|---|
| 探索 |
|
| テスト |
|
| 耳を澄ます |
|
どこから始めるか、あるいはまず何に最初に焦点を合わせるとよいのかを決める際は、これらの主なUX手法から選ぶといいだろう。時間の制約やシステムの成熟度、製品やサービスの種類、現在の最大の懸念事項によって、他の手法より適切な手法もある。製品サイクルごとに異なる手法を用いたり、交互に用いたりするとよい。手法によって目指す目標も知見の種類も違うからだ。以下のグラフは、UX関連のキャリアに関するアンケート調査で、UX実践者がこれらの手法をどのくらいの頻度で利用しているかについての回答内容である。
UXに関する活動を1つしか実施できず、既存のシステムの改善を目指す場合は、（思考発話法を用いる）定性的なユーザビリティテストを実施するとよい。これがユーザビリティの改善に最も効果的な方法である。ユーザーによるテストができない場合は、できるだけ多くのユーザーデータを分析しよう。しかしながら、（たとえば、営業やサポートセンターの通話履歴や検索、アナリティクス分析から取得した）データは、ユーザーの代わりにはならない。なぜなら、データは通常、「何が」というのは教えてくれるが、多くの場合、知る必要があるのは「なぜか」だからだ。その場合は、データから得られた疑問を活用して、ユーザビリティテストの実施の必要性を主張しつづけよう。
発見
発見の段階は、知らなかったことを明らかにし、ユーザーが何を必要としているかをよりよく理解しようとする期間である。特に新しい製品や機能を作る前には、発見のための活動を行うことが重要だ。この活動によってそのプロジェクトを行うことに意味があるのかどうかを見極めることができるからだ。
この段階での重要な目標は、思いついた仮説を検証して取捨選択すること、そして、データと知見をチームにもたらすことである。この調査は、間違ったものを作ってしまったり、間違った対象ユーザーのために何かを作ってしまって、労力を無駄にする前に実施するのが理想だが、既存の製品やサービスを担当中の場合は軌道修正のためにも利用可能だ。
発見の段階でやっておくとよいこと：
- フィールド調査を実施し、ユーザーにインタビューする。ユーザーがいる場所に行って、彼らを観察し、質問し、話を聞こう。ユーザーがシステムとインタラクトしたり、あなた方が解決策を提供しようとしている問題を解決しようとしているところを観察するとよい。
- 日記調査を実施して、ユーザーの情報ニーズと行動を把握する。
- ステークホルダーにインタビューして、ビジネス要件と制約条件を収集・把握する。
- 営業やサポート、トレーニングの担当者にインタビューする。ユーザーから最もよく聞く問題や質問はどういうものか。ユーザーが抱える最悪の問題とは何か。どんなことにユーザーは怒っているのか。
- 営業やサポートの電話を聞く。ユーザーは、何について質問してくるのか。何を理解するのに問題があるのか。営業やサポートの担当者は、どのように説明し、手助けしているのか。ユーザーと担当者の間で食い違いのある語彙はどういうものか。
- 競合テストを実施する。競合製品の長所と短所を見つけ、ユーザーが最も好むものを発見しよう。
探索
探索の手法は、問題空間とデザイン範囲を把握して、ユーザーのニーズに適切に対応するためのものである。
- 競合他社と機能を比較する。
- デザインレビューを行う。
- 調査をもとにユーザーペルソナを構築し、ユーザーストーリーを作成する。
- ユーザーのタスクを分析して、ユーザーの時間と手間を節約する方法を見つける。
- ステークホルダーにユーザージャーニーと途中で顧客を失う危険性のある領域を示し、理想的なユーザージャーニーがどのようなものなのかを一緒に判断する。
- さまざまなアプローチを想像し、ブレインストーミングを行い、最も良いアイデアをテストすることで、デザインの可能性を探り、ずっと残しておきたい選り抜きのデザインコンポーネントを特定する。
- ステークホルダーや対象分野の専門家とデザインのウォークスルーを行い、初期段階のタスクフローに関するフィードバックを受ける。回答や質問を書面でもらうことで（サイレントブレインストーミング）、集団思考を避け、グループでは声を上げないかもしれないメンバーも自分の懸念事項を話せるようにするとよい。
- ペーパープロトタイプをターゲットユーザーでテストすることでデザインを反復する。そして、ユーザーがそれを使用するのを観察することでインタラクティブなプロトタイプをテストする。意見を集める必要はない。その代わりに、ユーザーがタスクを完了し、エラーを回避するために、デザインがどのように役立っているかに注目しよう。問題のある領域をユーザーに示してもらったところで、デザイン変更をして、再度テストしよう。
- カードソーティングをして、ユーザーの情報の分類の仕方を調べ、ナビゲーションや情報の整理スキームに役立てる。
テスト
テストや検証という手法は、開発中やそれ以降のデザインのチェックをして、システムがそれを利用するユーザーにとってうまく機能するかどうかを確認するためのものだ。
- 定性的なユーザビリティテストを実施する。１人ずつでもグループでも、さまざまなユーザーを対象に早期に、そして頻繁にテストをしよう。ユニバーサルアクセスを確保するためのアクセシビリティ評価も実施しよう。
- 日記調査などで、長期にわたってシステムを使用している間のインタラクションや興味深い出来事などをユーザーに自己申告してもらう。
- トレーニングクラスを聴講し、トピックやユーザーが尋ねる質問、その回答を記録する。説明書とヘルプシステムのテストを行う。
- ユーザーグループと話す。
- ソーシャルメディアアカウントのスタッフになり、オンラインでユーザーと対話する。称賛や苦情がないか、ソーシャルメディアをモニタリングする。
- ユーザーフォーラムの投稿を分析する。ユーザーフォーラムは、対処すべき重要な問題や問題を解決する回答の情報源になる。そこで学んだことはデザインや開発のチームに持ち帰ろう。
- ベンチマークテストを実施する。大規模なデザイン変更や改善の測定を計画している場合は、現在のシステムのタスク時間やタスクの完了率、エラー率を判断するためのテストも行い、時間の経過に伴う進歩を測定できるようにしておこう。
耳を澄ます
調査とデザインのサイクル全体を通して、既存の問題を理解し、新しい問題を探すために、耳を澄まそう。収集したデータを分析し、入ってきた情報にパターンや傾向がないか、モニタリングしよう。
- 顧客や見込みユーザーにアンケートを実施する。
- アナリティクスと指標をモニタリングして、傾向や異常を発見し、進捗状況を把握する。
- 検索キーワードを分析する。ユーザーは何を探し、それを何と呼んでいるのか。検索ログは見落とされがちだが、そこには重要な情報が含まれている。
- コメントやバグレポート、質問を送信しやすくする。送られてくるフィードバックチャネルを定期的に分析して、ユーザビリティに関する主な問題や問題領域を確認しよう。ユーザーが見つけることができないものや誤解していること、意図しない影響についての手がかりを探そう。
- よくある質問を収集し、それらによって示された問題の解決に努める。
- 顧客やユーザーが参加するカンファレンスにブースを出展し、彼らから情報を自発的に提供してもらったり、話を直接聞いたりできるようにする。
- 講演やデモを行う。そこでユーザーの質問や懸念を把握しよう。
UX活動
発見
UXに関する活動を継続的かつ戦略的に行うことで、問題が先取りでき、体系的な改善が可能になる。
- 味方を見つける。デザインを改善するには、組織的な取り組みが要る。それには協力者と擁護者が必要だ。
- 専門家と話をする。他の人の成功と失敗から学び、経験豊かな人からアドバイスを得よう。
- 倫理ガイドラインに従う。UXPAのプロフェッショナル行動規範は、良い出発点になる。
- ステークホルダーを巻き込む。意見を求めるだけではなく、ちょっとしたことでもよいので参加してもらい、貢献してもらおう。調査結果を共有しよう。また、調査セッションを観察し、メモを取ってみないかと誘おう。
- データソースを探す。UXの探偵になろう。必要な情報をもっているのは誰か。そして、それはどうやったら集められるか。
- UX指標を決定する。システムがユーザーに対してどの程度有効であるかを測定する方法を見つけよう。
探索
- Togのインタラクションデザインの原則に従う。
- 特に自社で調査を実施できない場合は、根拠に基づいたデザインガイドラインを使用する。ユーザビリティヒューリスティックスは、従うべき全体的な原則である。
- ユニバーサルアクセスに配慮したデザインをする。アクセシビリティを最後に付け加えたり、QA中にテストしたりしてはならない。利用の権利は法律で義務づけられつつあるし、この分野の専門家の助けを借りることもできる。アクセシビリティを向上させると、システムがすべての人にとって使いやすくなる。
- ユーザーがコントロールできるようにする。ユーザーが自分の必要とすることをコントロールできるようにしよう。とはいえ、選択できるようにはするが、無限に選べるようにするわけではない。
- エラーを防止する。エラーが発生したら、そのエラーをデザイン変更によってどのように解消できるかを検討しよう。ユーザーエラーのように見えるものもシステムのデザインの不具合であることがよくある。エラーの発生メカニズムを理解することでエラーを防止し、その影響を軽減するようなデザインをしよう。
- エラーメッセージを改善する。残ったエラーについても、システムの状態を伝えるだけで済ませてはならない。ユーザーの立場に立って何が起こったのかを述べ、どうすべきなのかをユーザーが理解しやすい言葉で説明しよう。
- 役に立つデフォルトを提供する。多くの人は難しい選択はあなたがやってくれるものと期待しているので、デフォルト設定で規定しておこう。ユーザーによって変更の必要がありそうなもの、彼らが変更したいと思いそうなものを変更できるようにしておけばよい。
- 一貫性に欠けるデザインがないか確認する。学習しやすさには、同じように機能する、ということが重要だ。ユーザーは違いを意味のあるものとして解釈しがちなので、恣意的に変えるのではなく、意図的にそれをデザインに生かそう。驚き最小の原則に従おう。驚かすのではなく、期待に応える必要がある。（訳注：驚き最小の原則とは、UIなどのデザインにおいて、システムの構成要素はユーザーを驚かせたりせず、ほとんどのユーザーが期待するような動作をすべきである、という考え方）
- 機能をニーズに対応させる。ユーザー調査を機能と対応づけておき、それぞれのデザイン要件がなぜできたのかをわかるようにしておくとよい。このように対応させておけば、次回の調査や次のチームのためにデザインの根拠を残しておくことができる。
- ソフトウェアをデザインする際には、インストールとアップデートが容易であることを確認する。インストールは迅速にさりげなくできるようにしておこう。ユーザーが必要に応じてアップデートをコントロールできるようにしておくとよい。
- デバイスをデザインする際には、修理やリサイクルに備える。持続可能性と再利用がかつてないほど重要になってきている。大事に使われることを想定したデザインをしよう。
- 無駄を省く。必要のない包装や使い捨ての部品を減らし、排除しよう。また、ユーザーの時間も無駄にしてはならない。無駄をなくして合理化することだ。
- システムのさまざまな文化的背景におけるユーザビリティを考慮する。あなた方はユーザーではない。システムが他の国のユーザーに対しても確実に機能するデザインを考えよう。翻訳はこの課題の一部を解決するにすぎない。
- 逆インセンティブを探す。逆インセンティブは、意図しない負の結果につながる。そのシステムはどのように操作できたり、悪用したりできそうか。それにどう対処することができるだろうか。悪意のあるユーザーが意図していなかった方法でシステムを使用したり、システムを使って他のユーザーに危害を加えたりする可能性を考慮する必要がある。
- 社会的な影響を考慮する。このシステムは、ユーザーの集団の中で、ユーザーの集団によって、あるいはユーザーの集団に対して、どのように使われるのだろうか。集団のそうした活動によってどのような問題が出てくる可能性があるか。
テスト
- 個人情報を保護する。個人情報とはお金のようなものだ。何も考えずに使っていいのは一度だけだし、銀行を襲ってみたいと思っている人はたくさんいる。個人情報を長期にわたって安全に保つ方法を考えよう。必要のない情報は収集しないようにし、古いデータは定期的に破棄する必要がある。
- データを安全に守る。調査データと顧客から会社に委託されたデータの両方へのアクセスを制限する必要がある。保存データを暗号化し、安全に転送できるようにすることを主張しよう。データの漏洩は、最悪のユーザーエクスペリエンスといえる。
- 良いことも悪いことも伝える。聞きたくないことは言いたくないのが人間のさがだが、UXテストでは厳しい問題を提起することが重要だ。あなたが知っていることや疑っていることを意思決定者が知るかどうかに、製品、さらに会社の将来まで左右されるかもしれない。
- ユーザビリティを経時的に追跡する。サポートに問い合わせのあった問題の数と種類、ユーザビリティテストでのエラー率とタスクの完了率、顧客満足度などの指標を使用して、デザインを改善したことによる効果を示そう。
- 多様なユーザーに参加してもらう。ユーザーはそれぞれ、文化的、身体的に大きな違いがある可能性もある。また、能力や言語のスキルもさまざまだ。ペルソナだけでは深刻な問題を防ぐのには不十分だ。そのため、テストにはできるだけ多様なユーザーに参加してもらおう。
- ユーザビリティのバグを追跡する。ユーザビリティのバグがバグデータベースにない場合は、独自のデータベースを立ち上げ、重要な問題を追跡するべきだ。
耳を澄ます
- ユーザーの感情に注目する。ソーシャルメディアは、ユーザーの問題や成功、不満、口コミ広告のモニタリングに最適な場所だ。ソーシャルメディアの投稿から、初めて競合他社の出現がわかることもある。
- トレーニングの必要性を減らす。トレーニングは、多くの場合、わかりにくいユーザーインターフェイスにとって次善の策になるわけだが、費用がかかる。トレーニングやヘルプのトピックを使って、デザイン変更をしたほうがよい領域を探そう。
- 将来の方向性を伝える。顧客やユーザーは、自分ができることと、使用している製品やサービスをどう扱えばいいのかを知っているかに依存している。変更というのは、たとえ破壊的なものであっても良いことである場合もある。しかし、驚くような変更は、ユーザーがすでにやっていることを駄目にしてしまう可能性があるため、不評なことが多い。可能な限り、顧客やユーザーに対して、変更について質問し、伝え、テストをし、彼らの声に耳を傾けよう。単に変更を発表するのではなく、彼らに相談することだ。大きな変更については早めに意見を交わすとよい。ユーザーから聞いたことを活かせばもっとうまくやれるようになるし、ユーザーも自分たちが知ったことによって必要な変化に備えることができる。
- 将来の調査とテストのために参加者を募集する。調査パネルに登録してもらえるようにユーザーに積極的に働きかけよう。参加のインセンティブを提示し、Webサイトやニュースレターなどの連絡先を介して、彼らが気軽に申込みできるようにしておこう。
結論
この早見表を活用して、プロジェクトに適したUXの手法と活動を選び、その成果を最大限に引き出してほしい。すべてのプロジェクトであらゆる選択肢を実行する必要はないが、多くの場合、複数の手法を組み合わせて利用し、反復のたびに継続的なニーズに対応していくことが有効だろう。
関連記事：ユーザーエクスペリエンス調査、どの手法をいつ使うべきか
