2016.3.10 / UX

UXデザインのためのユーザー調査・評価手法の選び方とは

Tomohiro Suzuki

ニールセン博士のユーザー調査のないUXは、UXではない(原文:UX Without User Research Is Not UX)の記事は、読んだことがある方も多いのではないでしょうか。
もちろんユーザー調査などは当たり前のようにやっているサービスもある一方、長年運営していても調査自体を行ったことのないサービスもあるようです。
適切なユーザー調査を行っていないと、新しい施策を考える際にも開発メンバーの思い込みだけで開発が進んでしまい、リリースしたのに誰にも利用されなかったということになりがちです。
また、調査をしていても施策を実施した後に適切な評価を行っていなければ、何が正しくて何が間違っていたかが学べないため次のPDCAには進めず、組織としてのナレッジも蓄積されません。

STANDARDでもUXデザインのご依頼を頂く場合には、基本的にはユーザー調査によりそもそものユーザーの課題はあるかや、ユーザーへの理解を得た上でのUXデザインをご提案させて頂いてます。
例えば調査によりユーザーの利用状況を明示し、その課題を解決する場合の理想の体験を定義したものをベースにサービス全体の設計を行うことで、リリース後に理想の体験とのギャップを分析したり、ビジネス貢献への価値を検証することができます。
逆にユーザー調査がなく、デザイナーもユーザーと全く違う属性の場合にはユーザー理解が不足しているため、適切な体験は設計できません。

しかし、調査の工数をカットして、いきなりサービスを作ってから仮説を検証したほうが早いケースも確かにあります。
ただしそれには、エキスパートな開発メンバーがいる場合や、本当に最小限のMVPまでを考えこまれているような場合、またはチャレンジャーの差別化を無くすための同質化戦略を行う場合などの前提が必要です。
それ以外のケースでは事前にそのサービスが成立する前提となるニーズがあるかを調査することにより、開発してから誰も使わなかったというリスクを最小化することができますし、後の検証も考えると効率的です。
では、適切な学びを得てサービスに活かすためには、どのような時にどのようなユーザー調査・評価手法を使えばいいのでしょうか?
今回の記事ではユーザー調査・評価の必要性や手法を判断するための軸についてご紹介していきます。

※ 調査手法の詳細について触れるものではないため、詳しく知りたい人や今回ご紹介した以外の手法に興味がある方はResearch & Design Method Index -リサーチデザイン、新・100の法則などを参考にしてください。

1.対象は何か

あなたの調査する対象はユーザーでしょうか、それともサービスでしょうか。
次の問について考えてみてください。

「我々の解決策(企画・サービス)が成り立つ前提はなんだろうか」

既にサービスが世に出ているのであれば、対象はハッキリしているように感じるかもしれません。
しかし、例えばリリースしてみたはいいものの、思うようにサービスが利用されない場合には、ユーザーとサービスのどちらから調べるべきかの判断はなかなか難しいものです。
いきなりユーザビリティテスト等で解決策であるサービス側についての課題を把握することも良いかもしれませんが、その前提として当初想定していたとおりのユーザーが使っているか把握できているでしょうか。
実際にリリースしてみたものの、想定とは違うユーザーが利用していることはよくあることですし、ユーザーが同じであっても想定とは違う課題の解決に使っていることもあります。
会員制のサービスであれば定量分析により属性を調べても良いでしょうし、またはユーザーミートアップを何度か開催して当初の想定と同じ課題を持つユーザーかどうかを判断するのもいいかもしれません。
早くサービスを改善したい気持ちもあるかもしれませんが、まずは自分達のサービスのユーザーや課題を明確に理解しない限り、今後調査をしていくにあたってのユーザーのリクルーティングや、解決策の評価自体が正しく行えず、組織の学習が進みません。

既にユーザーと課題が明確になっていてサービスを調べる場合であっても、解決策自体の評価なのか、UIの評価なのかを見極めることが大切です。
例えば実際にサービスのコアとなるXXXという体験を行ったユーザーは1週間以内に70%がリピートするサービスであれば、解決策自体は確度が高いと判断し、そこに至るまでのユーザビリティを評価し、改善していくという方法が考えられるでしょう。
しかし、上記の数値を置き換えて、コアとなるXXXという体験を行ったユーザーでも1週間以内のリピート率が10%などであれば、ユーザビリティなどではなく、コアとなる体験自体を見直すための調査が必要になるでしょう。

