読者です 読者をやめる 読者になる 読者になる

株式会社ネクスト エンジニアBlog

不動産・住宅情報サイト HOME'Sを運営する株式会社ネクストのエンジニアが提供する技術ブログです。エンジニアに役立つ情報の発信や、弊社エンジニアの活動を中心にお届けします。

デザインで失敗すること

デザイン

大坪と申します。先日見つけた動画の内容が興味深かったので、自分が理解できたところだけ紹介します。


Airbnb Design Talk with Braden Kowitz 12.12.12 ...

スピーカーはBraden Kowitz氏。現在はGoogle Ventureのデザインパートナーであり、以前はGMail, Google Spreadsheetsのデザインにも携わったとのこと。このプレゼンテーションの中でKowitz氏は「デザインプロセスにおいて、失敗することの重要性」を説いています。

プレゼンの最初に「失敗したデザインの例」として悪名高いiMacの円形マウスの写真を出します。確かに人目をひくデザインをしていますが、「そもそもどちらが上なのか」わからず困った経験をしたのは私だけではないと信じたい。Kowitz氏の表現を借りれば

「カーソルを上に動かそうとマウスを操作すると、カーソルはとんでもない方向に飛んで行く」

製品でした。実際この後にAppleがデザインしたマウスは、仮に丸みを帯びた形であっても持っただけで方向がわかるようになっています。つまりこれは明らかな「失敗したデザイン」だったわけです。(私はApple原理主義者ですが、このことを認めるくらいの柔軟性は持ち合わせています)

さてKowitz氏が最初に取り組んだデザインの仕事は失敗に終わったそうです。彼は一人でコンセプトをつめ、「まだ人に見せられる段階じゃない」と途中のフィードバックも拒み、そして3ヶ月後に「これが成果です」とやったところ結果を誰も理解できなかった。なぜこのようなことが起こるのか?

氏は"Design Blindness”という言葉を用いて理由を説明します。デザインを行う人間は「これは行ける」というある種の確信をもって作業を始めるわけですが、その瞬間から自分のデザインを客観視することができなくなる。それ故Critique Early & Often:早い段階から、できるだけ頻繁に「批評」してもらうことが必要になる、と。

しかし自分の仕事について「批評を受ける」ことは勇気のいることです。特に「まだできていない」作品に対してあれこれ文句を付けられるのは楽しくない。しかし良いデザインをするためには、デザイナーは「失敗」に対してオープンな姿勢を取る必要がある。ここから氏は3つのトピックについて語ります。

まず「楽器の練習」

ピアノに関して本を何冊か読めば、カーネギーホールでピアノを演奏できるか、といえばそんなことはない。もちろん最初にインストラクションは受けるのですが、自分でやってみると指はうまく動かない。何度も繰り返しているうちにようやく目標としているレベルの演奏ができる。このプロセスは「ピアノの失敗」ではなく「ピアノの練習」と呼ばれます。

それ故「デザインの失敗」ではなく「デザインの練習(Practice)」と呼ぶべきではないかと氏は提案します。「失敗」は学ぶことの一部であり、それ無しに上達-あるいはデザインが良くなることはありえない、と。

2番めは「軍艦」。軍艦がどうしたって? 氏が取り上げたのはGmail。Gmailは軍艦のように複雑で巨大なプログラムです。この画面にChat機能を入れようとした際にどんな「デザインの失敗」があったか。最初のデザインはGoogle社内ではとても好評。次に「普通の人」にテストしてもらった時何が起こったか?テストを行う側が最初のメッセージを送ったところ、被験者は

「どうやったら入力した文字が送信されるのかわからず、返答の文字をタイプした後固まってしまった」

そうです。「慣れれば」エンターキー(リターンキー)を押した瞬間文字が送信される、という方法は効率がよいのですが、初めて使う人間にとってみると「送信ボタンはどこ?」となってしまう。よし。では「エンターキーを押すとメッセージが送信されます」という表示をつけよう。

