プレイブック -プロダクトデザインスプリント-

ほとんどの人は、デザインというのは見た目のことだと誤解している。デザイナーにベニヤの箱を渡して、「見栄え良くしてくれ」と言うようなものだと。私たちが考えるデザインは、そんなものではない。見た目や感覚だけではなくて、どのように機能するかがデザインだ。
スティーブ・ジョブズ

Google Venturesのデザインチームが開発したProduct Design Sprintとは、人々が欲しいと思うものを作る可能性を向上させることを目的とした5段階の実習です。私たちは、高額な費用がかかる製造を始める前に、根拠のない自信を確かな自信に変えたいのです。あるいは、手がけようとしている製造が高額な費用をかけるのに値しないということを知り、惨事を免れたいのです。

このスプリントは、新しい製品や新しい仕事の流れに取り掛かる際だけでなく、既にある製品の問題を解決しようとする際にも有用な出発点です。通常は5日間続きますが、もっと短い期間でも行うことができます。利害に関係する人と専門家を、なるべく多く集めましょう。

Product Design Sprintは、テスト駆動型のデザインです


注釈:
第一フェーズ Understand(理解)
第二フェーズ Diverge(発散)
第三フェーズ Converge(集中)
第四フェーズ Prototype(プロトタイプ)
第五フェーズ Test(テスト)

下準備

スプリントを始める前に、最終フェーズで行うテストのために、クライアントから5人用意しておいてもらいます。彼らは私たちよりも、ユーザについて理解しています。

また、以下のような情報源から研究結果を集めます。

さらにいくつか、(有料の)下準備をすることもあります。

私たちはたいてい、特別感を演出するために初日の朝食を注文しますが、スプリントの期間中、毎日ランチをオーダーするのはやめましょう。そしてスプリント中でも普通の日でも、”ワーキングランチ”にはしないことが重要だと考えています。その代わりに、脳を休ませるために短時間でも仕事から離れ、新鮮な空気を吸い、チームメイトやクライアントと交流しましょう。

Understand(理解)

このフェーズで行う実習は、ユーザの生活(コンシューマソフトウェア)や仕事(ビジネスソフトウェア)上のニーズを理解して共感するのに役立ちます。

このフェーズを通して、みんなメモをとります。付箋に書いて、部屋の壁に貼っていく様子も多く見られます。

まずは”プレゼン練習”から始めます。これは、クライアントが自社の製品を、投資家を相手にしているつもりで売り込むのです。ユーザやユーザの問題、彼らがこの製品にさせたいと思っている仕事を特定するのに役立ちます。また、ドメインで使われている用語の記録もし始めます。

それからQuoraやAnalytics、AdWords Keyword Plannerからの研究、インタビューや調査の結果を見直します。これによってユーザの動機、マーケティングファネル、ターゲットとしているマーケットの規模が理解できます。

最後に、ソフトウェアのクリティカルパスの素案を作ります。これ以降のスプリントは、これに焦点を合わせて進めます。この時点で高いレベルに維持するよう努め、実行の詳細について、できる限り細かく検証するようにします。クリティカルパスを作るのに効果的な質問は、次のようになります。
ユーザは、この製品にどんな仕事をさせたいのだろう?

フェーズが進むごとに、クリティカルパスも編集しましょう。

Diverge(発散)

このフェーズではユーザのニーズを満たすことができそうな解決法の具体案を徹底的に洗い出していきます。

このフェーズに入る前に、チームで部屋の壁に張り巡らされたクリティカルパスやメモの数々を歩きながら再度検討していきます。

再度”プレゼン練習”から始めて、クリティカルパスに照らし合わせていきます。

その後、各個人でそれぞれ10個以上のユーザフローやユーザインターフェースをスケッチします。そして顧客がどこからやってくるのかといったことを考えていきます。Twitter? ブログの投稿? AdWords? 自動的に表示される広告? 送られてくるメール? 友人の紹介? プッシュ通知?

製品が見えてきたならば、こういった情報はGoogleアナリティクスの”Acquisition Channels” で調べられるでしょう。

そしてそれらのスケッチを壁に貼り、無言での投票を始めます。注意深く検討し、自分のとは別のフローやユーザインターフェースで良さそうなものにドットステッカーを貼っていきます。この方法で、どのアイデアがベストか視覚的に分かります。

そして次に、グループ審査に移ります。1つのアイデアに対して3分間審査します。このグループは個人投票でつけたドットステッカーによって分けられます。また、スケッチを書いた本人は新たに注釈を書き加えることが出来ます。あるアイデアを切り捨てたり、選別したりもしません。この投票は討論を長引かせず、委員会の介入を避けるために行うのです。

最後に、大き目な赤色のドットステッカーを使って”超過投票”を行います。CEOまたは製品のオーナーがそれぞれベストだと思うアイデアに1つだけ”超過投票”します。こうすることで自分たちの組織の現状を反映した決定をすることができ、組織の最高権威者の確認も取れます。

