Movatterモバイル変換

Design Sprint Processデザインスプリントのプロセス詳細についてv2: http://www.slideshare.net/takaumada/design-‑sprint-‑guidebook-‑v2Takaaki UmadaAugust 25, 2014 (v 0.1, draft)Big Thanks to Google Ventures1

このスライドは Design Sprint のファシリテーター向けに作られている• Design Sprint のおおよその流流れをつかめるように、プロセスを中⼼心に説明する• Design Sprint の意義について知りたい場合は別の資料料を参考のこと• http://www.slideshare.net/takaumada/design-‐sprint2Objectives of this Deck

実施の際は v2 もご確認ください。 http://www.slideshare.net/takaumada/design-‐sprint-‐guidebook-‐v23Version 2 があります

4LearnDesign Sprint は迅速な学習にフォーカスする

タイムライン5Timeline1DayUnderstand (理理解する)チームの意⾒見見を聞いたり、リサーチや競合製品を通して解決したい問題を深掘りする(2 〜～ 5 時間)2DayDiverge (発散する)できるだけ多くの解決策をラピッドに作る(2 時間〜～ 1 ⽇日)3DayDecide (決める)もっともすぐれたアイデアを選び、全員でユーザーストーリーに同意する (2 〜～ 5 時間)4DayPrototype (プロトする)ユーザーに実際に⾒見見せれるものを素早く（汚く）全員で作り上げる (4 〜～ 8 時間)5DayValidate (検証する)ビルの外に出て、プロトタイプを実際のユーザーに⾒見見せ、何が良良くて何が悪いのかを素早く学ぶ (4 〜～ 6 時間)0DayPrepare (準備する)必要な⼈人とモノを集める (所要時間は数時間)

デザインスプリントを実施して効果を上げたスタートアップの例例And Others….• Gmail, Google X, From Google Ventures 6Case Study: Design SprintBlue Bottle Coffee Pocket CustomMadeSales growth & Time on sitex2New users saved the first item more+58%Customer engagement+300%

準備物8Resource Preparation• 5 ⽇日間使えるワークルーム（5 ⽇日間ずっと使える場所）また 5 ⽇日⽬目⽤用に• インタビュールーム• オブザーベーションルームを⽤用意する。インタビューに必要なものとしては、• Skype (⾳音声を拾拾ったり、Web サイトの操作画⾯面をデスクトップ共有する)• カメラ (ユーザーのボディランゲージを⾒見見る)• Miracast や AirPlay (モバイルの場合、ユーザーの操作画⾯面を⾒見見る)など4 〜～ 8 ⼈人程度度（上下しても構わない）の少なくとも下記の役割の⼈人を⼀一⼈人ずつ• デザイナー• CEO (決定者)• Product Manager• User Expertそのほか、エンジニア、マーケター、関係者など。また、• ファシリテーター（できれば取り組む製品についてあまり知らない⼈人）を⽤用意する必須• ⼤大量量のポストイット• 太めのペン• ホワイトボード（できるだけ多く）• ホワイトボードマーカー• 丸形の⼩小さなステッカー• PowerPoint or Keynote• 多めの A4 の紙 (A3 も便便利利)あると便便利利なもの• Time Timer• Bit Timer• セロテープ or 3M のコマンドタブ• PPT/Keynote ⽤用のプロトタイピングライブラリ (Keynotopia, etc)• プロトタイピングツール (Pop, Flinto, Briefs, etc)• Conference Microphone• スナックPeople Place Materials5 ⽇日間の時間。スプリントの間、すべての⼈人がすべての時間に参加できるようにするTime以下のものをそろえる。

まず最初にインタビューするユーザーをリクルートしてから始める次にやることはインタビューするユーザー 5 ⼈人を確保すること。今現時点で何の製品もなく、何が問題か明らかでなくても、とにかく 5 ⽇日⽬目のユーザーインタビューのユーザーをリクルートして、インタビューの時間割を決める。何故 5 ⼈人かは Nielsen Norman Group のリサーチを参照のこと 9Recruit, Recruit, Recruit Users⽉月⽕火⽔水⽊木10:00 〜～ 10:3011:00 〜～ 11:3012:00 〜～ 12:3013:00 〜～ 13:3014:00 〜～ 14:30

Day 0 ⽤用の tips• インタビューのユーザー集めは⼈人づてになることが多いが（特に⽇日本はユーザーインタビューに応じてくれる⼈人が少ない）、⼯工数を減らすために外部のサービスを使ったほうが楽だしスクリーニングできる。外部のサービスには以下のようなものがある。• Craigslist• ゴチソー• 事前にみんなで意識識を合わせておくべきことは以下• 時間を守る。5 分と⾔言われたら 5 分で必ず収める。例例外は認められない。• PC は 4 ⽇日⽬目までほぼ使わない。必要がないときは閉じておく。メールもチェックしない。• スケッチを恐れない• 「絵⼼心がない」は禁句句。Day 3 までは伝われば何を描いてもいい• スケッチであることを⽰示すために、太めのペンを使うことを推奨10Tips for Day 0

Day 1 の成果物はユーザーストーリーダイアグラムhttp://www.gv.com/lib/the-‐product-‐design-‐sprint-‐understandday-‐1 12Day 1 Outcome is “User Story”, looks Like:

