第9章

あなたの知識こそが問題

専門家ほど、自分の仕事を正しく評価しにくい理由

自分のデザインをレビューしているとき、初めて使う人と同じものを見ているわけではない。何週間も見続けてきた目の前の画面は、頭の中では、それについて知っているあらゆることに覆われている。自分がつくった機能を動かす、あのボタン。その働きは、すでに知っている。目がそこに向いた瞬間、きちんと読む前に意味が浮かぶ。その時点で、もうインターフェースそのものを読んではいない。つくったときの記憶を読んでいる。初心者は、そうした背景を何も持たずに同じ画面にやってくる。ボタンを読む。あるいは、読もうとする。クリックできることにさえ気づかないかもしれない。

私も、これ以上ないほど明快だと思っていた画面で、そうなるのを見てきた。

知っているからこそ、見えなくなるもの

1989年、経済学者の Colin Camerer、George Loewenstein、Martin Weber は、Wharton で一連の実験を行った。問いは単純だった。何かを知っている人は、それを知らない人にどう見えるかを予測できるか。できなかった。情報を与え、その情報を持っていないつもりで考えるよう求める。毎回、うまくいかない。しかも、知っていることが多いほど、成績は悪くなる。Camerer のチームは、これを知識の呪いと呼んだ。一度理解が頭に入ると、ただ持ち歩くだけでは済まない。ものの見え方を妨げ始める。

問題は性格ではなく、記憶だ。なじみのあるものを見るとき、脳は立ち止まって丁寧に調べない。意識に上らないところで、素早く組み立て直す。だから、自分がデザインした画面は、もう初めて見るものには見えない。情報のそろった画面に見える。曖昧なラベルも、十分に明確に感じられる。奥にしまい込んだ機能も、ほとんど隠れているように見えない。ユーザーが持ったことのない背景知識で、すべてを埋めてしまう。

Carl Wieman は、大学の物理教育でこの問題を長年研究した。結論は明快だった。「何かを知っていると、それを知らない人の立場から考えるのは、きわめて難しい」（英語からの翻訳）。Wieman が扱っていたのは、自分には自明な概念で学生がなぜ苦労するのか理解できない教授たちだった。そのまま、テストを見ながら「どうして気づかないのか」と思うデザイナーの説明にもなる。

何かを知っていると、それを知らない人の立場から考えるのは、きわめて難しい。
— Carl Wieman（英語からの翻訳）

Photoshop は専門家のためにつくられた

Photoshop は、プロの画像制作の作業工程から生まれた。Adobe 自身の歴史によれば、ソフトウェアが形になりつつあった頃、John Knoll は Industrial Light & Magic で働いていた。また Adobe は、Photoshop の主なユーザーは長年、プロのデザイナーや写真家だったと述べている。この背景が重要だ。マスク、調整レイヤー、描画モード。これらは初心者向けの概念ではなかった。基本的な語彙だった。大工がいちいちノミの用途を説明しないのと同じように、Photoshop を形づくる人たちも、インターフェースが初心者に何を理解するよう求めているのかを、実感できなかった。（Photoshop の起源についての Adobe の説明、Photoshop の主な利用者についての Adobe の説明）

初めて使う人は、苦労しなければならなかった。Adobe 自身の入門教材でさえ、専門家には当たり前の概念、特にレイヤーを、立ち止まって教える必要がある。今どのレイヤーを選んでいるのか。なぜ編集が反映されないのか。この二つのブラシは何が違うのか。ツールをつくっている人には、それらがもう問題に感じられなかった。Nielsen Norman Group の認知的ウォークスルーに関する研究は、まさにこの点を述べている。

初めて使う人の体験を模擬する体系的な評価があるのは、まさにデザイナーが自力ではその体験を再現できないからだ。知識が、それを妨げる。
（英語からの翻訳）

Adobe はやがて Lightroom を発売した。そして Photoshop Elements を出した。Adobe は現在、後者を「賢く、使いやすい写真編集ソフトウェア」（英語からの翻訳）と表現し、「誰でも」（英語からの翻訳）が使えて「経験は不要」（英語からの翻訳）と説明している。Photoshop をつくった人たちは、同じ製品をさらに磨くだけでは、初心者にとって明快なものにできなかった。別のものをつくらなければならなかった。（Adobe Photoshop Elements）

その場に初心者はいなかった

実際のチームでは、たいていこう進む。デザイナーが操作の流れをレビューし、明快だと判断する。開発者がエラーメッセージを読み、十分わかりやすいと思う。プロダクトマネージャーが初回利用の案内のデモを見ても、誰も疑問を口にしない。みんながうなずく。ところが、初めて使う人は「続ける」を押し、そのボタンがこれから何をするのか、まったくわかっていない。

ユーザーがやってくると、みんなが簡単だと思っていた手順で止まる。何週間もかけてつくった機能を無視する。まっすぐ進むはずのところで、横道にそれる。その場の人たちは背景をすべて知っているので、それを見てもなお、驚いたような反応をする。

振り返りで行き着くのは、いつも同じことだ。チームの中にしかなかった背景知識を、ユーザーも持ってやってくると思い込んでいた。レビューではまったく問題なさそうだったリリースの後で、そうなるのを見てきた。

自覚するだけでは解決しない。Camerer の研究では、知識の呪いについて知らせても、判断への影響はほとんど変わらなかった。それについて読み、理解し、ほかの人に説明できても、自分の仕事の穴は見落としうる。私も、疲れた金曜日にはいまだにやってしまう。バイアスの存在を知ることと、その影響を超えて見ることは、別の仕事だ。

初めて見る人に使ってもらう

最も役立つのは、外からの視点だ。そのプロダクトを本当に一度も見たことのない人を探そう。キックオフにいた同僚ではない。別のチームにいても、雑談で話を聞いたデザイナーではない。背景をまったく知らない人に来てもらう。プロダクトを目の前に置く。黙って反応を観察し、沈黙を埋めようとしない。どこで動きが遅くなり、読み違え、諦めるのかを見る。

その一つひとつが、自分の知識で埋めていた隙間を示している。知識の呪いは、考えれば抜け出せるものではない。Chip と Dan Heath は Harvard Business Review で明確に述べている。デザイナーと、デザインする相手との間にある、最大の障害だと。つくるときに役立った専門知識が、同時に妨げにもなる。初めて見る人にはまったく読み取れないことに気づかず、同じ画面を磨き続けるデザイナーを、私は見てきた。

大切なのは、何をつくったかではない。初めて見る人に、何が見えるかだ。