スピード感あるプロトタイピング
先週のNew Product Developmentではプロトタイプ作りについて学んだが、その際にGoogleのプロトタイプ作りのプロセスについて説明する動画が紹介された。
ウェブサイトやスマホアプリなどのプロトタイプをいかに効果的に素早く作るかを解説しているものだが、3本ある動画の1本目はなんと丸々「紙のプロトタイプ作り」について。Googleのアプリ作成でも、最初は紙に絵を描くところからスタートしている。
※3本ある動画の1本目はこちらから
https://www.youtube.com/watch?v=JMjozqJS44M&t=202s
それを踏まえ、今週のNew Product Developmentでは事前課題として、駐車場アプリのプロトタイプを紙で作ってくることが課されていた。
具体的には、紙に手書きした画面を取り込んでプロトタイプを作れるPOPというアプリを使ったのだが、基本的には手書きで画面のレイアウトや画面間のトランジションを作成した。
サービスを成り立たせるのに必要となる10枚ほどのページイメージを紙に描き、それをiPhoneのカメラで撮影、取り込んだ画像の上にリンクを置いていき、どのボタンをタップしたらどのページに飛ぶか、その際のトランジション(ページ遷移の仕方)はどうなるかを設定すればできあがり。4人のメンバーで2~3時間あれば最初のプロトタイプが完成してしまう。
これら一連のワークから学んだことをまとめておきたい。
まず、何故紙なのか。
これはシンプルで、とにかくスピードが早い。
プロトタイピングのプロセスは修正に次ぐ修正の嵐だ。というか、仮説検証とプロダクトの修正をするためにプロトタイプがあるというのが正しい。
そのため、一旦仮説検証を終えたらすぐにプロトタイプを修正して次の仮説検証に向かわなければならない。その度にコーディングし直したり画面上でのデザインにこだわったりしていると、それだけで時間がかかる。
プロダクトの最も初期の段階では、基本的な機能へのニーズや基本機能についての画面遷移が検証できれば良いので、それ以上のものを検証するためのプロトタイプは作らない(もし美しくデザインされたアプリを作ってもニーズが無ければ無駄である)。
そのため、紙に手書きレベルでも十分なのだ。Googleのビデオの冒頭では、「あなたのアイディアはもう他人に見せても良いか。答えはYESだ」と言っている通り、紙に手書きのものでもどんどんユーザに見せて問題ない。
むしろその段階からユーザに見せて叩いてもらってこそ、本当に検証すべきものから無駄なく素早く検証していけるので、後になって致命的なことになったりしないのだ。
紙のプロトタイプで検証すべきこと
上記でも少し触れたが、このステップで検証すべきことは
「ユーザの課題をどのような流れで解決していくのが良いか」
「ユーザが直感的にアプリを操作し、自然な流れで使えるようになっているか」
ということだと思っている。
具体的には以下の項目を検証していく。
ユーザがサービスを使う流れ
プロトタイプを作る前段階として、ストーリーボード(10コマくらいの漫画)でユーザがサービスを使っていかに課題解決をしているかを描く。その中から、ユーザが一連の行動の中でいかに課題解決をするか、それをサービスがいかに助けるか、そのために必要な機能は何かを整理する。
また、ユーザがその行動を起こしていく各ステップで持つ疑問(どこに車を停めるのが良いか?どの階が空いているのか?どうやって料金を払おうか?等)を洗い出すことで、サービスがそれらに対していかに答えるかという観点から必要な機能とレイアウトを考える。
それらをアプリのページの形に落とし込み、プロトタイプ化することで、ユーザに対してどのページをどの順番で見せるとユーザが潜在的に持つ疑問をスラスラと解決しながら進んでいけるかを検証していく。
画面のレイアウト
画像やボタン、文字の大まかな配置もこのステップで検証する。重要なのは、ユーザがストーリーボードに描かれた理想的な消費行動を取るためにどのような情報をどのような優先順位で見せ、どのような行動を促すかということであり、オシャレなデザインや実際の画像はここではまだ考えない。
アプリ内での各リンクの反応
プルダウンを押すとどのような選択肢が見られるのか、画像をタップするとどのようなウィンドウが出てくるのかなども紙で検証可能な項目である。
例えば、プルダウンにはジャバラ状の紙を使い情報を記載して貼付しておき、その内1つの選択肢を選ぶと別の紙に書かれた新たなウィンドウがオーバーラップしてきて…という一連の流れを手動操作しているところをiPhoneの動画に録ることでそれらの動きが分かるプロトタイプができてしまう。
これによって、ユーザが自身の課題を解決するためにどのようにアプリを操作するのか、それに対するアプリの反応は使いやすくわかりやすいものになっているかということを検証する。
色や影など細部のデザイン
基調色+アクセントカラーの使い分けや、オーバーラップするウィンドウのイメージなども、コーディングに入る前に、紙の使い分けや手動操作の録画などによって簡単に検証できる。
以上の通り、紙とペンだけでもサービスの基礎となる部分の仮説検証を進めていくことができてしまう。時間もコストもほとんどかからない。
「仮説検証の優先順位をつける」「プロトタイプは、今すべき仮説検証に必要なものだけを作る」という基本的なスタンスを体現する具体的な手法を学べたことは大きな収穫であった。
「紙に手書きのものなんてお客様(社長?)に見せられない」「何かあったらどうするんだ」と言っている間に、これができている会社は次々に仮説検証を進め、サービスの根幹部分を形作ってしまう。
完璧なものを作ろうとせずに、一番検証すべき仮説を最短で検証し、OKなら次に進むしダメならすぐやめるというプロセスを回していかなければ、スピードの速い技術オリエンテッドなイノベーションは起こせないだろう。