利害関係者をユーザーテストに関与させる

ユーザビリティのセッションに、デザインチームのメンバー全員と彼らの上役である様々な階層の管理者を招待することを、何十年も私は勧めてきた。実際のところ、企業がユーザビリティプロセスの成熟度の段階を上げるため、ユーザビリティラボに投資する主な理由の1つは、テスト参加者を怖がらせることなく、より多くの人が彼らを観察できるようにしたい、というものである。（とはいえ、観察する人がほんの数人である場合は、ドアの閉まる部屋であればテスト用施設として使用はできる）。

どうやって自分たちでユーザーテストをするのかという我々のコースでは、こうした観察者がユーザビリティについてあまり知らない場合に、彼らをどのように扱ったらよいかをかなりの時間を使って議論する。実のところ、これは非常に重要な問題なのである。しかしながら、最近、実施したカンファレンスの1つでは、次のようなさらに重要な質問が聴衆の1人から投げかけられた。そもそもなぜこうした「部外者」をテストに招待するのか。開発者や経営陣といった人たちのことを気にすることなく、自分たちだけでテストを実施してしまった方が効率は上がるのではないだろうか。

ほとんどの場合には、ユーザビリティに関わるすべての活動を1人が担当し、他の人は皆、自分の仕事をした方がたぶん効率はいいだろう。

その主な例外としてよくあるのは、バグのある発売前ソフトウェアのテストである。こうしたケースでは避けられないクラッシュのときにそれをなんとかするのを手伝ってくれる開発者がそばにいてくれれば便利というわけだ。（初期ビルドをテストすることが重要だということは覚えておこう。初期であればあるほど効果は高い。なぜならば、実装するには遅すぎる調査結果よりも、初期のユーザビリティのフィードバックの方が最終的な製品へのインパクトがずっと大きいからである）。

チームとしての意識を確立する

現実世界の組織では、ユーザビリティプロセスの効率はデータ収集に費やされたスタッフの労働時間ではなく、製品の改良度に対してどのくらいスタッフの労働時間が費やされたかによって測られる。

つまり、ユーザーのデータを大量に集めることは、結果的にアドバイスが導き出されるときにのみ、意味が出てくるのである。

ユーザビリティセッションにチームメンバーを招待する主な理由は、そうすることでユーザビリティ上の発見の受容性が大きく高まるからである。百聞は一見に如かず。そして、生で観ればその効果はさらに高くなる。

顧客がウェブサイトで困っている様子をビデオに撮り、ミーティング中にこのビデオクリップを見せることは可能ではある。それが効果的であることは間違いない。調査結果についての印象を強めて、記憶に残るようにしてくれるため、我々はセミナーでは例外なくそうしているくらいだ。

しかしながら、ユーザーが参加している生のテストセッション中、チームメンバーが同じユーザビリティ上の問題を直接目にすれは、その効果はさらに増す。だからといって、我々がテストのビデオを偽造しているなどと彼らが実際に疑っているわけではないだろうが。（もちろん、それは絶対にやってはならないことである。一度でもインチキのデータを使えば、今後、あなたの「発見したこと」に対する信用はすべて失われてしまう）。何かが起きている間、実際にその場にいるというのは、記録されたものを後から見るよりも効果的だ。つまり、事柄そのものの方がそれについて書かれたものをただ読むよりも影響力が強いのである。

ユーザビリティセッションの間、チームのメンバーにその場にいてもらうことにはいろいろなメリットがある：

• 信頼。知見がどのように導き出されているかを目にすることで、ユーザビリティについてのあなたがたの調査結果やレポートを（でっち上げられたものでも、個人的な意見や志向を単に提供したものでもないものとして）信じてくれるようになる。
• 協力。チームメンバーには観察しに来るよう誘うだけなく、テストセッション中の出来事を議論するためのデブリーフィングにも参加するよう要請すべきである。そうすることは、早期の妥結を下すのを助ける。分析に参加した人はアドバイスを受け入れて、それに従って行動を起こそうとする傾向が強い。
  • 注：　これはデザインアドバイスを受け入れさせるための単なるギミックではない。幅広い専門分野の人がいるグループで観察結果を分析すれば、調査から得られる実際の所見はより優れたものとなる。その上、観察する目が増えることで、何か違う物も見えてくるだろう。