Day 1 の⽬目的1. 問題に対する全員の知識識や⾒見見解を共有し、現状の理理解を⼀一致させる2. 今回のスプリントの中でフォーカスするべき⼀一つの問題を決める13Objectives of Day 1

Day 1 の主なプロセスDay 1 のプロセスはエクササイズによる問題に対する理理解の⼀一致と、問題の発⾒見見に充てられる。最終的には皆が合意するユーザーストーリーを描くことになり、そのユーザーストーリーは最終⽇日までの議論論の⼟土台となるので、腹落落ちしていないところがあれば各⾃自必ず⾔言うこと14Day 1 ProcessTopic を決めるエクササイズする(Topic × 10 分)ユーザーストーリーを描く本スプリントで解決する問題を決める1234

話すべきトピックを決めるトピックを決める。トピックには以下のような例例がある。トピックは価値がないと判断すれば抜いても構わないし、追加しても構わない。• Business opportunity (市場やビジネス機会について話す)• Lightning demos (競合製品や類似製品を⾒見見てみる)• Lay it out (現製品を使ってユーザーの疑似体験をしてみる)• Success metrics (デザイン上のメトリクスを決める。HEART フレームワークなどが参考になる)• Existing research (製品の調査データを使って顧客について知る)• Team interviews (社内のエキスパートに問題について聞いて回る。特にカスタマーサービスの⼈人は貴重な情報を持っている)• Analytics (機能の usage データやドロップレートなどを⾒見見てみる)151.1 Choose the TopicTopic を決めるエクササイズする(Topic × 10 分)1234ユーザーストーリーを描く本スプリントで解決する問題を決める

現状理理解を共通にするために各トピックで 10 分のエクササイズ（議論論）を⾏行行う選んだトピックについて、それぞれ 10 分間議論論する。必ず 10 分の上限は守ること。How might we… (… をどうやったら解決できるか?) という疑問形のフォーマットで問うことで適切切な機会を⾒見見つけることができる（e.g. How might we build trust?How might we figure out the user’s style?）。疑問はすべてポストイットに書いておく。エクササイズが難しい場合は⼗十分なデータを持っていないというケースが多いため、⼩小規模なユーザースタディをしたりごく短いオンラインサーベイをしたりして新鮮なデータをスプリントを始める前に取ってくること。161.2 ExerciseTopic を決めるエクササイズする(Topic × 10 分)1234ユーザーストーリーを描く本スプリントで解決する問題を決める

最も重要なユーザーストーリーをスケッチする共通理理解の上で、協調しながらユーザーストーリーのマップを描く。描くのはファシリテーター。その際には重要なユーザーストーリーに絞ること。何が重要かは、今回のスプリントで解決したい問題による。たとえば、• 顧客の製品の理理解を助けたい → 顧客が製品を初めて⾒見見た時の体験を改善する171.3 Sketch the Most Important User StoryTopic を決めるエクササイズする(Topic × 10 分)ユーザーストーリーを描く本スプリントで解決する問題を決める1234• 新しい製品のコンセプトを作りたい→ Value Prop とコアとなる機能を決める• Landing Page のコンバージョンを上げたい → なぜ顧客が LP にたどり着くのか、彼らのゴールは何かを理理解したい

今回のスプリントのスコープを決めるすべてのアイデアについてプロトタイプを作ることはできないので、このスプリントでどの問題/アイデアにフォーカスするかを決める。決めるうえで重要なのは、• プロトタイプを⾒見見せたときに、ユーザーから何を学びたいのか？• 学ぶためにどんなプロトタイプを作るべきなのか？• 問いかけるのをためらうぐらい「明確な質問」をしてみる：みんなの理理解が進むをしっかりと考える。ファシリテーターは時間制限を付けて問題を決めるようにする。181.4 Focus on the ProblemTopic を決めるエクササイズする(Topic × 10 分)ユーザーストーリーを描く本スプリントで解決する問題を決める1234

Day 1 ⽤用の tips• 問題に対する共通の理理解をすることが⼤大事• 時間がないことをみんなに理理解してもらう：インタビューまですでに残り 4 ⽇日• HEART Framework と Goals-‐Signals-‐Metrics process をうまく使う• Goals: そもそも達成したいこと (Youtube のビデオを⾒見見つけやすくする、等)• Signals: ゴールに対する少し低いレベルの数値 (Youtube のビデオ視聴時間、等)• Metrics: より詳細なレベル (A/B テストが⾏行行えるぐらい) の数値 (Youtube の⼀一⽇日のユーザーあたりのビデオ視聴時間の平均、等)19Tips for Day 1Definition Goals Signals MetricsHappiness ユーザーの態度度（満⾜足度度、使いやすさ、NPS）Engagement ユーザーの関与（頻度度、関わりの深さ：PV, DAU）Adoption 製品や機能に対する新規ユーザー（過去⼀一週間の登録ユーザー、新機能利利⽤用）Retention 既存ユーザーの動向（次に帰ってくる時間、チャーンレート）Task Success タスクの成功率率率（タスク達成の時間、成功率率率）