2.顕在的か潜在的か

1.の調査の対象にも繋がりますが、ユーザーを理解する必要があると判断できた場合でも、どの程度理解しているかによって調査手法も変わってきます。

「我々のサービスのユーザーについてどれくらい語ることができるだろう」

この問に対して答えられない、または曖昧にしか答えられないようであれば、まずは潜在的課題を理解する必要があるかもしれません(既に顕在的課題は解決されていたり、代替品が存在していることが多い場合)。
しかし、例えば新規サービスの立ち上げのために、まだ解決されていないユーザーの潜在的課題を調べたいはずなのに、構造化インタビューを行っても、どのユーザーからも想定の範囲を超えるような調査結果は得られないでしょう。
よくある失敗例で「ユーザーに何が欲しいですか?」と聞いても、そもそも潜在的な課題はユーザー自身も把握していなかったり、うまく言語化できないこともあるため、パッと思いついたことや、具体的すぎる解答が返ってきてしまい、そのまま開発すると痛い目に合うことがあります。
潜在的な課題を調べるためには解答に対してさらに問いかけを続け、徐々に関係性を明らかにして詳しく掘り下げるデプスインタビューや、課題の背景や原因の前後関係を調べるのであればオブザベーション(観察)を組み合わせたインタビューなどの定性調査が有効です。

逆に問に対して答えられる場合でもそれがまだ開発者の仮説段階の場合や、定性調査により明らかになった課題をより正確に検証したいような時には、デプスインタビューなどでは時間がかかりすぎて適切ではありません。
顕在的な部分を検証するためにはアンケートや構造化インタビュー、既にサービスがあり内部に分析のための準備が整っているのであれば、集まったデータを分析することで定量的に検証することができるでしょう。
または顕在的な部分はユーザー自身も自覚して言語化できている可能性もあるため、SNSなどを調べて不満の声を集めるという方法もあります。

参考:ユーザー理解の調査手法を正しく理解するために、押さえておくべき2つの軸 | Web担当者Forum

3.調査する環境

調査や評価をする場所はいつもユーザビリティテストルームやインタビュールームで行っていませんか。
サービスによっては実際の利用シーンと異なる場所での実験室調査では、普段とは異なる結果が出てしまうことがあります。

「我々のサービスのユーザーはどこにいるのだろうか」

例えば極端な例ですが、ランニング中の音楽アプリのユーザビリティを評価するのであれば、走っている状況とインタビュールームの机に座って操作してもらうのでは結果に明らかな差があるでしょう。
画面などのスクリーン上のみで目的が完結するようなサービスではなく、外部環境とのインタラクションが発生するサービスであれば、実際のシーンに近い環境に調査担当者が行ってみることで新しい発見が得られるかもしれません。

また、利用シーンはわからない場合でも、ユーザーが集まりやすい環境が特定できているのであれば、現地に行きゲリラインタビューや行動観察を行うことで、素早く調査を行うことができます。
例えば学生向けの英語学習アプリなどであれば、実際に利用するのは電車や家などの環境かもしれませんが、学校や学生が集まりやすい街に行くことで、すぐにインタビューや行動観察に協力してくれる人を見つけることができるかもしれません。
事前にリクルーティングするのも良いですが、スタートアップの初期化説などは足を動かして現地に行くほうが、より大きな学びが得られるでしょう。
※ 街角でのゲリラインタビューなどでは警察署への許可が必要ですので、実際にやられる際にはご注意ください。

4.現状のフェイズ

今現在、あなたのチームは開発プロセスの中のどの位置にいるのでしょうか。
サービスの成長とともに、使用する調査手法も変化していきます。

「我々は何を知っていて、次に何を知ることができれば先に進めるのか」

