「UXデザイナー」の画像を検索すると、同じような結果ばかりが表示されます。恐らく、机に向かって背中を丸め、グリッドの入ったメモ帳にワイヤーフレームを描いている眼鏡の男性の画像が見つかるでしょう。あるいは、壁の模造紙に貼られたポストイットを眺めて考え込んでいる眼鏡の女性かもしれません。走り書きされたホワイトボードの前で話し合う眼鏡の社員たちの可能性も高いでしょう。これらの撮影者が、なぜUXデザイナーは全員視力が悪いと思っているのか、私には理解できません。
デザイナーの日常業務には、共通した静的なイメージがあるのでしょう。しかしながら現実のUXデザイナーは、必ずしもMacbookに張り付いてたり、会議室に閉じこもっているわけではありません。UXデザイナーの仕事はもっと動的です。フォーカスグループやインタビュー、デザインワークショップ、そしてオンサイトリサーチを繰り返しています。
オンサイトリサーチ（On-site research）とは名前の通り、UXデザイナーをデスクの束縛から解放し、製品が実際に存在する（または将来的に存在するだろう）現場を訪れることです。適切に実施されると、社内でデザインしているだけでは決して得られない、実用的で貴重なユーザーインサイトを獲得できます。一方で使い方を間違えると、特に締切が厳しいときには、プロジェクトサイクルの時間を多く浪費してしまうでしょう。
そこでオンサイトリサーチを十分に活用するために、CodalのトップUXデザイナーに頼んで、オンサイトリサーチにまつわる彼らの技術やベストプラクティスを提供してもらいました。
なぜオンサイトリサーチをするのか？
オンサイトリサーチを実施すれば、どんなデプスインタビューや調査からも得られないようなデザインのデータや視点を獲得できます。中でもオンサイトリサーチで得られるもっとも価値ある利点は、コンテキストです。便利で美しい製品は、隔絶された会議室では生まれません。なぜなら、UXデザインはコンテキストなしには存在できないからです。
実際の現場で使用されている製品を観察することで、デザイナーは製品が利用される現実のコンテキストを理解することができます。オンサイトリサーチでは、ユーザー自身が意識していないペインポイントや市場機会を見つけることができるのです。
記事を書くにあたり、私はコンテキストの実例をCodalのUXデザイナーに聞きました。すると彼らは私に質問を返し、チームの近しいメンバーとどのようにコミュニケーションをとっているのか尋ねてきました。Slackで機械的に話すのか？ 面と向かってコミュニケーションするために、すぐそばのマネージャーのオフィスまで足を運ぶのでしょうか？ これらの行動によって、たとえば社内プラットフォームのメッセンジャー機能にどのような影響を与えるでしょうか？ そのような細かいことについて、私は今まで気づいたり、深く考えたりしたことがありませんでいした。しかしUXリサーチャーの注意深い目は、それらの小さな事象を逃しません。
「現実の世界で」製品を観察することは、デザインプロセスに知見を与えるだけでなく効率化にもつながるのです。長年の経験や企業のベストプラクティスは素晴らしいガイドラインになっている一方で、プロジェクトの内容は毎回異なります。より良い調査は、よりスマートなデザインプロセスを生み出します。それによって、UXデザイナーは憶測を排除し、繰り返しの作業を減らし、素早く問題を解決することができるでしょう。
いつオンサイトリサーチを行うのか
地理的な条件や締切が許すなら、この疑問に対する理想的な答えは「いつでも」です。しかしより現実的な答えは「プロジェクトによる」です。
比較的制限された環境でしか使用されない製品は、オンサイトリサーチの理想的な候補です。たとえば、社内の従業員が使用するプラットフォームであれば、ユーザーは会社のスタッフに限定されます。
ご想像の通り、オンサイトリサーチが適さないプロジェクトは、一般的に使用される範囲や環境が広いものです。ただ、オンサイトリサーチを完全に無視するべきだと言っているのではありません。
ベストプラクティス
オンサイトリサーチが重要な理由を理解し、現行のプロジェクトにとって適切かどうかを判断できたら、私たちは優れた知見を得ることができるでしょう。では、オンサイトリサーチをもっとも効果的で効率的に実施するにはどうすればいいでしょうか？
１. 準備
デザインプロセス自体と同じように、調査はさまざまな準備から始まります。何も考えずに現地を訪問し、質問を即興で考えないようにしましょう。無意味な調査を生み出す要因になります。効果的で一貫した現地訪問をするために、事前に質問を準備してクライアントとブレインストーミングをし、ガイドラインやチェックリストを作りましょう。リストには次のような質問を含めるべきです。
- この環境を特徴づけるものは何か？
- ユーザー体験にとって、現状何がペインポイントや問題なのか？
- これらの問題を解決するために、何か解決策が取られているか？ それはどのようなものか？ どれだけ効果的か？
- 人々はどのように関わり合っているか？
尋ねたい質問がわかったら、問題を解決する機会がどこにあるのか、より正確に特定することができます。オンサイトリサーチの最中にさらに多くの疑問が生じるかもしれませんが、これらの基本的な質問は調査の確固たる基盤になります。ここまでで、必要なデータ収集の方法を選択する準備ができました。
２. 観察のフレームワークを使用する
オンサイトリサーチの根本的な目的は、観察と記録です。これらは想像よりもはるかに難しいタスクです。何に注意を向けて、何を無視すれば良いのでしょうか？ どうすればノイズから有益な情報を選別できるでしょうか？
これらの基礎的な疑問に応えるために、多くのUXリサーチャーが観察のフレームワークを生み出しています。重要なユーザーデータを確実に得るための方法と組織化ツールがあれば、あらゆる種類のやりとりを適切に識別し、把握することができるでしょう。
観察のフレームワークにはさまざまな種類がありますが、UXデザイナーの中でもっとも有名なものは（そしてCodalの中でもっとも使用されているのは）、POEMSです。
POEMSは多用途である点で、とても優れたフレームワークと言えます。観察時間が15分だとしても50分だとしても、同じように効果を発揮します。また、POEMSはフレームワークの広さという点でもおすすめです。この利点は、POEMSが何の頭文字なのかを見るとわかります。
- 人々（People）：役割、ポジション、行動の特徴、デモグラフィック、人口
- 目的（Objects）：人々は何を操作するのか。機械、ツール、機能など
- 環境（Environments）：照明、温度、建築物、空気
- メッセージ（Messages）：言語、言い回し、よく使うフレーズ、社会的か専門的か
- サービス（Services）：環境に影響を与えるすべてのアプリ、ツール、システム
これらのカテゴリーを使って観察眼を鍛え、調査結果を整理しましょう。そうすれば重要なユーザーデータを見逃すことなく記録が整理されて、デザインプロセスの後の段階で振り返りやすくなります。Web上にはPOEMSのワークシートが溢れています。信頼できるテンプレートはこちらからダウンロードできます。
POEMSのテンプレート（参照：Atomic Object)
3. 観察の先へ
プロジェクトによっては、調査を中断して利用者により詳細な情報を聞くことなく、実際の環境の中だけでしか参加者を観察できないものもあるかもしれません。それでも可能であれば、対象者と話し合ってプロセスマッピングを作成するべきです。
プロセスマッピングでは、標準的なユーザーインタビューのように、ユーザーとUXデザイナーの１対１でデザインの問題について話し合います。しかし標準的なインタビューとは異なり、プロセスマッピングは、ユーザーが製品を利用するプロセス中に実施して、利用ステップごとに集中して情報を記録します。
プロセスマッピングを行う間、ユーザーは特定のタスク（メールの送信やアカウントへのサインインなどの、プロジェクトに関わるすべてのワークフロー）をリストアップして、それらを難易度や必要度といった基準に即して順位付けます。
Codalの現地調査での、プロセスマッピングの実践
プロセスマッピングが効果的である理由は、普段無意識に操作しているタスクを分解し、高い精度でタスクについて考えることをユーザーに強いるからです。プロセスのどの部分が複雑で、どの部分が簡単か、どの部分がまったく必要ではないかといった、あらゆる有益なインサイトが明らかになります。
起き上がれ、飛び出せ、手に入れろ
オンサイトリサーチは、UXデザイナーにとって欠かせない手法です。プロジェクトにおける発見フェーズを活性化することもできます。さまざまな知見を獲得し、デザインプロセスを前進させることができるでしょう。ユーザージャーニー、制作する機能のリスト、優先順位、デザイン原則やガイドラインといった将来の制作物の下準備にもなります。
次のプロジェクトの発見フェーズでは、デスクから離れ、会議室から飛び出しましょう。「起き上がって、外に飛び出せ、そして何かを手に入れろ」という、OutKastの不朽の歌詞を実行するのです。
