ユーザー調査のないUXは、UXではない
UXチームの責務は、ユーザーにとって望ましいエクスペリエンスを作り出すことである。にもかかわらず、ユーザーを開発プロセスに巻き込んでいない組織は多い。顧客からのインプットがない組織は役に立たないインタフェースを作り出してしまう危険がある。
Webサイト（あるいは製品）の成功はユーザーからどう思われるかにかかっている。ユーザーはWebサイトの有用性と使いやすさを、そのサイトとインタラクションしながら評価し、数秒、ときには数ミリ秒で結論を出す。
あるサイトに関与するかどうかのユーザーの判断の基準になるのは、「そのサイトは自分にとって価値があるか。使いやすいか。そこでのエクスペリエンスを楽しめるか」といった問いである。ユーザーエクスペリエンスが良質であれば、この問いへの答えはすべて「はい」という結果になる。
ユーザーエクスペリエンス（UX）とは何か
ユーザーエクスペリエンス（UX）はデザイン業界では一般的に使われている用語だが、その定義はUX業界の中ですら、少々わかりにくい。Nielsen Norman Groupの創設者であるDon NormanとJakob Nielsen（ニールセン博士）は1998年にこの会社を始めるとき、UXを以下のように定義した：
模範的なユーザーエクスペリエンスの第一の要件とは、悩ませたり面倒をかけることなしに、顧客のニーズを正確に満たすことである。次に必要なのは、製品を所有することがうれしく、利用することが楽しくなるような、簡潔さと上品さである（UXの定義の全文を参照のこと）。
つまり、UXのチームや専門家はユーザーが欲しいと思い、必要とする製品を作り出す努力をして、利用するのが容易で楽しい製品をデザインすべきである。ユーザーエクスペリエンスはユーザー、そしてユーザーと製品とのインタラクションに影響を及ぼすすべてに関係するからである。
もちろん、模範的なユーザーエクスペリエンスを達成したいと誰もが考えている。しかしながら、実際には、この実現に必要なことへの理解が不十分な組織は多い。ユーザーエクスペリエンスという領域は最近、流行ってはいる。しかし、多くの組織ではそのデザインでの実践はまだうまくいっていないのである。
ユーザーエクスペリエンスに対する責任は全員にある
UX部門やUXとつく役職があるからといって、UXを実践していることにはならない。模範的なユーザーエクスペリエンスを達成するには、製品管理、開発、マーケティング、コンテンツ、カスタマーサービス、グラフィックデザイン、インタラクションデザイン等の多数の領域間での連携が必要である。言い換えると、ユーザーのことを考える責任は皆にある。製品ライフサイクルの各ステップでユーザーのニーズについて考慮しよう。それには自分たちのデザインへの取り組みの中心にユーザーをずっと据えておくことである。
真に効果的なユーザーエクスペリエンスを創造して、企業が繁栄していくには、多様な領域や利害関係者による組織的アプローチが必要である。製品が真に成功するには、ユーザー中心のデザインによってビジネス目標を補完する（あるいは推進する）ことが必要なのである。
ビジネスのゴールとユーザーのゴールの橋渡し
ビジネス上の優先事項にはユーザーのニーズという現実が欠けていることが多く、そこでの決断では自分たちが素晴らしいと「思う」かどうかが基準で、「真に」素晴らしいかは基準ではない。UXには戦略的な側面があり、ビジネスやユーザー、彼らが操作するコンテキストを深く理解する必要がある。
UX専門家の最大の不満の1つが、ユーザー調査のようなUX関連の活動に対する組織のサポートがないことだ。この問題はアジャイルのようなクイックリリースの製品開発フレームワークではさらに深刻である。さらに悪いことに、スクラムのようなアジャイル開発手法ではUXデザイナーは中心的な役割を果たさないのが普通で、多くの組織でUXは不可欠なものではないと思われている。しかし、残念ながらこれは間違っている。
最近実施したアジャイルチームのメンバーへのインタビューで明らかになったのは、ほとんどのチームがデザインやコンセプトについてのユーザー調査を実施してないということである。こうなってしまっている一番の理由として回答者から挙がっていたのは、時間的制約とUXに関するリソース不足である。同様に、ユーザー調査の省略はウォーターフォールを含むどんな製品開発モデルでも起こりうる。手法がなんであれ、自分たちのどこが顧客に真に価値があるのかを知らないまま、組織は製品を出荷しているということである。重要なのは何個の製品をリリースできるかではない。それがジャンク品なら、単にジャンク品をより多く出荷することになるだけだからである。
口先だけのUX
チームはプロジェクトから様々な大きさのプレッシャーを受けている。そのため、我々は回り道をしないように、自分たちの直感に頼るということをしてこなければならなかった。しかしながら、ユーザー中心のプロセスの価値は長期的なものである。それは我々が目標に到達することを手助けしてくれるからである。
我々が本当にサポートする必要があるのは、ユーザーデータに基づくデザイン決定やビジネス戦略であって、自分たち自身の経験や好みによるものではない。ユーザー中心の実践が実行されれば、デザイナーやリサーチャーはビジネスニーズとユーザーニーズが重なる「スイートスポット」を見つけることが可能である。
UXのデザイナーとリサーチャーにビジネスの優先事項に意見する権限を与えよう。そうすれば、「とにかく出荷する」という考えにあなた方のプロジェクトが陥ることはなくなる。また、そうした組織作りをして、それを企業文化に育てよう。その結果、ビジネスの上の優先事項を達成する方法としての顧客ニーズの解決という目標に対して、経営幹部を含む皆が結びつきを感じられるようになる。
ユーザビリティの伝道方法はいろいろとある。あなた方の代わりに調査参加者にそれをやってもらうのも1つの手だ。反対派にユーザビリティ調査を見学させる方法を探しだそう。顧客が苦労しているところを見れば、ベストプラクティスに異議を唱えたり、やみくもなデザインを続けるのは難しくなる。
正しい調査を正確に行おう
善意からなされた調査もやり方や実行する過程に不備があることもある。企業がパニック状態でNielsen Norman Groupに連絡してきて、彼らの新しいWebサイトがなぜうまくいってないかを見つけ出してほしいと手助けを求めるということは、多すぎるほどよくある。彼らにローンチ前にユーザビリティ活動を行ったかどうかをたずねると、答えはたいてい「はい！」だ。ではなぜそのデザイン変更はさんざんな結果になったのか。その主な理由はやり方がまずかったからである。
やり方の間違いとしてよくあるのは：
フィードバックを求める相手を間違えている： 利害関係者や同僚というのは実際のユーザーではないし、ターゲットオーディエンスを代表しているわけでもない。デザインプロセスには正しいユーザーを巻き込むようにし、社内の同僚を参加者にするのはやめよう。彼らはそのデザインに近すぎる位置にいることが多く、率直で正確なデータを提供できない。
誘導尋問している： 進行役に経験がないと、誘導尋問をしてしまって、誤った結果を引き出し、調査にバイアスをかけてしまうこともありうる。ユーザビリティテストは行動学的調査を理解している人間によって実施されると、得られる情報の有効性がずっと高くなる。
利用する調査手法を間違えている： ユーザーテストが何をさすかは人によって様々だ。そこに含まれる手法にはアンケート調査やフォーカスグループもあれば、A/Bテスト、ユーザビリティテスト、等もある。選ぶ手法は聞きたいことや開発ステージによって変わってくる。アンケート調査は意見ベースのデータを集めるには適していることも多いが、意見のやり取りには向かない。間違った手法を適用すると、誤った結論に導かれかねない。
調査を実施するときには、バイアスを避け、正しい答えを得るため、どうやって、いつ的確な手法を利用するとよいかをきちんと知っておこう。
ユーザーテストで加わるメリット： チームワークの向上
すでにお気づきかもしれないが、ユーザー調査の主なメリットは、デザインや製品を決定する材料となるユーザーデータが得られることである。しかしながら、この活動には強力な副次的効果がある。それが、コンセンサスの構築である。
クライアントから彼らのデザインやコンセプトについてのエキスパートレビューの実施を依頼されることはよくあり、喜んでそれをさせていただいている。しかしながら、私は時々、ユーザビリティ調査の実施を提案する。それによって社内での意見の不一致の解消や、開発時間のスピードアップができるからである。社内で堂々巡りの議論をするよりも、様々な理論を試すほうがよい場合は多い。
ユーザビリティやデザインについてのアドバイスの提供はUXデザイナーやUXリサーチャーの仕事の一部に過ぎない。チームが生産的なやり方で前進する手助けをするのも仕事だ。それには意見ではなくデータを用いるのが一番だ。推測の入り込んだデザインソリューションを覆すのは容易だが、証拠による裏付けのある選択肢に異議を申し立てるのは非常に難しいからである。
憶測が飛び交っているミーティングを終了させる最善の方法は「ではそれをテストしてみましょう！」という発言だったりもする。
その発言の後には軽いユーザー調査を実施しよう。そうすれば、すぐにその憶測が正しいか、あるいは誤りかがわかるだけではなく、ユーザー調査に価値があることも明らかにできる。
例を挙げると、最近、高等教育機関のWebサイトをデザインしている人たちのあいだで、とある大学の新サイトのデザインの善し悪しが大論争になっていた。議論に参加するかわりに、我が社のあるUX専門家はたった1日でそのサイトのテストを実施した。真実の答えはすぐに得られた（それは悪いデザインだった）。
スケッチを作成してテストしよう（そして必要ならそれを繰りかえそう）
反復デザインという概念は新しいものではないし（1993年の記事を参照）、 デザインビジョンのテストを何度も行うことを重視する、リーンスタートアップ運動も反復デザインの認知度を上げるのに一役買った。しかしながら、リーン転向者がよく唱える「デザインして、構築して、ローンチして、評価する」というスローガンは誤解を招きかねない。そこから推測されるのは、製品とは、ユーザーがテストするシステムのためにコーディングしてローンチされ、その後に評価されるものだ、ということである。しかし、これは誤解である。
プログラムの1行目を書く前に、まずスケッチやワイヤーフレームをテストすることによって、クライアントの開発時間をスピードアップさせるという手助けを我々は長年行ってきた。リソースを無駄遣いして、ユーザーが欲しいものではなかった、とか、重大な欠陥があった、という知るには遅すぎることを確認するだけのために、何か動くものを作るのはやめよう。開発の各フェイズで自分たちのコンセプトについての疑問を検討し、仮説をテストするためのシンプルな中間生成物を作り出そう。繰り返し実施することで完成度は上がる。今、すぐ発売できるはずと思うのはやめよう。
結論
ユーザーエクスペリエンスとはユーザーあってのものである。ユーザーインタフェースを創造するには複雑で入り組んだ決断を伴う。ユーザー調査はあなたがたの目標達成を手助けしてくれるツールになる。
非常によく考えられているデザインですら、実際のユーザーでテストするまでは仮説だ。様々な調査をすることで様々な疑問に対する答えは得られる。そうしたツールを理解し、使いこなそう。ユーザーを考慮しないことは選択肢に入らない。
この記事を1行でまとめると次のようになる：
UX – U = X
（ここでの「X」は「それをしてはならない」ということを意味する）。