戦略策定のフェイズで、見込める収益の規模を調べる必要があるなら市場調査が必要かもしれません。
課題や解決策の仮説検証ができていない段階であればJaverinBoardなどを使用して、構造化インタビューやアンケートを行うのもいいでしょうし、仮説の原因を探るために行動観察をするのも良いかもしれません。
Product Market Fitを達成していれば大きな仮説検証は最小限に抑え、A/Bテストやディザイラビリティテストなどの細部の最適化のための調査が必要になるフェイズもあります。
しかし、コアとなるユーザーや課題も明確になっていない段階で、A/Bテストを行ってしまってしまうとどうでしょうか。
そもそも本来調べるべきはユーザーの課題や、解決策の価値にも関わらず、見た目やUIのA/Bテストを実施しても実際とは異なるユーザーにアプローチしているかもしれませんし、解決策自体が間違っているかもしれません。

参考:スタートアップにおいて最も重要なPMFの図り方と達成方法 | Growiz.us
グロースハックにおいて最も重要なアクティベーション完全マニュアル | Growiz.us

5.調査に関する習熟度

あなたのチームは調査についてどれくらいの経験と知識があるでしょうか。
また、意思決定にはどれくらいのメンバーが関わるのでしょうか。

「我々は調査を適切に実施し、学習することができるだろうか」

チームによっては調査の必要性や、インパクトについて十分に理解していない可能性もあります。
そのような環境で、いきなりデプスインタビューや行動観察を自身で実行し、チームメンバーに伝えてもなかなか共感を感じてもらえないかもしれません。
または調査の必要性自体を理解してもらえず、実施の承認が得られないこともあります。
場合によっては本来の調査を行う前に、少し遠回りをしてでも評価から入り、比較的効果を実感しやすいユーザビリティテスト等を実施して、チームメンバーにユーザーとの関わりを持つきっかけを提供するなども必要かもしれません。

あなた自身が途中からプロジェクトにアサインされてユーザー理解が薄い場合もあるかもしれません。
そのような時は、まずはユーザーミートアップに参加したり、街でアプリを使っている人に声を掛けたりなど、理解のための調査も良いかもしれません。
会社によっては中途で入ってきたメンバーは、必ず数ヶ月〜数年カスタマー・エクスペリエンス(カスタマーサポート)の担当をして、ユーザー理解の基盤を作ってからでないと本来の職種で活動できない会社もあります。
もし逆にチームに熟練したメンバーが多く、ユーザー中心の設計プロセスが根付いている場合には、解決策自体にユーザーを巻き込むこともできるかもしれません。
例えばインターフェイスのラベリングや構造を考えるためにユーザーにカードソーティングを行ってもらったり、ビジュアルの印象のためにコラージュ技法のワークショップを実施することも良いでしょう。

6.ユーザー調査は必須ではない

あなたのサービス、または組織でまずやるべきことはユーザー調査ではないこともあります。
開発陣の中でユーザーのイメージがブレているのであれば、まずはどれだけ認識が違っているかを示すために全員が想定するユーザーを書き出してみるワークをチームに展開し、問題提起をすることも良いでしょう。
または作ること自体が好きで創業したスタートアップなどでは、逆にプロダクトアウトで作りたいものを作ってリリースしたほうがチームのモチベーションが上がるというケースもあります。
全てにおいて細かく調査を実施していると、小さなチームならではのスピード感が失われることもあるので、状況に応じた判断が必要です。

しかし、大切なのは必ずどこかの段階でユーザーによる評価、または調査を実施することです。
ユーザーからの適切なフィードバックを得ることで、自分達の目指すべき方向が正しいかを確認することができます。
そこで適切な学びが得られていれば、例え仮説が間違っていた場合でも、より確度が高い方にピボットすることができるでしょうし、組織にもノウハウが蓄積されていきます。


今回は主に調査と評価のみにフォーカスして代表的な手法を元に紹介させて頂きました。
しかし、そこで終わるのではなく目的に合った適切な分析を行わなければ、設計に活かしていくことはできません。
STANDARDではUIなどの具体的な設計だけではなく、調査段階からの関わり方やサービスの改善の方向性を一緒に考えていくようなご依頼も受け付けています。
新規事業を検討されている方や既存のサービスに悩みを抱えている方はお気軽にお問い合わせください

記事一覧へ

Related Articles

About us

アプリやWebサービスなどの新規事業や既存事業における
アイデアの仮説検証からデザインまでをサポートします

株式会社スタンダードは、アプリやWebでサービスを展開される方の企画制作をサポートするデザインファームです。