Day 2 の成果物はストーリーボードとそれに対する投票（決定）Crazy 8s や、それを基にしたストーリーボードの作成、そして最終的な投票結果が Day 2 の成果物となる。http://www.gv.com/lib/the-‐product-‐design-‐sprint-‐divergeday2 21Day 2 Outcome: Voted Storyboards

Day 2 の⽬目的1. Day 1 で決めた問題を解決するための多くの可能性を明るみに出す2. 短い期間で可能性を出すために、時間に明確な制限を設けて進めていく22Objectives of Day 2: Diverge

Day 2 のプロセスDay 2 のプロセスで重要なのは• 各⾃自が個別に静かに⾃自分のアイデアを書き出す (No Brainstorming!!)• 実は古いアイデア（以前思いついていたアイデア）が有効だったりする……古いアイデアから書き出そう！（新しく思いついたアイデアには往々にして過⼤大評価の傾向にある）• 紙を使おう。早く書こう。High fidelity なモックアップは不不要。神を使えばみんなで貢献できるし、特定のアイデアに固執することもなくなる。できれば太いペンを使おう。気を付けておきたいのは、• Storyboard (Step 5) を書き出すまでは誰とも何もシェアしないそれまで気にせず書こう！23Day 2 Process問題を分けて選ぶノートを取る(5 分)マインドマップ(10 -‐ 15 分)Crazy 8s(5 分)ストーリーボード(10 -‐ 20 分)Silent Critique(5 -‐ 10 分)3 min Critique(3 分/idea)Super Vote(5 分)12345678

ユーザーストーリーをチャンクに分けられる場合は分けるユーザーストーリーダイアグラムが2つ以上のチャンクに分かれる場合（多くの場合はそうなる）は、問題を分けてから取り組む。2つ以上のチャンクに分かれた場合、それぞれの問題について Step 2 以降降のサイクルを回していく。ただしそれぞれの問題に別のチームをアサインするのは避けること。全体観がなくなる。チャンクが多すぎる場合は、今回のスプリントで⾏行行う問題をさらに⼩小さく選ぶこと。242.1 Choose Part of the Problem問題を分けて選ぶノートを取る(5 分)マインドマップ(10 -‐ 15 分)Crazy 8s(5 分)ストーリーボード(10 -‐ 20 分)Silent Critique(5 -‐ 10 分)3 min Critique(3 分/idea)Super Vote(5 分)12345678

各⾃自がアイデアをノートに書いていくホワイトボードに書いてあるユーザーダイアグラムや、昨⽇日のディスカッションの結果の “How might we” (どうやったら解決できるか) ポストイットを貼り出したり、あるいはノートを貼り出したりして、昨⽇日の議論論を脳に叩き込む。そのときそれぞれがノートや紙を持ち、有⽤用だと思ったものを書いておく。252.2 Take Notes問題を分けて選ぶノートを取る(5 分)マインドマップ(10 -‐ 15 分)Crazy 8s(5 分)ストーリーボード(10 -‐ 20 分)Silent Critique(5 -‐ 10 分)3 min Critique(3 分/idea)Super Vote(5 分)12345678

アイデアを⽣生むためのマインドマップを作る思いついたものをどんどん繋げていマインドマップを紙に書いていく。マインドマップは今後の UI スケッチの cheat sheet となる。⾃自分しか⾒見見ないので、絵でも⽂文字でもリストでもなんでもいい。262.3 Mind Map問題を分けて選ぶノートを取る(5 分)マインドマップ(10 -‐ 15 分)Crazy 8s(5 分)ストーリーボード(10 -‐ 20 分)Silent Critique(5 -‐ 10 分)3 min Critique(3 分/idea)Super Vote(5 分)12345678

5 分で 8 つのデザインを描いていくA4 (A3) の紙を 8 つのパネルができるように折り、それぞれのパネルに問題を解決できるようなデザインを、なんでもいいので書いていく。5 分ですべてを完成させる、つまり 1 パネル 40 秒で書こう！（実際は30 秒で書いて 10 秒休むぐらい）詰まってしまった場合は、前のスケッチを少し変えてみたりして、深堀りしてみてもよい。また古いアイデアでも OK。Crazy 8s は慣れないうちは 2 度度⾏行行うとコツがつかめる。このとき Bit Timer を使うと便便利利。272.4 Crazy Eights問題を分けて選ぶノートを取る(5 分)マインドマップ(10 -‐ 15 分)Crazy 8s(5 分)ストーリーボード(10 -‐ 20 分)Silent Critique(5 -‐ 10 分)3 min Critique(3 分/idea)Super Vote(5 分)12345678

最も気に⼊入ったデザインのアイデアを最低 1 つ以上ポストイットに描くこのステップではユーザーストーリーダイアグラムをより具体的にしていく。まず A4 の紙に 3 つのポストイットを貼る。それぞれのポストイットがストーリーボードの 1 フレームに対応すると考える。282.5 Storyboard問題を分けて選ぶノートを取る(5 分)マインドマップ(10 -‐ 15 分)Crazy 8s(5 分)ストーリーボード(10 -‐ 20 分)Silent Critique(5 -‐ 10 分)3 min Critique(3 分/idea)Super Vote(5 分)12345678マインドマップと Crazy 8s の中からベストだと思う 1 つ以上を選び、その詳細を書いていく。注意点は、• それぞれを独⽴立立させる（⼝口頭の説明がなくても意味が分かるように）• 匿匿名のままにする（⾃自分の名前を書かない）• アイデアにタイトルを付ける（あとで議論論しやすくするため）終わったら紙を壁に張り付けていく。美術館の絵画のように横⼀一列列に。

