ありがちなプロトタイプ失敗パターン

次へ進むための『何か』

プロトタイプは今日の設計プロセスにおいて必須の役割を果たしている … といった論調を見かけることがあります。特にアプリの場合、Web サイト制作以上に開発者とデザイナーの密接なコミュニケーションが必要になるので、単なる静止画データの受け渡しでは不十分です。そこで「プロトタイプを作りましょう」となるわけですが、他のツールと同様、手法を取り入れただけで制作における課題が解決されることはごくまれです。

プロトタイプは、紙で作るものから、Principle のようなアプリケーションを使ってインタラクションを加えるものまであります。プロトタイプの完成度も制作スピードもツールによってまちまちなので、どのように扱えば良いのか迷う方も少なくありません。また、新しいツールを採用してプロトタイプ（のようなもの）を作ってみたけど、以前と状況が変わらないどころか、大変になってしまうこともあります。

私の中でプロトタイプは、工程を進めるために必要十分な『何か』と定義しています。この定義だと、従来からあるワイヤーフレームもプロトタイプの一種として含めることができます。何か新しいツールを使っていなければならない。画面遷移をはじめとしたアニメーションが付いていなければいけないという先入観が付きまとうプロトタイプですが、そんなことはありません。むしろ、その先入観で作られたプロトタイプが、プロセスの失敗を導く場合があります。

プロトタイプにある落とし穴

様々な完成度のプロトタイプを今も作り続けていますが、完成度が高いのに効果がないものを作ってしまったり、余計な時間を費やしてしまったこともあります。プロトタイプの利用に失敗するパターンは 5 つあります。

成果物として捉えてしまう

プロトタイプは完成品ではありませんし、ちょっとリッチな指示書でもありません。「こんなかんじ」という漠然としたアイデアを検証し、周りに「なるほど」と思ってもらい、会話を始めるためにあります。この通りに作ってくださいという位置付けでプロトタイプを作ってしまうと、やたら制作時間がかかるデザインファイルになってしまいます。

検証のためのプロタイプは大きく分けて 3 つあります。完成品ではなく、これらを検証するために作るようにすると、何を、どれくらいの完成度で作らなければならないか考えやすくなります。

• アイデア — イメージがうまく共有できていない
• 実装 — 技術的に実現可能なのかを考えたい
• 計測 — 何をテストするべきなのか、何をもって成功かを考えたい

学びのツールとして利用しない

プロトタイプを早く作る理由は、納品物を早めに完成させるためではなく、早めに課題を発見して余計な後戻りを減らすためにあります。デザイン批評全般にも言えますが、「これはどうですか？」と見せるものというより、学びを引き出すためにプロトタイプがあります。以下のような疑問について考えるためにプロトタイプを活用すると良いでしょう。

• 利用者がもつどの課題を解決しようとしているのか
• 自分たちがもつ利用者のイメージにズレはないか
• 実装するにはどれくらいのコストがかかるのか
• 新しい技術やデータが必要になるか
• 他に可能性があるとしたらどのようなものか

プロトタイプを共有する相手を見ていない

プロトタイプツールを選ぶときに、どれくらいの完成度のものが作れるかが気になりますが、共有方法も選定の際に重要な項目になります。ペーパープロトタイプはスピードが最も早く、誰でも参加しやすいのが魅力ですが、リモート環境では効果が半減します。自分にとって作りやすいだけでなく、誰が何を目的でプロトタイプを使うのかを考えなければいけません。

もし他の人がプロトタイプを編集する可能性があるのであれば、Keynote や PowerPoint のほうが良いでしょうし、Android ユーザーにも検証してもらいたいのに、プレビューアプリが iOS にしかないのでは意味がありません。

作り込み過ぎて時間を無駄にする

最近は Principle や Flinto for Mac のようにコードの知識がなくても簡単に高度なアニメーションを加えることができるようになりました。Framer まで使えるようになると、本物のアプリと同じような使い心地のプロトタイプが作れるようになります。プロトタイプの精度が上がることで、よりイメージの共有がしやすくなりますが、必要以上に作り込んでしまう危険性もあります。

私のプロトタイプの定義で「必要十分な」という言葉を入れてあるのは、必要以上に作り込むことが容易になってきたからです。画面AからBまでの遷移がうまくできるかを検証したいだけのために、Mac の前で一生懸命アニメーションを作っていたら時間の無駄ですし、検証時にアニメーションの話になって議論がズレてしまう恐れがあります。

ひとつのツールに固辞してしまう

多くのプロトタイプツールは、ある一定の完成度のものを早く作ることに長けています。例えば inVision であれば、画面遷移の検証に使えますが、１画面で起こる様々なインタラクションの共有には向いていません。Axure のように古くからあるツールは膨大な機能を提供しているものの、万能ではありませんし、他のツールのほうが早く作れる場合があります。他のツールを学ぶのは時間がかかるということで避けている方も少なくありませんが、最近のツールはマニュアルをしっかり読まないと理解できないものは極めて少ないです。

Web サイトの大まかな構成を共有するのであれば、Keynote や PowerPoint で十分かもしれませんが、レスポンシブ Web サイトにおけるコンテンツフローを共有するのであれば、Bootstrap Studio で作って見せたほうが早いですし、誤解も防ぐこともできます。工程を次に進めるためには手段を選ばないという気持ちで、3 つ以上の手法を覚えておくと良いでしょう。

まとめ

情報伝達はもちろんですが、プロトタイプはコミュニケーションツールとして用いることで真価を発揮します。今はコダワリ始めると、いくらでも完成度を上げることができるので、会話をするために必要最低限のモノは何かを見極めないとデザイナーの負荷は上がる一方です。

また、コミュニケーションがとれる環境を整えることが、プロトタイプをプロトタイプらしく扱うには必須です。決裁権をもつ方と直接話すことができるのか。他のグループメンバーとの距離感や関係性はどうか。ワークフローの中に『模索する』という余白は残されているか。プロトタイプの失敗パターンは、ツールを知っているだけでは解決しないことを意味しています。新しいツールが導入できないから無理と嘆くのではく、「ちょっとこれ見てよ」と誰かに途中段階を見せるだけでもプロトタイプ活用のための第一歩になります。