マニフェスト(名詞)―政府、主権者または組織によって発行された意図、意見、目的、または動機の公的な宣言。Dictionary.com
私は普段「マニフェスト」という単語を聞くと身震いしてしまいます。その主な理由は、それが政治的に使われる単語だからで、マニフェストは信用できない政治家が、長ったらしい予備選挙の公約の中で何度も発言している言葉という印象が強いからでしょう。票を稼ぐために人々を騙したら最後、完全に無視されてしまうでしょう。
私が身震いせずに聞くのを喜べる唯一のマニフェストは、アジャイルマニフェスト(Agile Manifesto)です。政治的なマニフェストではなく、ソフトウェア開発の原則をいくつかまとめたものです。
アジャイルマニフェストは不満から生まれました。伝統的なウォーターフォールモデルでは、すべての要件が前もって定義され、デザインの作成、実装、テストが非常に直線的に行われていました。このような方法は、ソフトウェアを提供する際には非常に手間がかかり非効率です。
そして2001年2月、ご存知の方も多いだろう17人の開発者は、それまでの手法に対する不満から、協力してより良い方法を考え出すことを決意しました。それこそがアジャイルソフトウェア開発です。そしてこの勇敢な新しいアプローチの原則を伝えるのを助けるために、彼らは以下のアジャイルマニフェストをまとめました。
私たちは、ソフトウェアを開発することで、あるいは開発を手助けすることで、より良い開発方法を明らかにします。この作業を通じて、私たちは次の4つに価値を見出しました。
- 「プロセスとツール」より「個人とインタラクション」
- 「包括的なドキュメント」より「機能するソフトウェア」
- 「契約交渉する」より「顧客と協力する」
- 「プランに従う」より「変化に対応する」
つまり、文の左辺のアイテムにも価値がありますが、私たちは右辺のアイテムをより評価するということです。
アジャイルマニフェストに触発されたことで、私は自身のUXマニフェストをまとめ、自分が重要なUXの原則の一部だと信じていることを要約して伝えようと思います。どうぞご覧ください。
「縦割りの仕事」より「協力」
私は、UXデザインは完全にチームスポーツであり、一丸となることでもっとも機能すると以前に書いたことがあります。協力は優れたUXデザインの鍵です。協力相手には、エンジニアやドメインの専門家、ユーザー事業のステークホルダーなど、さまざまな職業が挙げられるでしょう。
UXは、ユーザーのニーズ、技術の制約、ビジネスの目標という3つが交差する位置にあるため、共同作業にほかなりません。別の考え方として、個人をフェンスで隔てるような考え方もあり、残念ながら未だに行われているデザイン代理店もあるようです。
周りを頼らないデザイナーは、孤独な作業場にこもって、一見すると素晴らしいデザインを制作します。そのようなデザインが見掛け倒しなのは、デザインがほとんど仮説に基づいているため、詳しく検査すれば問題が見つかるからです。
そして、質の低い開発チームにそのデザインが手渡され、実装されます。ステークホルダーは自分たちの意見が反映されていないと文句を言い、開発チームもデザインが実装不可能だと文句を言い、哀れなユーザーは、自分たちのニーズに対応できていないデザインとともに取り残されるしかありません。
「静的な文書」より「インタラクティブなプロトタイプ」
私は要件を文書に記すのが嫌いです。本当に大嫌いです。芝刈りやCelebrity Big Brother liveを見ることのような、ただ魂を擦り減らす行為です。要件のドキュメントは決して読まれることはありません。また、デザインや要件が変更されるたびに何度も更新する必要があり、詳細をどれだけ記載するべきか決断するのが難しいことがあります。あまりにも細かくまで記載すると開発チームが叫んで逃げ出すでしょうし、あまりにも少ないと、彼らは多くの質問をしなければならず、ドキュメントの存在意義に疑問が持たれるでしょう。以上の理由から、私はインタラクティブなプロトタイプのファンです。
インタラクティブなプロトタイプは、デザインやデザインの要件を伝える最良の方法です。というのも、デザインがコンテキストの中でどのように機能するのかを示せるからです。ユーザーのクリックやタップで何が起きるのかを詳しく書き記すのではなく、単にプロトタイプのインタラクションとして組み入れることができます。
エンジニアはプロトタイプが好きです。なぜなら、そのデザインがどのように機能するのか伺えるからです。ステークホルダーも、デザインが実際に動くのを見られるのでプロトタイプを好みます。UXデザイナーもまた、実際にデザインがどのようなルック&フィールになるのか観察できるので、プロトタイプが大好きです。そして何よりも重要なことに、ユーザーがデザインを直接体験しフィードバックすることができるため、プロトタイプは、ユーザーからのフィードバックを得るのに最適なのです。
現在では豊富なプロトタイピングツールが存在し、インタラクティブなプロトタイプを恐ろしく簡単に、素早く作成できるようになりました。UXのプロトタイピングツールのガイドの全文についてはこちらをご覧ください。きわめて詳細な要件文書を書く時代はもう終わりました。
「ステークホルダーのためのデザイン」より「ユーザーのためのデザイン」
「UX」はもちろん「ユーザーエクスペリエンス」の略です。私はいつもなぜ文法的に正しい「UE」ではなく「UX」なのかと不思議に思ってきました。「UX」のほうが少し響きが素敵だからでしょうか。
ステークホルダーがデザインについて指示して来るたびに、「UX」が何の略であるのかを思い出してください。なぜなら、デザインしているのは、究極的にはステークホルダーのためではなく、ユーザーのためだからです。確かに、最終的に資金を払うのはステークホルダーなので、彼らを満足させる必要はあります。しかし、デザインの成功と失敗を決めるのは、ステークホルダーではなくユーザーです。
素晴らしいUXとは、そのようなとらえどころのないスイートスポットを見つけることです。その場所は、ユーザーのニーズ、技術の制約、ビジネス目標の間に存在します。ステークホルダーは真っ先にビジネス目標を考えるでしょう。技術チームはまず技術の制約について考えるはずです。したがって、ユーザーに注意を向けられるかどうかは、UXとUXデザイナーがユーザーのニーズを最優先に考えられるかどうかに掛かっています。
「ユーザーが欲しがるもの」より「ユーザーが必要とするもの」
私は二児の親です。そのため、私もすべての親と同じように、子どもが欲しがるものは、多くの場合子どもが必要とするものと大きく異なることを痛感しています。私がいつも子供たちの欲しがるものあげたら、チョコレートやケーキ、アイスクリームだけを食べ、Dora the ExplorerやPower Rangersを一日中見ながら過ごすことになるでしょう。
Steve Jobs氏の有名な発言に「自分が何が欲しいのか知ることは、顧客の仕事ではない」というものがあります。そう、違うのです。ユーザーが何を必要としているのか見つけ出すのは、UXデザイナーの仕事です。私は以前、ユーザーがいつも正しいとは限らない理由について書いたことがあります。単にユーザーに質問しても、何を必要としているのか知ることはできません。ユーザーが抱える問題や目標、不満、モチベーション、するべき仕事についてきちんと理解する必要があります。もちろんユーザーに質問してデザインプロセスのあらゆるステップに彼らを加えることもできますが、ユーザーがUXデザイナーの仕事を肩代わりしてくれるとは期待しないでください。
「ユーザーが言ったこと」より「ユーザーがやったこと」
私は長年にわたって、何百ものユーザビリティテストのセッションを開催してきました。何時間も人々がさまざまな技術を使っているのを見てきました。これらのセッションの共通のテーマの1つは、ユーザーが言うことは、ユーザーのやっていることと大きく異なるということです。次のような発言を聞いたことはないでしょうか。
私:それで、全体的にどれくらい使いやすかったですか?
参加者:ああ、楽勝でした。まったく問題はありません。
私:本当に? 何も問題ありませんでしたか?
参加者:ありません。
私:では、あなたが完了できなかった3つのタスクについてはどうでしょうか? あるいは、先程「脳無し」によってデザインされていると言っていた画面についてはどうでしょうか?
参加者:あぁ、でも、それ以外は本当に使いやすいものでした。
ユーザーは、礼儀正しいために使いにくかったとは言えなかったのかもしれませんし、自身の卑劣な行為を認めたくなかったのかもしれません。そもそも、ユーザーは問題が発生したことを覚えていないかもしれません。ピーク・エンドの法則(訳注:人間は過去の経験のうち、ピーク(最高か最悪)と最後の状況だけしか記憶しないという法則)によれば、私たちは経験の一瞬だけしか覚えていないものだそうです。誰かに製品が使いやすかったと言われたら、自分が異なったように知覚しても、おそらく彼らは正しく理解していると考えるでしょう。
ユーザービリティテスト、ユーザーの観察、使用データの取得、あるいは単に行ったタスクや仕事について質問するとしても、本当に信頼できるのはユーザーの発言ではなく、ユーザーの実際の行動なのです。
「仮説」より「ユーザーのインサイト」
私は以前に、デザイナーは調査をすべきで、調査者はデザインをすべき理由について書きました。ユーザーリサーチとそれによって得られたインサイトは、優れたUXデザインの屋台骨です。ユーザーのインサイトがなければ、デザインが仮説に基づいて構築されているということです。仮説に基づいたデザインは、不安定な基盤の上に建てられた家のように崩壊することになります。
仮説は必ずしも悪いものではありません。作業のなかで仮説を前進させ、それに沿って実際に検証をするのであれば、仮説はデザインを進める有効な方法です。しかし、偉大な Steve Jobs氏の発言にあるように、「人間の経験を広く理解しているほど、より良いデザインを手に入れることができる」のです。仮説ではなく、ユーザーのインサイトを基にUXデザインを進める必要があります。
「ユーザー中心デザイン純粋主義」より「プラグマティズム」
数年前、私はUX Cambridgeで『どのようにUCDの習慣をやめ、Lean UXを愛することを学んだのか』という威勢の良いタイトルでプレゼンテーションをしました。ちなみに、トークはオンラインで見ることができます。このトークでは、ユーザー中心デザイン(UCD)に関する自分の経験と、新しい定説であるLean UXを私が受け入れた経緯について話をしました。
私とUCDが愛憎関係にあるのがおわかりいただけたでしょう。ユーザーをデザインプロセスの中心に置くというアイデアは大好きです。しかし、UCDプロジェクトはしばしば地に足がついていないことがあり、時間も費用もかかり、また必ずしも常に何かを提供できるとは限りいません。これらの原因は、UXデザイナーがUCDに対して純粋になりすぎるからだとも考えられます。
「リリースについて考え始める前に、少なくとも12人のユーザーとユーザビリティテストをする必要がある。あぁ、ユーザーリサーチの予算だけでこんなに必要になるなんて!」
私はもちろんLean UXのファンですが、私がもっとも重要だと思うのは、実用的であることです。前述のトークの中で、私はMP3の考察をしました。貴重なHi-Fi設定に大金を費やすオーディオマニアの方々は、CDやLPレコードとMP3を比較して怒鳴り散らしています。彼らは、MP3の高音域はいつも酷い、音がとても平たくて人工的だ、MP3はリスニング体験を台無しにするなどと不平を言うでしょう。しかし、私たちのほとんどは、元々ノイズの多い環境で小さなヘッドフォンや安価なスピーカーを介して聴くため、MP3で十分です。より美しく豊かなサウンドを提供するフォーマットを持つのは嬉しいことですが、MP3のように実用的な品質であれば、99%問題ないのです。
同じようなプラグマティズムをUCDにも適用する必要があります。UCDによってもたらされる利益を提供するだけで十分で、それ以上は要りません。UXリサーチやデザイン活動に柔軟に対応することを恐れず、UCDの純粋主義にならないようにしましょう。
私のUXマニフェスト
以上が私のUXのマニフェストです。あなたの考え、そして、あなたのUXのマニフェストにはどのような指針がありますか? ぜひ考えてみてください。
- 「縦割りの仕事」より「協業」
- 「静的な文書」より「インタラクティブなプロトタイプ」
- 「ステークホルダーのためのデザイン」より「ユーザーのためのデザイン」
- 「ユーザーが欲しがるもの」より「ユーザーが必要とするもの」
- 「ユーザーが言ったこと」より「ユーザーがやったこと」
- 「仮説」より「ユーザーのインサイト」
- 「ユーザー中心デザイン純粋主義」より「プラグマティズム」
注:左側のアイテムにももちろん価値はありますが、私は右側のアイテムをより評価するということです。