喋らずに、良良いと思ったアイデアにシールを貼っていく全員が丸型のシールを持ち、壁に張り出されたアイデアのうち、良良いと思ったものにシールを張っていく。シールを貼る数に制限はないし、⾃自分のアイデアにシールを貼って⾏行行ってもいい。ただしこのとき誰もしゃべらないようにすること。この結果、アイデアに対するヒートマップが出来上がり、どのアイデアに⼈人気が集まっているかが⼀一⽬目でわかる。292.6 Silent Critique問題を分けて選ぶノートを取る(5 分)マインドマップ(10 -‐ 15 分)Crazy 8s(5 分)ストーリーボード(10 -‐ 20 分)Silent Critique(5 -‐ 10 分)3 min Critique(3 分/idea)Super Vote(5 分)12345678

みんなが良良いと思ったアイデアの発案者は 3 分間でそのアイデアの詳細を話す権利利を得る全員でどのアイデアが好きだったかを議論論し、⼈人気のあるアイデアを書いた⼈人に 3 分間以内で説明してもらう。（全員が全員のアイデアを話すのは時間がかかりすぎるので避ける）必要であれば、写真でアイデアを撮って、それを PC に取り込んでプロジェクターに映しながら検討するのもいい（ただし時間は 15 分+)302.7 Three-‐minute Critique問題を分けて選ぶノートを取る(5 分)マインドマップ(10 -‐ 15 分)Crazy 8s(5 分)ストーリーボード(10 -‐ 20 分)Silent Critique(5 -‐ 10 分)3 min Critique(3 分/idea)Super Vote(5 分)12345678

決定権者を中⼼心に、ベストなデザインを決定する全員が “special” なシール（シールにマークを書いたりしたもの）を 1 or 2 つ持ち、ベストだと思うアイデアに super vote する。もし CEO がすべての決定権を持つような⽂文化のチームであれば、CEOに 3 つのシールを渡してもいいし、CXO なら CXO に渡す。そこは正直に、make the call できる⼈人に extra vote の権利利を作ろう。エリート主義的ではあるが、コンセンサスはデザインを殺すし、決定権者が納得していない案を進めるとあとで後悔する。サイクルが終わったら、次にフォーカスすべきチャンクについて議論論し、チャンクを決める。そして次のチャンクで同じサイクルを回す。2 回⽬目以降降のサイクルはもっと簡単なので安⼼心しよう！でも⼤大体 1 ⽇日 2, 3 回すると疲れ切切るので注意。312.8 Super Vote問題を分けて選ぶノートを取る(5 分)マインドマップ(10 -‐ 15 分)Crazy 8s(5 分)ストーリーボード(10 -‐ 20 分)Silent Critique(5 -‐ 10 分)3 min Critique(3 分/idea)Super Vote(5 分)12345678

Day 3 Outcomes: Whiteboard User Storyhttp://www.gv.com/lib/the-‐product-‐design-‐sprint-‐decideday3 33

http://www.gv.com/lib/the-‐product-‐design-‐sprint-‐decideday3 34Battle Royale

Day 3 の⽬目的1. どの解決策のプロトタイプを作るのか、Best Shot もしくは Battle Royale するかを決めるPoint• 意思決定はつらいものだけれど、すべてのアイデアをプロトタイピングしたりテストできないので絞る必要がある• スプリント中は、通常の会社の意思決定の仕組みよりもより “⺠民主的” になる傾向があるが、これは実際にプロダクトなので、会社の意思決定の仕組みを採⽤用する。たとえばCEO がやるといったらやる！という会社ならこのスプリントでもそうするし、ファシリテーターはそのように促さなければならない（衆愚の罠にかからないように）• ファシリテーターは “Make the call” (最終決定してくれ) と決定権者に⾔言い続ける35Objectives of Day 3

Day 3 のプロセス最初にするのはコンフリクトを探すこと。コンフリクトを探すために、前⽇日のストーリーボードをじっくりと読み込むところから始める。準備が整ったら次に進もう。36Day 3 Process意⾒見見のコンフリクトを探すbest shot か battle royaleかを決める前提とテストの⽅方法を決める詳細なユーザーストーリーを描く1234

皆の意⾒見見が分かれている場所、コンフリクトを探す同じ問題に対する複数のアプローチが出ている場合、それを Conflict と呼ぶ。この Conflict が製品のための⾦金金脈となる。Conflict はそれぞれポストイットに書き出すこと。たとえば、LandingPage のユーザーダイアグラムに、「ビデオ」「⼀一枚ぺら」「⼀一枚の製品画像」という3案が出ている場合 Conflict が発⽣生している。すべての Conflict をポストイットに書き出して、カテゴリに分けて壁に貼っていく。373.1 Search for Conflicts意⾒見見のコンフリクトを探すbest shot か battle royaleかを決める前提とテストの⽅方法を決める詳細なユーザーストーリーを描く1234通常デザイナーはアプローチを⼀一つ選び、詳細なプロトにして持っていくが、このようにすることで決定すべきポイントがマップされ、さまざまな可能性が検討されるようになる。

