ヒアリングも兼ねた内部検討向けのラピッドプロトタイピングはアイディア発散と要件収束の両方に効く

Gaji-LaboのUIデザイン案件がどのようにはじまり、どのように最終調整に進んでいくのかの全体像を紹介する記事の流れで、前回はUI検討のための機能のモデリングについて書いてみました。

とても大事なステップであるモデリングを経たうえで、そのあとに行うプロトタイピングも同様に大事なプロセスになっていきます。今回はプロトタイピングについて書いてみたいと思いますが、プロトタイピングのお作法というよりは「UI方向性検討の際に何をするとよいのか」の考えをまとめてみたいと思います。

プロトタイピングはあらゆる段階で発生する

プロトタイピングとは、機能やアイデアを試作品のような形で具体化することで、確認や検証を行えるようにするものです。目的は様々あると思いますが、プロダクトの実現可能性を探る他に共通言語としてコミュニケーションに活用されることが多いのではないかと思います。

プロトタイプとして数えられるものにもいろいろあります。ワイヤーフレームも一種のプロトタイプですし、もっとざっくり紙に書いて表現するペーパープロトタイプもデザインツールで作り込んだ実物に限りなく近い詳細プロトタイプも、活用するタイミングが違うだけでどれも重要なプロトタイプです。

プロトタイピングが必要なのはユーザーテストだけではない

1か月間でUIデザインの改善にコミットするようなプロジェクトの場合、厳密にゴリゴリプロトタイピングをする猶予があるとは言えません。その場合、私たちが直接ユーザーテストにコミットする機会も少なくなります。

私たちは作るところまででテスト自体はクライアントで行ってもらう、という形になるので、そういったプロジェクトの場合はリリースを繰り返して改善を重ねるサイクルの一部をお手伝いする形といえます。（もちろん長期に渡るアサインがある場合には、ユーザーテスト自体にご一緒できる機会もできます）

「ユーザーテストを行わないのであれば、プロトタイプなど必要ないのでは？」という声もあるかと思いますが、Gaji-Laboがプロトタイピングをする相手はエンドユーザーだけではなく、クライアントさん自身も対象になります。

ヒアリングも兼ねて、内部検討の材料としてラピッドプロトタイピングする

前回紹介したUI検討のための機能のモデリングのステップでは、ビジネスに効くUIデザインを行うためにビジネスサイドからエンジニアサイドまで幅広く通じる「共通言語」が必要だと説明しました。プロトタイピングのステップもまったく同じことが言えます。

今まで概念でしかなかった事業アイデアをモデル化しただけでは、形になったとは言えません。モデルを元に実際に触れる＝タンジブルな状態にすることで、はじめて現実世界にプロダクトが生まれてきます。

プロダクトの機能面を確認するファンクショナルプロトタイピングになるような何か、実物に近いデザインプロトタイピングになるような何かをうまく盛り込んでコミュニケーションすることで、あやふやだった機能要件や体験としてのキーポイントが洗い出され、何時間もかけてヒアリングするより芯を食った情報をもらえるようになります。

言葉を変えてみると、概念を具現化したものの叩き台＝プロトタイピングと考えてもよいのかもしれませんね。プロトタイピングの正確な定義やお作法などはいったん横に置いておいて、ここで伝えたいのは「具現化した概念を眺めたり手に取ったりしながらコミュニケーションすることが何より大事」ということです。

より濃密なコミュニケーションするための叩き台をみんなで叩ける… というのがプロトタイピングの利点。多少一般的なお作法から外れていても、大事なことが達成されていればOKだとも考えています。だからGaji-Laboでは叩き台をベースにしたディスカッションを大歓迎しています。

また、コミュニケーションには文脈があるので「今はアイデアを発散するためのプロトタイピングですよ」「今は仕様を落とし込んで決めていくためのプロトタイピングですよ」の両方が存在します。今行っているのはなんのためのプロトタイピングなのか、チームメイトと逐次共有することが必要ですね。

プロトタイピングは正解がない領域ですが、そのときの状況に応じてもっとも適切な文脈のプロトタイプを活用できるように心がけています。そんなこんなで、UI方向性検討の際に必要なことは、定義やあるべき論にとらわれず、泥臭く必要なことを繰り返していくことなんじゃないかなぁというのが、現時点での私の答えです。

Gaji-Labo式UIデザインプロジェクトについて他にもいろいろ知りたい方は「UIデザインプロジェクトの進め方」まとめがおすすめです。