HBOのドラマ『シリコンバレー』を見ているUXデザイナーなら、誰もがシーズン３の最終週にテレビに向かって叫んだでしょう。架空のファイル圧縮プラットフォームPied Piperは、デイリーアクティブユーザーは僅かしかいないのにローンチされ、製品開発プロセスにユーザーリサーチやユーザーテストが一切行われない場合に何が起こるかを示す完璧な事例となりました。
Pied Piperがもし調査をしようと思っていたなら、比較的容易にできたでしょう。ユーザーリサーチは、喫茶店にいる人に声をかけて協力してもらうのと同じくらい手軽にできる場合もあります。FacebookやGoogleなどリソースが無限にありそうな企業であれば、厳密なテストを定期的に実施するリソースを割けるでしょう。しかし、多くの企業ではテストを行う上で時間やお金、人的リソースなどが最大の課題となります。そして、社内の承認を得るために四苦八苦することは、言うまでもないでしょう。
無駄がなく手堅い製品であっても、ユーザーテストを通して多くのインサイトを得ることができます。最近、私自身もテストを行ったのですが、多くの課題に直面しました。私の場合、既存顧客とのやり取りの方法を必死に守ろうとするカスタマーリレーションのマネージャーというテストを邪魔する厄介な「おまけ」もいました。
私は、JW PlayerというBtoB企業で働いています。私たちは、オンラインビデオ企業や開発者に対する支援を専門としており、視聴者へのリーチおよび拡大やビデオコンテンツの収益化といったお手伝いをしています。ここ数年間で、JW playerはSaaS事業に移行し驚異的な成長を遂げ、新たな製品ラインの拡大もしました。私たちは、顧客が喜んでくれる意思決定ができているか確認するために、顧客やユーザーに対するテストに着手しました。
この記事では、テスト手法の選択、テストにおける制約、目標の設定、計画の実行などについて説明していきます。
テスト方法の選択
JW Playerで、新しいユーザーリサーチプロセスを作り、ユーザーテストすべき顧客タイプを決め、話を聞くのに適した人を集めていたときの話です。このとき、私たちは新しくリリースしようとしているリアルタイム解析ツールの初期テストも行えるのではないかと気付きました。このツールは、デバイスや位置情報毎にビデオのトラフィックとパフォーマンスを測定することができるもので、当時は製品に関して次のようなことを知りたいと思っていました。
- ユーザーにとってもっとも価値のある指標はどれか
- このツールを使用する可能性の高いユーザータイプはどれか
- ツールで表示される内容は、ユーザーの解釈と一致しているか
開発プロセスのどのタイミングで行うか、チームメンバーの知識のギャップがどこにあるかによって、ユーザーリサーチの選択肢は変わります。これについては、多くの人が詳細に調査し、説明しています。
私たちにはあまり時間がありませんでしたし、予算もありませんでした。そのため、ほかのオフィスへの移動や社内のテストスタジオの準備などは選択肢から外れました。
既に作ってあるローファイな（忠実度の低い）プロトタイプに対し、被験者への具体的な質問も用意してあったので、必要な回答を得るにはモデレーター付きのリモートユーザーテストをすれば十分だと思いました。
プロトタイプを使ったモデレーター付きのリモートテストは、次のような理由からうまくいくと判断しました。
- 内部管理性：業務は全部オンラインであるためすべてが共有可能で、多くのステークホルダー（異なるチームに属している可能性がある）間でのコミュニケーションが容易です。
- 外部管理性：出張の必要がない場合、スケジューリングはより簡単です。ユーザーに自分のオフィスまで来てもらう必要はなく、各自の快適なオフィスで30分共有してもらうだけなのでテストを頼みやすいです。さらに、JW Playerの顧客は世界中にいます。これは、顧客全員をテスト対象に含めることができる素晴らしい方法です。
- 柔軟性：BtoB企業では、現場でのテストのためのリソースがつねにあるとは限りません。しかし、遠隔テストは効率的に低コストで実行できます。
このリモートテストは、画面録画を用いたセッション追跡を行えるので、あとからステークホルダーに簡単に共有することができます。さらに、複数のチームメンバーがさまざまな場所から参加することができ、私たちの場合は２，３日で数セッションのテストを実施できました。完成品に多くの開発時間とデザイン時間を費やす前に、プロトタイプでアイデアを検証し、あらゆる危険信号を浮き彫りにすることができます。
このように、テスト方法は選びました。次は計画を立て、私たちの新製品「Right Now Analytics」のテストを始めましょう。
フェーズ１：計画と目標設定
目標を決め、全体の計画を立てる段階になりました。テストにおける発見をまとめ、コミュニケーションを行うためのテンプレートとしてTomer Sharon氏の１ページの調査計画を使用したいと思います。これはプロジェクトの開始時に、全員の足並みをそろえるのに非常に役立ちます。テンプレートでは、以下のような質問に答えます。
- 私たちは何を調査またはテストしているか
- ターゲットとするユーザーは誰か
- 私たちはターゲットユーザーに何を言うのか
- チームの誰に共有しておく必要があるか
このようなドキュメントを共有することで、調査からなにを得るかという期待と心構えをチームに共有できます。そして、調査をいつ終わらせるかも明確になります。さらに、すべてのコミュニケーションを効率的にします。これこそがこのタイプの調査の第一のテーマです。
私たちの調査プロジェクトでは、未完成のワイヤーフレームやインタラクティブなプロトタイプを使いテストをしてきました。このケースでは、未デザインのテスト用ページを作成し、そこに実際のデータを入れました。この調査では、データそのものの価値を評価し、ページに何を含めるべきかについてより高いレベルの決定を下すことを目指していたので、この実際のデータが入った未完成のプロトタイプは、検証の結果の忠実度の高い選択でした。
学んだ教訓
計画を立てる。具体的で明確な目標を設定する。チーム全体が計画に同意していることを確認する。テストの主題と焦点が、用意した質問に対する答えを明らかにするために適切であることを確認する。
フェーズ２：ターゲット設定、アウトリーチと調整
この段階では、ほかの一般向け製品チームの多くは関係ないであろうハードルと直面します。顧客管理ツール、製品データベース、および複数の分析情報ソースなど、BtoBに焦点を当てた企業のユーザーデータベースはバラバラで統一されていない可能性があります。多くの場合、「ユーザー」、「バイヤー」、そして「顧客」ははっきり区別されていますが、「ユーザー」が「バイヤー」でもある場合可能性もあったり、不満を感じサポートを求めている「ユーザー」は、製品のテストを依頼する私たちに対して反発することもあります。言うまでもなく、これは難しい問題です。摩擦を最小限に抑えるために、私たちはアカウントマネージャーが誰といつ話す（または話さない）か、いつ話すかに目を向けました。
このフェーズでは、やり取りをするのに適切なユーザーを特定し、さらにデリケートな既存の関係を壊したり、悪影響を与えたりしないようにすることが目標です。
適切なユーザーの発見には時間がかかります。企業にもよりますが、必要な情報を収集するためにチームや複数のデータベースを横断する必要があるかもしれません。さらには、アカウントマネージャーに早々に迎え入れられるかもしれませんし、予想以上の時間がかかるかもしれません。
学んだ教訓
時間と労力はかかるものの、ユーザーテストに参加するように依頼する前に、システム内のユーザーの状況を理解することが重要です。やり取りする前に、ユーザーとの関係が現在デリケートまたは不適切な状態になっていないことを確認するように心がける。
フェーズ３：セッションの実施
ユーザーが選ばれ、テストの準備ができました。私たちは効率的なツールを選びました。
- カメラとマイク付きのノートPC
- グループ通話とスクリーン共有用にGotoMeeting
- 録画と録音用にCamtasia
- セッションの録音の保存、整理、および共有用にJW Playerダッシュボード
- そのほかはすべてGoogle
- アウトリーチと設定用にGmail
- セッションの招待状送信用にカレンダー
- メールを統合するのためのスプレッドシートプラグイン
- メモ取りと共有、ユーザーの会話の追跡用にGoogle Drive
私たちはリモートテストツールをセットアップしてユーザーを招待し、テストの進め方を正確に説明しました。
これらのリアルタイム解析のプロトタイプテストの中で、何人かのユーザーは使用しているほかの解析ツールやリアルタイムツールを見せてくれました。ユーザーが信頼しているほかのツールをユーザー視点で知ることができたため、豊富な知見を得ることができました。これは、フィードバック収集を行うほかの遠隔手法と比較したスクリーン共有の利点の素晴らしい例です。
学んだ教訓
計画した話題へと会話を誘導するのを恐れる必要はありません。ノートにすべてを書き留めるよりも、自然に受け止めることのほうが重要です。また、わかりきったことのように聞こえるかもしれないですが、つねに「録画」を忘れてはいけません（マルチスクリーン設定の場合、ソフトウェアが録画している画面はどれか注意する）。私たちはこの教訓を苦労して学んだため、念のために確認するようにしましょう。
フェーズ４：成果報告、キャプチャと共有
ユーザーが離脱した時点で、私たちは自分たちが学んだことについて手短に話しました。興味深く注目すべきことを洗い出し、もっとも参考になることを集めました。
テストの間、ユーザーはリアルタイムデータに集中して、なにができるのか疑問を抱いているように見えました。しかし、実際にはユーザーが決定をするときに必要としているのは、基本的なリアルタイムデータのみであると気付きました。
さらに、リアルタイム解析は必要ではないと言ったユーザーが、実際には意思決定にChartbeat（リアルタイムデータツール）をどのように使用しているかも調べることができました。これは、スクリーン共有がとても重要なもう１つの理由です。ユーザーの発言と行動が一致しないこともあるます、そしてその差異は、リサーチャーが実際にユーザーの世界に入ることで初めて浮き彫りになるのです。
学んだ教訓
セッション後は考えるべきことがたくさんあり、次の日までテスト内容をすべてを覚えておくのは難しいです。そのため、すぐに成果報告を行うことは、メモに書き留めていない考えを把握するのに役立ちます。また、ユーザーが話したことに対してどのような行動を取るかよく考えるのにも役立つでしょう。ユーザーの発言よりも、ユーザーの行動のほうが重要であることのほうが多いのです。
フェーズ５：アクションアイテムとその先
すべてのセッションが実施されたあと、パターンやポイントを探すためにメモを読みました。そして、プロダクトマネージャーがこの情報を元に必要なユーザーストーリーを作成し、技術チームと一緒に実行計画を立てます。
テストはすぐに完了したわけではありませんが、研究や出張の予算なしで数週間の内に効果的な調査結果にすることができました。ユーザーに対して調査へ参加しに来てもらう不便を感じさせることなく、遠隔セッションで時間をできる限り最小限に抑えることができました。
また、検証結果によって計画どおりにプロトタイプを進めても良いと確認できました。全体的に、ユーザーは価値を見出して興味を持ってくれていました。私たちは、ユーザーにとってわかりやすい情報設計を作成するために、レイアウトの微調整が必要であることがわかりました。また、特定のタイプの組織におけるユーザーは、このツールに興味を持っていない可能性があることもわかったので、実際の製品でのベータテストの後半にあるメッセージを強化しました。
データのパイプラインが洗練され、モックアップ用のワイヤーフレームがデザインに送られ、最終的にユーザーが現在目にしている「Right Now」アナリティクスになりました。
学んだ教訓
調査結果を伝えるとき、定量的データやパターンは非常に役立ちます。報告方法を賢く選択し、ユーザーにとって影響力の強いものであることを確認しましょう。また、セッションから興味深い瞬間を抜き出して考えてみると良いです。これは共感を生み出し、開発者と製品チームが自分たちがソリューションを提供している人々とのつながりを持てるようにする素晴らしい方法となります。
テストにはつねに課題がある
研究を計画して実施する際には、誰もがそれぞれの課題とハードルに遭遇します。「理想的な」対面調査を行う時間やお金がない場合、遠隔のモデレート付きのリモートテストセッションを数人で行うことを検討してみましょう（５人に行えば十分でしょう）。テストされているデザインやプロトタイプの忠実度に応じて、価値や明瞭さ、構成、フローなど、幅広い未解決の問題に答えることができます。
テストに関する決定をするチームは、次のことを検討しましょう。
- ユーザーはどこに住んでいるか。
- 顧客のアカウントは良好な状態にあるか。
- 出張予算はあるか。
- どんな質問に、いつまでに答える必要があるか。
私たちのチームがこの作業を行うことができるのであれば、どんなチームでもできるはずです。Richard Hendricks氏とPied Piperもそうするべきです。シリコンバレーのシーズン４がよりユーザー中心の冒険をもたらしてくれることを期待しています。