コンフリクトを解消する (best shot を選ぶ) か、もしくはコンフリクトを並⽴立立させて battle roylae を⾏行行うコンフリクトに対して⼆二つの対処法がある。「Best Shot」か「BattleRoyale」である。Best な⼀一つのプロトタイプだけを作るか、複数のプロトタイプを作るか、である。Best shot はプロトタイプをより早く作れるし、ユーザースタディも簡単になるし、ユーザーの競合に対する反応なども聞く時間ができる。Battle royale は新しい領領域に対するアプローチの時に有効で、どの⽅方法がユーザーにとって最適なのかが分かる。ただし時間はかかるし、ユーザースタディの効率率率も悪くなる。なお⾯面⽩白いことに、 Battle royale はダークホース的なデザインがユーザースタディでは最もウケが良良かったりする驚きを提供してくれる。もちろんこれらのハイブリッドでも問題がない。たとえば best shot でプロトを作ってみたものの、ユーザースタディでうまくいかなければbattle royale を⾏行行う、など。最終的には gut check を⾏行行って best shot か battle かを決める。納得していない⼈人が多ければ battle すべき。383.2 Best Shot or Battle Royale?意⾒見見のコンフリクトを探すbest shot か battle royaleかを決める前提とテストの⽅方法を決める詳細なユーザーストーリーを描く1234

検証するべき前提 (assumption) と、それに対応するテストの⽅方法を決めるユーザースタディでテストしたいことを決めるには、前提や想定(assumption) を明らかにすることが有効。テストに対する前提にはたとえば、ユーザーの前提（e.g. 写真をアップロードしたいユーザーがいる）、ビジネスの前提（e.g. 市場規模）、技術の前提、メッセージングの前提などがある。これらの前提を確認するためにプロトタイプを使ってテストする。たとえば、ユーザーが製品を使って写真を快くシェアするかどうか、といったようなものをプロトタイプを使ってもらってテストする。393.3 Test Your Assumptions意⾒見見のコンフリクトを探すbest shot か battle royaleかを決める前提とテストの⽅方法を決める詳細なユーザーストーリーを描く1234技術の前提はエンジニアに試してもらえばいいが、そのほかの前提すべてをテストできそうにない場合は重要度度の低いものは次に回す。どのコンフリクトを探求すべきか、どの前提のテストをするかを決めれば、次はついにプロトタイピングの時間。

詳細なユーザーストーリーをホワイトボードに描き、プロトタイピングのベースとするプロトタイピングする前に詳細なストーリーボードをホワイトボードに書いていく。ユーザーが実際に体験するものになるので、click by click で画⾯面を分ける。これがプロトタイプの spec になる。なおこのストーリーボードはスプリント最後のグループワークである。ホワイトボードに⼤大きなグリッドを描き、それぞれの⼤大きさは A4 の紙 2 つ分ぐらい。それぞれのセルには⼀一つのアクションを置く。クリックやテキスト⼊入⼒力力、ピンチなどなど。セルの画⾯面の詳細は気にしなくていいが、すべてのアクションがストーリーに⼊入っていることが重要。403.4 Whiteboard the User Story意⾒見見のコンフリクトを探すbest shot か battle royaleかを決める前提とテストの⽅方法を決める詳細なユーザーストーリーを描く1234書いている途中に、ユーザースタディのことを考えながら書くといい。どうやって製品にたどり着くのか？等ファシリテーターは⼀一⼈人が全部を書かないように気を付ける。グループ全体が参与するように気を付ける。

Day 3 の tips• 常に戦う準備をしておくこと (Keep the gloves off)• ストーリーボードを描くには、たくさんの⼩小さな決定をしなければならない。そのときに集団の同意を取るのではなく、CEO に “make the call” してもらう。• どうしても決められないときは battle royale にする• ただし Battle royale を「決めることから逃げる」ことに使わない41Tips for Day 3

Day 4 の成果物は「ユーザーに⾒見見せることができて」「最⼤大限の学習効果が得られる」プロトタイプユーザーに触ってフィードバックをもらえるプロトタイプが Day 4 の成果物となる43Day 4 Outcomes: Prototype

Day 4 の⽬目的1. Day 3 のストーリーボードを基に、ユーザースタディのための High Fidelity なプロトタイプを作るPoint• Crazy Deadline はすぐそこ：明⽇日にはユーザースタディが始まる• プロトタイプは Day 5 の Validate を通した「学習」のためにあることを忘れないこと（デザイン上の傑作はいらない）• 学習を⾏行行うに⼗十分なプロトタイプ作成のポイント• ⾒見見た⽬目が最低限リアルであること (Keynotopia などを使う)• リアルなテキストを書くこと（lorem ipsum ではないテキスト）• データの品質や Email のパーソナルコンテンツに関係する場合はコードを書く• でも⼗十中⼋八九 PowerPoint や Keynote で事⾜足りる• プロトタイピングサービスをうまく使おう44Objectives of Day 4

