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

ウェブサイトの画面設計のファーストステップとして、よく使うのが、ペーパープロトタイピングという手法です。ペーパープロトタイピングとは、紙 (paper) による試作 (prototyping) という意味で、紙の上で手描きしたり、そこに紙片を切り貼りすることで、画面構成を作ってみることを言います。

ペーパープロトタイピングの利点は、特別なツールが不要で (紙と鉛筆さえあればできる)、手軽にできることです。四角形や丸や線が描ければ、「絵心」が無くても問題ありません。いわゆるデザイナー (デッサン力があったり、ビジュアルデザインソフトを使いこなす人) や開発者 (コーディングやプログラミングができる人) でなくても参加できるので、プロジェクト関係者みんなで一緒に描く、というのもありでしょう。

まず重視すべきは情報の優先度

私の場合、特に初期段階のペーパープロトタイピングにおいては、プロジェクト関係者みんなで集まって、ペーパープロトタイプ作りのセッションをすることが多いです。その際、まず重視するのは、視覚的なレイアウトよりも情報の優先度付けです。ユーザーの目的、コンテキスト (利用環境、取り巻く状況、前後の動線、など)、次にユーザーに取って欲しいアクション、といったことを見据えて、提示すべき情報を取捨選択し、提示順位を決めるのです。

今やモバイルデバイス (スマートフォンなど) でのウェブ利用が一般的なので、「モバイルファースト/コンテンツファースト」の考えかたに立ち、ポストイットなどに情報 (コンテンツのブロック) を書き出すなどして、ワンカラム (縦一列) に順位付けして並べます (同率順位は認めず、シビアに順位を決めます)。実際やってみると、様々なトレードオフに直面するので悩ましいですが、これがクリアできれば、その先の作業 (画面構成の詰め) は割とスムーズにできるので、何はともあれ、順位付けです。特にセッションの時間が限られている場合は、(関係者の合意が伴う形で) ポストイットが縦一列に並んだ状態にまで持っていくことができれば十分、という感触を持っています。

その際、セッションをモデレートする立場としては、情報構造 (セマンティックなマークアップ) も意識しつつプロトタイプをまとめ上げていきます。幸い、情報がシリアルに並ぶことで、スタイリング (CSS) を排除した「素の」HTML ドキュメントに近い形になるので (いわば「リニアライズ」された状態)、情報構造を意識することはそう難しくありません。情報構造の適切さはアクセシビリティに大きく影響するので、ペーパープロトタイピングという設計の最上流段階から情報構造を意識することは、アクセシビリティに優れたサイトを作るうえでとても有効だと考えています。

ペーパープロトタイピングは試行錯誤が大事

情報の優先度を重視しつつ、ペーパープロトタイピングを練り上げていきますが、作ったペーパープロトタイプは積極的に「試行錯誤」することが大事です。作ってみて、フィードバックを受けて、作り直して、またフィードバックを受けて、修正して…という具合に、繰り返しブラッシュアップします。なので、キレイに描くことは大事ではなく、むしろ「くよくよせずにスッパリとやり直しができる」程度にラフに (エネルギーをかけすぎずに) 描くことのほうが重要です。

また、作ったペーパープロトタイプは、単に眺めるのでなく触ってみる、つまり操作 (ユーザー行動) のシミュレーションをしながら、検討することも大事です。ブラウザウィンドウを模した枠を作って重ねたり (ファーストビューやスクロールなどが検証できます)、モバイル向けの画面設計であればプロトタイプを実際のスマートフォンやタブレットに (あるいは適当な大きさの板に) 貼り付けて持ってみるのも効果的です。そのためプロトタイプはなるべく原寸大で作るのがよいでしょう。特にタッチインターフェースでの利用が想定される場合は、タップ可能な UI 部品 (ボタンやリンク画像など) をはじめ原寸大で画面構成を描くことを意識しましょう。

ペーパープロトタイプをユーザビリティテストに使う

上述の通り、作ったペーパープロトタイプは触って試行錯誤してみることが大事ですが、これはつまり、ペーパープロトタイプはユーザビリティテストの対象にできる、ということでもあります。むしろ、可能であればどんどんユーザビリティテストにかけるべきだと思います。というのも、早い段階 (開発や制作にコストを投入する以前) でユーザーからのフィードバックを得られる、そのフィードバックをもとに修正や方向転換が手軽にできる (その分、後工程やローンチ後の手戻りリスクを軽減できる)、というメリットがあるからです。

実際に動く「ソフトウェア」ではない、ただの「紙」に対してユーザビリティテストすることの実効性について、不安視する声も聞かれますが、検証したいことがクリアで適切なタスク設計ができれば、問題ありません。小さなタスク遂行を、身近な人 (同僚、家族、友人、など) に短時間協力してもらう形で、それをなるべくたくさんやってみる、というのがよいと思います。なお、ペーパープロトタイプを用いたユーザビリティテストでは、テスター (ユーザー役)、モデレーター (進行役)、観察者 (記録係) に加えて、テスターの操作に反応してプロトタイプを変化させる「マシン役」が必要になりますが、この「マシン役」次第で、テスターの没入感を高めることは意外と可能です。

ここで言う「マシン役」のように、実際のソフトウェアによる挙動の代わりに、人手を介して「いかにもソフトウェアが動いているように」見せるシュミュレーション手法は、ユーザビリティの専門家の間で「オズの魔法使い」と呼ばれています。

今どきのウェブ利用環境への対応

ペーパープロトタイピングは、昔から使われている手法ですが、それだけに、今どきのウェブ利用環境を考えると、いくつか問題があると考えられるかもしれません。私自身は、以下のように「工夫次第」かな、と思っています。

たとえば、JavaScript による複雑なインタラクションについてですが、ペーパープロトタイピングでもある程度シミュレートすることはできます。紙を折ったり重ねたりすることで、折り畳み/展開、プルダウン、レイヤー、タブ切り替え、アラート挿入…などアイデア次第でいろいろできますし、各種入力 (チェックを入れたり文字入力したり) はその場で書き込んでもよいでしょう。動画や音声の再生なら、(ユーザビリティテストで)「マシン役」が喋ったり歌ったりしても面白いと思います。

また、マルチデバイス対応 (レスポンシブデザイン) を想定して、代表的な画面サイズごとに複数のプロトタイプを作らなければならないのか、という懸念があるかもしれません。案件によるかもしれませんが、個人的には「モバイルファースト/コンテンツファースト」の考えかた則って、ペーパープロトタイピングはスマートフォンでの利用を前提にした画面設計でよいのでは、と考えています。大きな画面 (タブレットや PC) での表示上の工夫は nice to have (あれば便利) なものと割り切り後工程に回す (もしどうしても必要であれば、補足的にプロトタイピングする) ことで、かえってプロジェクト内に「モバイルファースト/コンテンツファースト」の意識を徹底できることが期待できると思います。


以上、ペーパープロトタイピングについて、私自身が心がけていることなどをまとめてみました。もっと詳しく勉強してみたい方は、古典になりますが、「ペーパープロトタイピング — 最適なユーザインタフェースを効率よくデザインする」という本がおすすめです。

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