• 記憶しやすさ。箇条書きで書かれた状態で見ただけ、あるいは長いレポートの中で読んだだけの調査結果を覚えておくのは難しい。しかし、調査結果とその元になったユーザーセッションを見たその人自身の体験が結びつけられれば、容易に調査結果は覚えておけるようになる。
• 感情移入。感じのいい人達が自分のデザインのせいで苦労しているのを見れば、修正しなければと強く思うものだ。また、そうしたユーザーが自分たちのニーズに合ったデザインにしてくれと明瞭且つ筋の通ったリクエストをするのを聞けば、そのチームメンバーは、「こんな間違いを犯すのは 頭の悪いユーザーだけだ」という言い訳を（無意識のうちでも）しなくなるだろう。
• デザイン上の間違いの減少。デザイナーや開発者が実際の顧客を見ていれば、ユーザーのためにならないであろうデザインアイデアに突っ走ってしまうことは減るだろう。UIの原案が優秀であればあるほど、次回のユーザーテスト後に必要な修正は減る。

経営陣にユーザーテストへの出席を要請することにもたくさんの同じようなメリットがある。彼らは実際のユーザーを見た後にはユーザーの経験というものを重視する傾向がある。そして、デザインを魅力的にすれば「ブランド力は上がる」という広告代理店のいうでたらめを信じなくなる。お金を払ってくれる実際の顧客がそうしたデザインをどれほど嫌がるかを聞くからである。最終的には、来年の予算配分の時期になったときにあなたのしていることを経営陣が理解していれば、自然により大きな予算が獲得できるようになる。つまり、生のユーザーセッションというものはそれだけしっかりと心に残るのである。

一部分だけを観察することによるリスク

ユーザーテストを実施することがあなたの仕事である。デザインチームの他のメンバーにはやるべきことが別にいろいろとあり、役員はさらに忙しい。

UIをテストするとき、それの実際のデザイナーはそのユーザビリティ調査全部に出席することが多いだろう。しかし、彼らですら競合テスト中、1回か2回のセッションにしか来ないこともあり得る。その一方、マーケティングマネージャーは競合テストの全部に来る可能性もあるが、成功するのが難しいとわかっている機能についての5回目の反復テストの前に退出してしまうこともあるかもしれない。

チームメンバーのほとんどの人にはユーザーセッションのすべてに出席する時間はない。それは仕方がないことである。1つか2つのセッションだけでも見に来てくれるのは歓迎ですと必ず招請状に書いておけばよい。しかしながら、調査の全部に参加しない人がいる場合には以下のような問題点がある：

• 一部のサンプルから早まった結論を出すこと。ユーザビリティに関する主要な所見についての適切なアイデアを1つ得るには、ユーザーを5人もテストすれば足りる。しかし、正確な傾向やパターンを特定したいのであれば、ユーザー1人か2人のテストでは十分でない。少数のユーザーしか見ていない人にはユーザビリティ上の大きな課題を間違って特定してしまう可能性があり、解決策を正確に導き出すほどの知見は持てない。
• 記憶にバイアスがかかること。人の心とユーザビリティのセミナーでさらに議論することにしているが、我々の記憶というのはいろいろなバイアスがかかりやすく、抽象的な概念を覚えておくのがかなり苦手である。ユーザーセッションを観察することの利点は、それによってユーザビリティ上の課題が記憶しやすくなることにある。何が起きるかを直に見るからである。危険な点は、調査全体についてのレポートで読んだだけのことより、自分自身が実際に見たユーザビリティ上の問題の方をずっとよく覚えているようになることである。
• 共感でバイアスがかかること。同様に、デザイナーや開発者、マネージャー達は自分たちが見たことのあるユーザーのニーズに応える方が、結果を聞いただけの、でも同じくらい重要なユーザーセグメントのニーズを満たすよりも重要であると無意識に思ってしまう。

こうした問題は避けられないものだ。しかし、そうした問題を知っておくことで問題の程度を軽くすることもできるし、他の利害関係者にそうしないようにと注意することも可能になる。たいていの場合、同僚や経営陣に可能な限りたくさんのユーザーテストを観察するよう要請することによるメリットの方がマイナス面をずっと上回る。彼らのほとんどにとって、それは動いている顧客を目の当たりにするそもそも唯一の機会である。したがって、大いに感謝もされる。このこともテストに関係者を招くもう1つの理由といえよう。