パワポと Keynote をプロトタイプに使いましょうPowerPoint や Keynote がメインのプロトタイピングツールとなる。これらなら:• デザイナーでなくてもデザインできる• アニメーションも簡単• PDF にしてしまえばモバイルでも開ける• ユーザースタディのフィードバックも反映しやすい。現実の製品に近づけるには、Keynotopia などの素材をうまく使う。コードを書き出すと時間がかかるので、コードは極⼒力力書かないようにする45PowerPoint / Keynote: Prototyping Tool

Day 4 のプロセスプロトタイピングの時間は少ないので、Time Timer で管理理していく。完璧なものを作るならデザイナー⼀一⼈人でやったほうがよいが、今回はユーザーテストに Good Enough なプロトを作るのが⽬目的なので、このプロセスは役割分担しながら全員でやったほうが早い。46Day 4 Process作業分担を決めるAsset Library を作る（必要あれば）各⾃自作業を⾏行行うLightning Critique を定期的に⾏行行う (5 分)Outsider Review を⾏行行う (30 分)細部をチェックする123456

役割を分けて担当を明確にする極⼒力力多くの⼈人が PowerPoint や Keynote を持っているのがベスト。それぞれ画⾯面の担当を振り分けて、最終的なクリーンアップはデザイナーが⾏行行えばいい。担当振り分けの際、昨⽇日のストーリーボードを⾒見見て、battle royale のところはチャンクを分けてアサインする。進みの速い⼈人を⼤大変なところにアサインしていくなどの⼯工夫が必要。⼀一⼈人を「Stitcher」としてアサインすること。スライドを⼀一つにまとめてフローにする。Battle royale の場合はそれぞれに stitcher を⽤用意。そのほかメールチェックしている⼈人がいたら指摘する⼈人、時間管理理する⼈人（1時間に1回休憩を⼊入れる⼈人）などが必要（ファシリテーターが兼任する場合も）。474.1 Divide and Conquer作業分担を決めるAsset Library を作る（必要あれば）各⾃自作業を⾏行行うLightning Critique を定期的に⾏行行う (5 分)Outsider Review を⾏行行う (30 分)細部をチェックする123456

ライブラリが必要なら作る共通のビルディングブロックが発⽣生しそうなところは、アセットライブラリ化を検討する。テンプレートを作ったり、スクリーンショットや、ユーザーアバター、ロゴ、サンプルテキスト等々、必要だと思うものはライブラリ化する。ブラウザーバーなどもリアリズムのためには⼤大事なので、持っていない場合は必ずつくること。484.2 Build an Asset Library作業分担を決めるAsset Library を作る（必要あれば）各⾃自作業を⾏行行うLightning Critique を定期的に⾏行行う (5 分)Outsider Review を⾏行行う (30 分)細部をチェックする123456

各⾃自作業！各⾃自担当した UI 作成の作業！1 時間に⼀一度度ぐらいは休憩を取りましょう。494.3 Work作業分担を決めるAsset Library を作る（必要あれば）各⾃自作業を⾏行行うLightning Critique を定期的に⾏行行う (5 分)Outsider Review を⾏行行う (30 分)細部をチェックする123456

簡単な批評を⾏行行う途中で簡単な critique を⾏行行うのが有効。⼀一貫性を担保するためや、外からデザインを⾒見見てもらってフィードバックをもらう。しかし critique は時間を使う傾向にあるので、5 分に収めることを推奨する。他⼈人のデザインを⾒見見て他のデザインを進めたくなる場合、それは次回のスプリントのためにとっておく。（Lightning critique は疑問を⽣生むのに良良い機会となるけれど、この画⾯面は今作っている⼈人が責任をもって作っているものと⼼心得る）504.4 Lightning Critique作業分担を決めるAsset Library を作る（必要あれば）各⾃自作業を⾏行行うLightning Critique を定期的に⾏行行う (5 分)Outsider Review を⾏行行う (30 分)細部をチェックする123456

外の⼈人を読んで簡単なレビューを⾏行行ってもらう30 分、今⽇日デザインに関わっていない⼈人にユーザーリサーチャーとして来てもらう。もしくは PowerPoint などを持っていなかった⼈人でもいい。外からの⽬目は groupthink の罠から遠ざけてくれる。できれば⼀一⽇日の早い段階で⾒見見てもらうこと。遅かったらもう出来上がってしまっているので、できれば早いうちに⾒見見てもらう。514.5 Review with an Outsider作業分担を決めるAsset Library を作る（必要あれば）各⾃自作業を⾏行行うLightning Critique を定期的に⾏行行う (5 分)Outsider Review を⾏行行う (30 分)細部をチェックする123456

