デモではものができあがっているように見せない

Kathy Sierra / 青木靖 訳
2006年12月27日

(アルファ版のような)開発中のものを私たちが世間や、クライアントや、ボスに見せるときには･･･彼らの期待のレベルを設定することになる。これは3通りの方法でやることができる。磨き上げられたモックアップで幻惑するか、プロジェクトの現状に合ったものを見せるか、ほとんどできていないものを見せながら順調に進んでいるから「信用しろ」と言っていら立たせるかだ。

結論を言うなら:

どれくらい「できている」ように見えるかは、実際どれくらい「できている」かに合わせるべきだ。

ソフトウェア開発者はみんなそのキャリアにおいてこのことを何度も思い知ることになる。しかしテクニカルライターもまた、デスクトップパブリッシングツールによって同様の問題に直面する——フォントやレイアウトが完璧に仕上げられたドラフトを誰かに見せるなら、その人はあなたが考えるよりももっと完成していると思うのだ。私たちが今どの辺にいるのかということと、みんな私たち がどの辺にいると受け取るかということは、適合させておく必要がある。

Joel Spolskyはこのことをずっと以前に、「氷山の秘密、明らかに」の中で書いている。その秘密とは:

「氷山の90%は水面下にあるというのは知っているよね? 実は、多くのソフトウェアもそうなのだ——それは作業の10%を占めるこぎれいなユーザインタフェースと、プログラミング作業の90%を占める見えない部分とからなっているのだ･･･こ れは別に秘密ではない。秘密なのは、プログラマでない人間はこのことを理解しないということだ」

彼は続けてこの命題の系を挙げている:

「非プログラマに90%まずいユーザインタフェースを持つ画面を見せたなら、彼らはプログラムが90%まずいと思う」

それに

「非プログラマに100%素晴しいユーザインタフェースを持つ画面を見せたなら、彼らはプログラムがもうほとんどできあがっていると思う」

系の残りや、彼が他にどんな話をしているか知りたければ、Joelのアーティクルを読むといい。

ロバート・スコーブルも、Vistaの初期のまがい物のプロトタイプの話の中でこの問題について 触れている。

「後になって･･･私たちが見ていたのはみんなMacromedia Directorで作ったムービーだったということを知った。それはすごくクールに見えた･･･それがどれだけ私たちを高揚させたか･･･これは実際にはMicrosoftにとっていいことではなかった･･･期待を高めておきながらそれが満たせないと、すごくバカみたいに見えるのだ。

しかし舞台裏の方はさらにひどかった。どうしてかって? 取締役たちもまた、その光や鏡や歌や踊りを信じてしまったからだ。彼らは自分の見ているものが実現可能だと思った･･･夢で見ているものが単に不可能だというのはすごくありうることなのだ」

だからFlash(あるいはPhotoshopやPowerPointやVisio)のデモで過大な期待を持たせることに誘惑を感じるかもしれないが、それは短期的な利益でしかなく(クライアントやボスや世間に対してヒーローになれる)、長期的には苦痛なものとなる。しかし問題はそれだけではない。できすぎたデモが誤った期待を持たせるのと同じくらいに問題となることは:

より「できている」ように見えるほど、フィードバックは幅が狭く増分的なものになる

私たちはそういうことを本やソフトウェアでしょっちゅう目にしている。彼らに何か磨き上げられたこぎれいなものを見せるなら、フォントサイズみたいなことについてフィードバックを受け取ることになる。レビュアは目の前にあるものに 目を奪われて、細かい差分的な調整をしようとする。しかしナプキンに描いたスケッチを見せたなら、彼らはそこにあるものを見るだけでなく、何が可能なのかを理解する。あなたはレビュアに今の時点ではどのような種類のフィードバックがほしいのか伝える必要がある･･･「木」の 段階に進もうというときに、「森」を見るような全体的なフィードバックをほしいとは思わないだろう。一方あなたが何か完成形のものを見せるときには、もっぱら木のレベルで微調整するようなフィードバックを受け取ることになる。だから全体像レベルのフィードバックがほしいときには、提示する情報を曖昧なものにすることだ!

それから、実情に合った見かけを作るのを助けてくれるツールがあることを知っておくべきだ。私のお気に入りはNapkin Look and Feelで、これはインタフェースを——文字通り——ナプキンに落書きしたような見かけにしてくれるJavaプログラム用のGUIスキンだ。これはすごくいい。作者のケン・アーノルド(Javaのグルであり、Sunの難民仲間)は詳細に対して驚くほど注意を払っている。たとえば、ラジオボタンが全部同じようであるなら、それがどんなにスケッチのような見かけをしていたところで、その同一性によって魔法が破れてしまう。だからスライダー にボタンにタブに･･･ほとんどあらゆるGUIコンポーネントが複数用意されている。

ここには1枚の画像しか挙げないが、Sourceforgeにあるスナップショットをぜひ見てもらいたい。あるいは実際のJavaのデモを試すならさらによい(上のリンクからデモにたどり着ける)。

例外やただし書きが必要になるケース(たとえば早い時期に度肝を抜くようなデモを見せられないとクビになるというような場合)が無数にあるのはわかるが、一般的に言って、あなたが手にしているものにより近いものを見せるほど、人々をうんざりさせる可能性は低くなり、そしてその時点において必要な種類の良質なフィードバックを得られる可能性が高くなる。結論: 初期のデモでは曖昧に考えること。スケッチのように考えること。小さく約束して期待以上のものを届けようと考えること。

[関連リンク:
* 37Signalsのブログがファイナルリリース前に「プレースホルダ」を間違いなく修正 する方法について取り上げている。
追記: flow/stateが「デザインスケッチをデザインフィードバックに望むレベルに合わせる」の中で同様の議論 をしている。]