改良されたデザインでテストを行ったところ、結果はまた「失敗」でした。チャットで呼びかけがあったときにポップアップウィンドウを開くようにしたのですが、ユーザはそれを「またウザい広告か」と内容を確認せず反射的にウィンドウを閉じてしまう。

Googleのデザイナーが間抜けばかりということはまずありえない。ではなぜ「良いデザイナー」が取り組んでいながら、これほど失敗を繰り返すのか。氏が得た結論は「デザイナーは普通ではない」から。

ここで氏は「この中でスマートフォン2つ持っている人?」と呼びかけます。おそらく会場の何人かが手を挙げたらしい。しかしスマートフォン所有率が5割とか6割とか言っているときに2台もっているなんてのは明らかに「おかしい」わけです。しかしその「おかしいデザイナー」は「普通の人」の感じ方、見方を推し量らなくてはならない。

つまりデザインというのは「軍艦ゲーム」(懐かしい!)のようなもの。D-3とか座標を言うと相手は「おっと命中だ」とか教えてはくれる。しかし結局相手の軍艦がどこにあるかは分からない。つまりデザインにおいて「失敗」は避けがたい要素なわけです。

3番目に挙げられたのは「ユーザがどんどん変化している」こと。今日Webサイトを使うユーザは2年前のユーザと同じではない。具体的に挙げられたのは

「チェックアウト時(?)に押して貰う黄色いボタンをどこに配置すればユーザは戸惑わないか」

というデザイン上の問題。以前同様の画面を設計した際ユーザスタディを行ったことがあったので、その経験から最も良いと思われる位置にボタンを配置しました。しかし視線のヒートマップをとってみるとうまく機能しない。逆に以前の経験では「悪いデザイン」と思っていた配置が一番よい成績を収めた。

つまりこの2年の間に、ユーザが普段使うサイトのデザインが変化し、それにともないユーザがどういうデザインをすれば戸惑わないか、という「正解」も変化してしまった、と氏は言います。この事を

"PEOPLE ARE MOVING TARGET" 人々は動いているターゲットだ

というフレーズで表現する。

例えば一番目に挙げた「Gmailのチャット機能」の経験をそのまま今生かせるだろうか。氏は懐疑的です。多分今なら「チャット」といえばFacebookメッセンジャーとか(日本ならLINE)にユーザは慣れている。つまりチャット機能に期待するものが変わってしまっているのです。

それ故仮に経験がある良いデザイナーであっても失敗は避けられない。従って失敗を恐れ3ヶ月間努力してBig Surpriseを食らうよりは、Little Surprise:小さな驚き をたくさんもらったほうがいい、と主張してプレゼンテーションを締めくくりました。

このあとの質疑応答にいくつか興味深いものがあったので紹介しておきます。

「どのタイミングでレビューをするべきか?」という質問に対しては、例えば2週間単位とかで定期的に行うのがいいのではないか、と回答しています。初期の段階ではほとんどみせるものが無いわけですが、その際にはユーザのニーズを探り、簡単なスケッチを提示する。デザインが進むにつれユーザにみせるものが出来上がっていくわけです。

面白い指摘と思ったのは「プログラムを開発する際にはテストを繰り返し、デバッグすることが常識になっている。なぜデザインではそれができないのだろう」という質問でした。考えてみれば近年ユニットテストとか、Continuous Integrationというようにプログラム開発においてテストの比重は高まっています。これに対しては「デザインにおいては、まだテストがプロセスの一つとして認知されていないからだろう」との回答。

こうした「デザインの途中でフィードバックを受ける」ことの重要性は誰もが頭ではわかっている。しかしなぜそれをしないかといえば「ボロカスにけなされるのではないか」という恐れからではないか。こうした指摘に対する答えは