⼗十分な製品に⾒見見えるように細部に気を付けるマウスポインタやテキスト、ユーザーがどこをクリックするか、とか、テキスト⼊入⼒力力後の画⾯面など、細かいところはできるだけ⼊入⼒力力するようにする。そのほうがユーザースタディがよりリアルになる。そのほか細部で気を付ける点として、• ⼀一貫性やタイポには気を付けること。特にユーザーデータ（⼭山⽥田太郎郎とかになっていないか）。• コンテンツは最新で関連のあるものにしておくこと。たとえばシアトルでテストするなら、新聞は Seattle Times にすべき。• スタックしたときには「何を学ぼうとしているか」を思い出すこと。30分をボタンのスタイルなどで失ってはいけない。ユーザーに何のValue Prop を理理解してもらいたいかを考える。「細部」の具体的な例例として Google Ventures で実際に作られた以下のプロトタイプが参考になる。https://www.dropbox.com/sh/b5le4kch8m3eor8/aZ6qZcUBTk/Design%20Staff%20Prototypes524.6 Crucial Details作業分担を決めるAsset Library を作る（必要あれば）各⾃自作業を⾏行行うLightning Critique を定期的に⾏行行う (5 分)Outsider Review を⾏行行う (30 分)細部をチェックする123456

54Day 5 Outcome: Scoreboard

55LearnDesign Sprint は迅速な学習にフォーカスする

Day 5 の⽬目的1. どのアイデアが受け⼊入れられ、どのアイデアが受け⼊入れられないのかを、ユーザーにプロトタイプを⾒見見せることによってテストを⾏行行い、テストを通して学ぶTips• インタビューはユーザビリティテストではない！「顧客が製品をどのように理理解したか」「競合製品や代替品として何を使っているか」などを学習するためのテスト56Objectives of Day 5

インタビューを効果的に⾏行行うためのリソース集インタビューを⾏行行うコツを解説したリソースは多数あるので、外部リソースを参照のこと。「半構造化インタビュー」で検索索すればある程度度 Web でもやり⽅方は書いてある。• 本• Interviewing Users: How to Uncover Compelling Insights• Running Lean• About Face 3• ユーザビリティエンジニアリング• IDEO Human Centered Design Toolkit• Google Ventures• GV Guide to Research• Get Better Data from User Studies: 16 Interviewing Tips• How to Hack Your Body Language for Better Interviews• Startup Lab Workshop: User Research, Quick ‘n’ Dirty (Video)57New to Interview?

Day 5 のプロセス始める前に何より、インタビューは学習するために⾏行行うということを意識識すること。プロトタイプを改善していくための⽰示唆を得る。インタビューする⼈人と観察する⼈人は分ける。ユーザーにとって不不快にならないように、できれば⼤大勢の観察者は異異なる部屋で観察を⾏行行うこと。58Day 5 Processキークエスチョンをリスト化する観察ルームをセットアップするAV テストを⾏行行う役割分担を決めるインタビューを⾏行行う (BR 案すべて)振り返りミーティングを毎回⾏行行う123456次のスプリントの検討をする7

キーとなる質問をリスト化して半構造化インタビューの準備を⾏行行う全員でキーとなる質問をリスト化して、半構造化インタビューに備える。そのための Tips として、• Conflict と assumption についてもう⼀一度度確認すること。ユーザースタディでテスト可能な assumption であればリストに加える。• Battle royale 状態のプロトタイプがあるかどうか。もしあるのであればインタビュワーはその違いをきちんと理理解して正しい質問をすること• 本物の競合製品などを⽐比較のために⾒見見せることを検討する• 今⽇日のユーザーテストはユーザビリティテストではないことに気を付ける。ユーザーがきちんと製品を理理解できているか、どんな競合製品や代替品を使っているかなどを⾒見見つけるためのテストである• 予想だにしなかったインサイトを⾒見見つけることフォーマットは独⾃自のものでも良良い595.1 List Your Key Questionsキークエスチョンをリスト化する観察ルームをセットアップするAV テストを⾏行行う役割分担を決めるインタビューを⾏行行う (BR 案すべて)振り返りミーティングを毎回⾏行行う123456次のスプリントの検討をする7

観察ルームをセットアップするインタビュールームと観察ルームをできれば分けて⾏行行う。そのために、観察ルームをセッティングする必要がある。観察ルームからはビデオでインタビューセッションの内容が⾒見見れたり、ノートをとれたりするような環境にすること。そのために、• 部屋全体の雰囲気を撮影するための PC のカメラ + ⾳音声を拾拾ってSkype や Hangout での共有• ユーザー操作⽤用 PC での Skype を通した PC 操作画⾯面の共有• Miracast / Airplay でのユーザー操作モバイルの画⾯面の共有などをセットする。605.2 Set Up the Observation Roomキークエスチョンをリスト化する観察ルームをセットアップするAV テストを⾏行行う役割分担を決めるインタビューを⾏行行う (BR 案すべて)振り返りミーティングを毎回⾏行行う123456次のスプリントの検討をする7

AV テストを⾏行行う利利⽤用するツールの AV テストは必ず事前に⾏行行う。特に、• ⾳音質• ビデオの位置• 画⾯面共有の状況については必ずチェックする。⾳音質が悪ければ conferencing microphone などを⽤用意する。また、観察ルーム側のマイクは mute にしておく。このテストはできるだけ毎セッションごとに⾏行行う。⼤大体デモには悪魔が潜む。615.3 Test the AV Ahead of Timeキークエスチョンをリスト化する観察ルームをセットアップするAV テストを⾏行行う役割分担を決めるインタビューを⾏行行う (BR 案すべて)振り返りミーティングを毎回⾏行行う123456次のスプリントの検討をする7

