第21章

ユーザーはタスクで考えない

ユーザーが考えているのは、作業ではなく、得たい結果

これまで、さまざまなフローをデザインしてきたはずだ。タスクフロー、ユーザーフロー、初期案内のフロー。すべてのステップを図にし、各画面に名前をつけ、完了率を測ってきた。ステップ、画面、離脱箇所を長く見つめていると、いつの間にか、ステップこそがデザインの本当の単位だと思うようになる。たいてい、そうではない。

ユーザーがプロダクトを開くのは、タスクを完了したいからではない。生活のなかで、何かを変える必要があるからだ。お金の不安を減らしたい。大切な人とつながっていたい。やるべきことを片づけて、もう考えずに済むようにしたい。ただ請求書を送り、支払いを済ませ、旅行を予約して、日常に戻りたいだけのこともある。こちらが用意した流れは、その大きな目的のほんの一部を助けるものにすぎない。タスクは手段だ。ユーザーが気にしているのは、それが終わったあと、自分にとって何が変わるかだ。

タスクより、目的が重要だ

2002年、Edwin LockeとGary Latham は、目標が行動をどう動かすかについて、35年にわたる研究をまとめて発表した。結論は明確だった。人間の行動の大半を直接動機づけるのは、意識された目標だ。明確で具体的な目標があれば、行動はその達成に向けて組み立てられる。なければ、行動は漂う。

Richard RyanとEdward Deci の自己決定理論は、さらに深い層を加える。人は、ただ目標に向かうだけではない。三つの基本的な心理的欲求を軸に動いている。自律性（自分の行動を自分で決めている）、有能感（大切なことが、よりうまくできるようになっている）、関係性（ほかの人とつながっている）だ。これは画面単位の欲求ではない。ドロップダウンメニューで選択を終えたこと自体を、意味のある前進とは感じない。こうした欲求は、タスクより上の階層にある。

デザインは、放っておくとタスク単位の話になりがちだ。タスク分析は、ユーザーの行動を、観察できる個々の動作に分解する。それは役に立つ。だが、完了を、もっと大きな何かに向かう一歩ではなく、成功そのものとして扱うと、落とし穴になる。

ミルクシェイクの研究が示したこと

1990年代、Clayton Christensenの研究チームは、あるファストフードチェーンから、ミルクシェイクの売上を伸ばす手助けを頼まれた。通常のやり方なら、味、濃さ、価格など、ミルクシェイクに何を求めるかを顧客に聞いただろう。チームは違うことをした。一日店内にいて、いつ、誰がミルクシェイクを買うかを観察した。

見えてきたのは、ミルクシェイクそのものを超えた話だった。売れたミルクシェイクの半数近くは、午前9時より前に、一人で車を運転する人が買って持ち帰っていた。研究者は、さらに聞いた。この人たちは、どんな仕事をしてもらうために、ミルクシェイクを雇っているのか。答えは、通勤だった。長い運転、空いている片手。時間をつぶせて、昼食まで腹持ちもするものが欲しかった。ミルクシェイクは飲み終わるまで時間がかかり、カップホルダーに収まり、ほとんど注意を払わずに飲める。人々は、単に飲み物を買っていたのではない。朝の困りごとを解決していた。

チームは、飲み物について聞いていた。ユーザーは、通勤の問題を解決しようとしていた。

完了と価値は、同じではない

すべてのステップを完了できても、ユーザーが離れていくプロダクトはつくれてしまう。仕組みは動いているが、目的は果たされていない。初期案内に問題があるからではなく、生活に望んでいた変化が、いつまでも訪れないから離れるのだ。

このずれは、運動の記録は簡単なのに、運動自体は続かなくなるフィットネスアプリに現れる。取引の分類は速いのに、お金を自分で管理できている感覚が持てない家計管理ツールにも現れる。プロジェクト管理ソフトでも同じだ。すべてのチケットに担当者を割り当て、すべての期限を設定できるのに、仕事が整理できていないと感じる。タスク単位では、プロダクトは機能している。それでも、求めていた結果は得られない。

Nielsen Norman Group のタスク分析の枠組みは、この違いを明確にしている。タスクとは、始点と終点がある、観察可能な活動であり、目的とは異なる。フォームへの入力はタスクだ。融資の承認を得ることは目的だ。その目的のために、ユーザーはプロダクトを雇った。フォームは、その手段にすぎない。

目的から始める

フローを描くのをやめる必要はない。フローは役に立つ。ただ、最初の四角を描く前に、目的を言葉にしよう。

ユーザーのタスク上の目標ではない。「購入手続きを完了する」「アカウントをつくる」でもない。生活のなかでの目的だ。プロダクトが役立ったら、その人の生活はどう変わるのか。具体的に何を変え、何を避け、何を実現しようとしているのか。一文に書き、具体的にする。そのうえで、フローを見て率直に問う。どのステップも、その一文の実現にユーザーを近づけているだろうか。それとも、主にプロダクト側の都合を満たしているだけだろうか。

大きなデザイン上の判断をする前に、この確認をしよう。各機能は、フローだけでなく、目的の役に立っているか。そして、完了率90％という数字は、ユーザーが本当に求めていたものを得られたことを意味するのかと問う。この問いは、あまりにもよく飛ばされる。

タスク単位にとどまるデザイナーは、ちゃんと動くのに失敗するプロダクトをつくれてしまう。機能はそろっている。フローは最後まで進められる。それでもユーザーは離れる。振り返りでは、誰も理由を説明できない。指標は全部、問題なさそうだったからだ。

これまでデザインしてきたすべてのフローは、理解した目的か、推測した目的の上に成り立っていた。うまくいかなかったとき、弱かったのは、その推測だった可能性が高い。珍しいことではない。よくあることだ。