ペーパープロトタイピング

ペーパープロトタイピング 最適なユーザインタフェースを効率よくデザインする

ユーザインタフェース（UI）を、紙に手書きしたモックを元に作り上げていくための、さまざまな知見が記述されている。本書を読む前は、紙ベースでUIを作り上げるための技術的な方法論かと思っていたのだが、そのような内容はかなり少なく、UIのテストをテーブルトークRPGのように行う秘訣についての記述が多かった。予想と違って、かなり驚きの内容でした。

第1部 ペーパープロトタイピングの概要

手書きの例題として、PC用アプリケーションや携帯端末の画面が図として示されており、ボタンやリストなど全て手書きだ。ペーパープロトタイピングの利点として、以下が挙げられている。

• 実装に入る前の開発プロセスの早い段階でユーザからフィードバックを得られる
• 多くのアイデアが試せる
• 開発チームのみならずユーザともコミュニケーションが活性化される
• 技術スキルが不要なので、多くの人が参加できる
• 創造性が向上する

本書にも書いてあるが、プロトタイプとして見た目だけでも動くサンプルプログラムや、その印刷物をユーザに提示すると、微妙なレイアウトに話題が集中する傾向があり、UIとして優れているかを評価することが出来ない。しかし、手書きだとそのような事はないそうだ。確かに、サンプルやその印刷物のような「完成品」を見ると、人はそれを受け入れた上で物事を考えるのかもしれない。その点、手書きという未完成品だからこそ、それを変えたり消したりするのに抵抗感が無いので、いろいろなアイデアが生まれるのかもしれない、と思う。
いくつかの実案件が紹介されているが、その中にMS-Windows用のアプリがあり、アイコン化、最大化、クローズのボタンまで手書きしてあった。正直言って、そこまでやるのかー、って思ったけど、本書の後に方にもっと手抜きした図もあったので、場合によるのだろう。最小限の努力で、有益なフィードバックが得られたと書いてあり、ペーパープロトタイピングの利点が強調されている。
実際のペーパープロトタイピングの作成として、紙や鉛筆やテープなどについて推奨する製品名が紹介されている。それらを切って書いて貼ったりして、チェックボックスやドロップダウンリストなどのGUI部品を手書きでシミュレーションする方法が記述されていて、すげー、そこまでやるのかと思った。マウスカーソルまで手書きですよ。なお、日本で買える同等品については、訳者が付録に追記しているのは良い。

第2部 ペーパープロトタイピングによるユーザビリティ調査

実際にペーパープロトタイピングを使用してユーザビリティを調査する方法が書かれているが、これには驚いた。どのボタンを押したらどうなるといった、UIの挙動を事前に決めておき、募集したユーザに実際に操作してもらい、どこでつまずくのか、どこが分かりづらいのか、と言ったことを調査するそうだ。ここで、「ユーザに操作してもらう」と書いたが、ペーパープロトタイピングなのでマシンはありません。PC役のスタッフに対して、ユーザが手元の用紙を指さして「このボタンを押す」とか言うと、PC役がそれに対応した画面を手書きした用紙を、ユーザの手元の用紙と差し替えると言ったことをします。
スタッフとして、PC役、書記、進行役が居て、その他に観察者が居る場合もあるそうだ。テーブルの座り方も推奨があって、ユーザの後ろに誰も居ない配置であるとか、具体的な図が示されている。スタッフの、ユーザの質問に対する答え方も記述してあり、要は誘導するような回答をしてはダメだそうで、ユーザの意図を確認するような受け答えが必要とのこと。また、ユーザがUIを理解できずに困っていても、それはUIが悪いのであって、ユーザに能力が無いと思われるような事を言ってはならないとか。そういった、ユーザに対する心理的な注意点の記述がかなり多いです。
ユーザの候補者は調査会社に依頼して、一般から募集する場合もあるそうだ。私が仕事で開発したような特定顧客向けのシステムとかでは無くて、DVD+HDDレコーダのUIとか、そういった物のテストを想定しているのだろう。

第3部 ペーパープロトタイピングを行うかどうかの判断

いろいろ書いてあるが、バイアスとハプニング集が興味深い。
バイアスは、対象ユーザ層に一致しないユーザを選んではならないとか、進行役が誘導質問してはならないとか、そういった事が記述されている。
ハプニング集は、これまでに記述された内容と矛盾が多くて、つっこみどころ満載です。ユーザビリティテスト当日までに実装が間に合わなくて、テスト中にバグが発生して困ったとか、ネットワークの調子が悪くてWebページが遷移しなかったとか、「ペーパー」プロトタイピングじゃなかったの？と思ったら、その後に「ペーパープロトタイピングでのハプニングは無かった」なんて書いてあるよ。本当かなー？

第4部 ユーザ中心設計の事例

事例が３つあり、その一つはリモコンのプロトタイピングで、木で作ったモックに紙でボタンを貼り付けて評価していた。なんか普通。

この本を読んでのまとめ

ペーパープロトタイピングの技術的なテクニックを期待して読んだのだが、あんまり書いてなくて、被験者（ユーザ）との接し方とかの記述が多かったので、期待からは外れていた。かといって期待はずれとは言うつもりはなくて、ユーザからの意見や意図の引き出し方とか、そういった点では面白かった。とはいえ、第2部のようなPC役を演じるような事をやろうとは思わなかった。本書の始めの方に、実装前のテストだからコストが掛からないと書いてあったが、私が関わるような仕事では第2部の方法ではコストが掛かりすぎで、実装して見てもらって作り直した方が安いだろう。だから、実装前に紙ベースでユーザと一緒に試行錯誤するという、テーブルトークRPGではない普通の方法で良いと思う。その方法であれば、別にこの本を読むまでも無く実行できるだろうし、読んでもあまり役には立たない。しかし、特に第2部の内容はヒアリングとか、別の分野にも参考になるだろうから、そういった意味では読んで良かったと思う。まぁ、実践するしないは別にして、なかなか面白かったですよ。