「レビューの仕方はずいぶん様々で、極端な例だと主観だけで相手を貶しまくり、批判されたデザイナーは帰って枕を涙で濡らすようなものもある。その逆の極端な例は皆が妙に優しく思った事をちゃんと言わないものだ。ところがその中庸で非常にうまく”批評”をしている例もある。どうやってそうした方法を身につけたのか、と聞いた所”学校で習った”とのことだった。従って良いレビューのやり方は学習によって身に付けることができる」

いやこっちが聞きたいのはその「良いレビューの仕方」なのだが、、と思うわけですが、少なくとも正しいレビューの方法は「天性のものではなく、学べるもの」というのは期待が持てるメッセージでは有ります。

いや、それでもレビューを受けて凹むのは怖い、どうすれば「最初の恐怖」を乗り越えてレビューを受けられるようになるか、という質問に対しては

「たくさん数をこなすこと。そうすればレビューで批評されても自分はそこから何かを学んでよりよいデザインができる、と確信をもてるようになる」

と返答がありました。デザイナーであってもなくても批評されるのは心理的に堪えるものです。ボロカスに言われると「ああ、この世の終わりだ。どこか人里離れた洞窟にでもこもろうか」と思うわけですが、そうした経験を何度かつみかさね、それでも自分の首がつながっている、という自信を持てれば、レビューを受けることに積極的になれるかもしれません。


質問にもありましたが、確かにプログラムを書くとき「自動テスト」を恐れる人はあまりいない。(恐れたほうが良い人がいるのも確かですが)しかしきっと遠い昔には「俺が書いたプログラムにはバグがないから、テストは不要だ」と真面目な顔で主張していた人もいたのでしょう。

同じようにデザインもテストを習慣づけるべきではないか。ではテストを行うとして、誰に聞けばいいのか。間違った相手に間違ったタイミングでテストすると恐ろしい事が起こる、、とか悩みは次の段階に行くわけです。

このビデオを見ていて、ある人が書かれていた体験談を思い出しました。

最後の学年のアート&ビジネスというクラスでした。 3ヶ月くらいかけて完成させる課題で、◯△□の基本的なシェイプを使って最終的には何かプロダクトのモックアップを作るみたいな感じだったと思います。 (中略) そして、締め切りの日の授業。みんなは自信作を早く見せてくてニコニコしてた中、先生は言いました。 「はい。みんな課題持って来ましたか?では、机の上に出して、紙の人はそのまま破り捨てなさい。立体物の人は壊してゴミ箱へ捨てなさい。」 生徒全員しばらく唖然とした状態で沈黙。その後、泣き出す人、すごい剣幕で怒り出す人、教室から出ていっちゃう人、多くの生徒はそのショックをそれぞれに表現していました。 (中略) そして、怒っている生徒に向けて先生はこう言いました。 「(中略)みんなプロのデザイナーとしてこの先の人生食っていこうと思っているなら、こんなことは日々起こること。これでショックを受けてやる気をなくしているなら、クリエイティブな職種に向かないから違う道に進んだほうがいい。クライアントの中にはアイデアや作品を見ることもなく破り捨てる人もいる。わたしもそんなこと毎日のように経験してるぞ。」

引用元:「傷つかない技術」を体験した授業(現在リンク切れ)

少なくとも見てもらえるのはマシなほう。であれば「これは失敗ではなく、Practice」と思い切る訓練をするべきなのかもしれません。以下に引用する言葉は、デザインに限らず広く必要な心構えと思います。

多くのまだ経験の浅いクリエイターの人は、作品や仕事にダメだしされてるのに、人格を否定されたような気分に陥って、自分を否定されたように思って、まだ人に認められるような作品を作る前に辞めてしまったり、上司やクライアントと喧嘩したり、病んでしまったりってあると思います。 引用元:同上

などとエンジニアの端くれである私が、デザインプロセスについて長々書いているのは、そろそろ作ってきたものを社内でレビューしてもらわなくちゃいけないのでその心理的プレッシャーから逃れるため、ではもちろんありません。