私たちの経験上、このフェーズは精神的に疲れます。なので、なるべく早めに切り上げて、自宅に帰って体力を回復させることをお勧めします。

Converge(集中)

このフェーズでは新たな解決法のアイデアの発生を防ぎ、ベストなアイデアだけに集中するようにします。そして、プロトタイプを試すテストを考えます。

まずは、自分たちが決めたベストなアイデアにおいて起こりうる前提条件を確認します。ユーザの動機、ビジネスモデル、ユーザを得るための能力、そして予算を考慮に入れて解決法を実行する能力などについて、全ての可能性をリストアップします。これによっていくつかの選択肢を排除することが出来ます。

次に、残ったメモから議論する点を探し、ユーザフローやユーザインターフェースについて検討していきます。これらは全て同じ問題をそれぞれ別の角度から解決しようとするアイデアですが、現段階で解決へたどり着けそうのないものは排除します。

そして、ベストだと思われるプロトタイプを1つだけ作るか、いくつか数種類のプロトタイプを作って比べていくかを決めます。数種類のプロトタイプを作ると、初期段階の作業が増えますが、行き詰りそうになる点がよりたくさん見えるようになり、その結果、新たにスプリントを実行せずとも、トラブルを避けやすくなります。

さらにここで、各プロトタイプにストーリーボードを付けていきます。これは私たちの顧客がクリティカルパスを通って動く流れを漫画仕立てで描いたものです。

最後に、テスト用のスクリプトをGoogleドキュメント内に作成し、会議室の壁にボードを付けます。このスクリプトはストーリーボードをベースに作られ、テスト結果を記録するためにスコアボードを使用します。こうすることで、自分たちが何を学習しようとしているかかなり明確に分かるようになります。

プロトタイプ

足並みを揃えるためにもう1回プレゼンの練習をしたら、もうこのフェーズではトレーニングはありません。適切なプロトタイプを適切な信頼度で構築することに集中し、効果的なテスト結果の生成を目指します。

このフェーズの間、クライアントにはGoogle Docsでコピーテキストを書くように依頼します。この時、 ロレム·イプサム(ダミーテキスト)ではなく
本当の文章で
入力してもらいます。ユーザの理解と熱意を検証するためです。この文章は後でTwitterでのつぶやきや、プレス、コピー、ランディングページなどにも利用できます。

クライアントがコミュニケーションを仕上げるのに忙しくしている間、私たちはデスクに向かってプロトタイプを作っています。デザイナーやプロジェクトによって使うツールは異なります。

Webアプリのプロトタイプには以下のようなものが適しています。

モバイルアプリのプロトタイプに向くのは下記のものです。

これらのツールをスプリント中に勉強しようなどとは思わず、ぜひ予め時間を取って精通しておいてください。そしてスプリントの期間には習得済みのツールを活用しましょう。

テストと学び

最終的に、ユーザ5人に対してインタビューを行い、ユーザとその状況、そしてプロトタイプへの理解をテストします。これはユーザビリティテストではありません。ユーザにプロトタイプを見せる前にインタビューを始めます。

デザイナーのうち1人がインタビューを行います。モニタリングのため、インタビュールームにビデオとオーディオストリーミングをセットアップします。他の関係者はインタビューを見ながら話し合い、ユーザの回答をボードに記入していきます。

いい質問はユーザが自由に回答できる余地のある、オープンエンドの質問です。

「どのくらいの時間、非営利団体でボランティア活動をしたか教えていただけますか?」

ユーザに期待通りの答えをさせるような質問はやめましょう。

「可能なら公立学校に寄付しますか?」

会話がすぐ終わってしまうような質問もしないようにしましょう。

「先週、どこかの組織に寄付しましたか?」

新しいプロダクトにおいては、最初のスプリントではうまくいかず、Diverge(発散)やConverge(集中)のフェーズに追加でスプリントを行って新たなユーザでもう1度テストするというケースが多いでしょう。

1~2回のスプリントの後、通常私たちは多くの前提条件を検証し、明確なクリティカルパスを確立し、より広いオーディエンスに向けて最初のバージョンのコーディングを始める準備ができます。

Webアプリでは通常、最初のバージョンをリリースするまでに4~6週間かかります。モバイルアプリでは6~8週間でベータ版をHockeyAppにリリースし、8~10週間でアプリストアにリリースします。

このようなスケジュールで、2~5日かけて2度目、時には3度目の短縮版プロダクトデザインスプリントを行います。これをやっておくことにより、後から失敗に気付き4倍から10倍もの時間とコストを失う事態を防ぐことができます。
他にあるケースとしては、結果的に、特にユーザが困っているわけでも、ビジネスモデルが悪くもなく、私たちの仮定が全部間違っていたということが証明されてしまうということがあります。これは感情的にはショックですが、時間とコストが節約されたという意味において成功と言えるでしょう。

この先のプランを計画してフェーズを終了します。