役割分担を決めるインタビュワーと観察ルームの2つで⼤大きく役割分担を⾏行行う。観察ルームの中でさらに役割分担を⾏行行う。• 基本的に全員紙にノートを取る役⽬目を負う。良良いところも悪いところも予想外のことも、気づいたことはすべてノートにメモっておく（PC は閉じておくことが望ましい）• ⼀一⼈人のみ PC を開いて裁判報告官のようにすべての⾔言葉葉をリアルタイムに筆記するようにする（疲れるので毎回変わると良良い）。これはのちにリファレンスとして利利⽤用される。録⾳音に逃げないように。625.4 Rolesキークエスチョンをリスト化する観察ルームをセットアップするAV テストを⾏行行う役割分担を決めるインタビューを⾏行行う (BR 案すべて)振り返りミーティングを毎回⾏行行う123456次のスプリントの検討をする7

効果的なインタビューを⾏行行うインタビューを⾏行行う。635.5 Doing an Interviewキークエスチョンをリスト化する観察ルームをセットアップするAV テストを⾏行行う役割分担を決めるインタビューを⾏行行う (BR 案すべて)振り返りミーティングを毎回⾏行行う123456次のスプリントの検討をする7

1セッションが終わるごとにスコアボードに全員で記⼊入していくスコアボードを⽤用意して、皆のノートをまとめていく。列列ごとにインタビュイーの枠を設け、⾏行行は各インタビューパート（バックグラウンドや、プロトタイプ 1 / 2、etc）に充てるインタビューセッション⼀一つが終わるごとに、スコアボードに全員の気づきを書いていく。そのとき、• 緑⾊色：良良かった点• ⾚赤⾊色：問題点、疑問点• ⿊黒⾊色：その他としておくと分かりやすい。645.6 Make a Scoreboardキークエスチョンをリスト化する観察ルームをセットアップするAV テストを⾏行行う役割分担を決めるインタビューを⾏行行う (BR 案すべて)振り返りミーティングを毎回⾏行行う123456次のスプリントの検討をする7書き終え次第、次のインタビュイーへのインタビューを⾏行行う。

インタビューの傾向インタビューを⾏行行うと、観察者側は⼤大体こういうパターンをたどる傾向にある。• 1つ⽬目のセッション「俺たちは天才だ」「俺たちはバカだ」• ⼈人はそれぞれ違うので気にしないこと。次のセッションに⾏行行こう• 2 〜～ 4 つ⽬目のセッション「これは複雑だ…」• 5 〜～ 6 つ⽬目のセッション「パターンが⾒見見えてきた！」• パターンが⾒見見えてきたらノートをダブルチェックするとさらに有効。スコアボードに 2, 3 度度出てきたことをチェックして、⼤大きな印をつけておく「うまくいったこと」「解決すべき問題点」がインタビューを通して分かってきたら、次にやるべきことを CEO や決定権者がリスト化しておく。65Observing Humans

次のスプリントの計画を⽴立立てるインタビューがすべて終了了したら、スプリントを終わる前に次のスプリントについて検討する。その時、ケースによって次のスプリントを⾏行行うかどうかを決める。A) ほとんどの物事がうまくいったケース修正すべき点を⾒見見つけて、プロトタイプを修正し、Day 3 (Decide) からやり直すと良良いB) いくつかの⼤大きな疑問が⽣生まれたケース最も多いケースがこちら。いくつかは上⼿手くいったが、いくつかは微調整が必要、いくつかはダメ、というケース。幸いなことにプロトタイプは修正しやすいので、次のスプリントに⾏行行く。次のスプリントは Day 2 (Diverge) からやり直すと良良いC) 全部だめだったケースよくあるケース。ただ失敗ではない。何がダメだったか学べたのは前進であるし、実際にモノを何か⽉月も使って作ってリリースしたときよりも短い時間で分かったのは良良いことだと思おう。次のスプリントは Day 1 (Understand) から始めると良良い。その時に今回の結果を Day 1 の Exercise のときに使おう。665.7 How to Start the Next Sprintキークエスチョンをリスト化する観察ルームをセットアップするAV テストを⾏行行う役割分担を決めるインタビューを⾏行行う (BR 案すべて)振り返りミーティングを毎回⾏行行う123456次のスプリントの検討をする7

Day 5 の tips• リサーチの前に• 必ず何を学びたいのかを明確にすること• ユーザーを dis らない• ユーザーが何かに困ったり⼿手が⽌止まったりしてもユーザーを⾮非難しない。デザインをテストしているのであって、ユーザーが変な⾏行行動をとったのはデザインのせいであり改善ポイントと考える• インタビューのこつ（代表的なもの）• メモのときには Why に集中する• ユーザーが考えていることを⼝口に出していってもらう (Think aloud)• ユーザーが⾔言ったことだけではなく⾏行行動も観察する67Tips for Day 5

Movatterモバイル変換

Change Language

Design Sprint Process / デザインスプリントの実際のプロセスについて

Embed presentation

Recommended

More Related Content

What's hot

Viewers also liked

Similar to Design Sprint Process / デザインスプリントの実際のプロセスについて

More from Takaaki Umada

Design Sprint Process / デザインスプリントの実際のプロセスについて

Editor's Notes