Design Sprint ガイドブック v2

Transcript

• 1. Design Sprint ガイドブック: Step-by-Step for Sprint Masters (2015 March Update) デザインスプリントのプロセス詳細について Takaaki Umada April 11, 2015 (v 2.0) Big Thanks to Google Ventures 1
• 2. 2 Design Sprint とは デザイン上の問題を解決するための 短期間でのスプリント (短距離走)
• 3. デザインスプリントを実施して効果を上げたスタートアップの例 And Others…. • Gmail, Google X, From Google Ventures 3 Case Study: Design Sprint Blue Bottle Coffee Pocket CustomMade Sales growth & Time on site X2 1 sprint+ New users saved the first item more +58% 3 sprints (3 weeks) Customer engagement +300% 3 sprints (3 weeks)
• 4. 4 Design Sprint の最近のアップデート Google Ventures Official Book (洋書、発売未定) Design Sprint Methods (SXSW 2015 by Google & Google [x]) Design Sprint (洋書、8 月発売予定)
• 5. SXSW Interactive 2015 Design Sprints at Google: UX Methods and Mindset で 発表された内容を中心にアップデート。 • Day 0 のアクティビティを追加 • Day 1 のアクティビティの詳細化と追加 • Day 2 のプロセスに一部を追加 何十回か実施してきた中で感じた幾つかの知見も含みます。 5 2015 March Update
• 6. Design Sprint とは 6
• 7. デザイン スプリントとは迅速に学習とプロトタイピングを行うためのメソッド Design Sprint とは • Design Sprint もしくは Product Design Sprint と呼ばれる、デザイン上の問題（新規顧客の離 脱率を下げる、新製品を考える等）を解決するための短期間でのスプリント • Design Thinking や IDEO のメソッド、アジャイルや Gamestorming の方法論などを Google Ventures の Design Studio が特にスタートアップ向けにカスタマイズして提供したもの • Google Ventures や Google X で採用されているほか、すでに 200 以上のスタートアップやプ ロジェクトで利用された実績がある 7 Method for Rapid Learning & Prototyping
• 8. http://www.gv.com/lib/the-gv-research-sprint-a-4-day-process-for-answering-important-startup-questions 8 従来のパターン
• 9. http://www.gv.com/lib/the-gv-research-sprint-a-4-day-process-for-answering-important-startup-questions 9 ×
• 10. 10http://www.gv.com/lib/the-gv-research-sprint-a-4-day-process-for-answering-important-startup-questions
• 11. デザインスプリントの目指すところ 11 Design Sprint http://www.gv.com/lib/the-gv-research-sprint-a-4-day-process-for-answering-important-startup-questions
• 12. デザインスプリントの目指すところ 12 Design Sprint http://www.gv.com/lib/the-gv-research-sprint-a-4-day-process-for-answering-important-startup-questions Day 1-3 Day 4 Day 5
• 13. http://www.fastcodesign.com/1672887/how-to-conduct-your-own-google-design-sprint 13
• 14. 14 LearnDesign Sprint は迅速な学習にフォーカスする
• 15. コアコンセプト • 制限を設ける。特に時間を制限して、短いスプリントを何度も回す。 • 問題と解決策をピンポイントにするためにプロセスを分ける • User Experience をストーリーボードで表す • リアルに近いプロトタイプを作り、インタビューを通して学習する 15 Design Sprint Core Concepts
• 16. タイムライン 16 Timeline 1Day Understand (理解する) チームの意見を聞いたり、リサーチや競合 製品を通して解決したい問題を深掘りする (2 ∼ 5 時間) 2Day Diverge (発散する) できるだけ多くの解決策をラピッドに作る (2 時間 ∼ 1 日) 3Day Decide (決める) もっともすぐれたアイデアを選び、全員で ユーザーストーリーに同意する (2 ∼ 5 時 間) 4Day Prototype (プロトする) ユーザーに実際に見せれるものを素早く （汚く）全員で作り上げる (4 ∼ 8 時間) 5Day Validate (検証する) ビルの外に出て、プロトタイプを実際の ユーザーに見せ、何が良くて何が悪いのか を素早く学ぶ (4 ∼ 6 時間) 0Day Prepare (準備する) 必要な人とモノを集める (所要時間は数時 間)
• 17. Prepare Day 0 17
• 18. キーとなるチャレンジを決める Design Sprint を通して解決したい「キーとなるチャレンジ」を考えて、Challenge Statement を作る準備をしておく。 良い Challenge Statement の条件は以下の 3 つ。 1. 簡潔で、チームのゴールに強く関連付けられている 2. インスパイアされるもの 3. ターゲットとなる顧客あセグメントにフォーカスしているもの 例）Chrome Kids Challenge の Challenge Statement 「2014 年の第 4 四半期にフォーカスした、4 ‒ 7 歳の子供向けの直感的な読書体験を提 供するアプリをデザインする」 18 Key Challenge
• 19. スプリントに必要なチームメンバーを集めてくる 必要なチームメンバーを構成する。プロダクトマネージャーなど、決定権者も構成メン バーに必ず入れること。 理想的には 5 ‒ 8 人。大きなチームになった場合は小さなチームに分けて、同じチャレン ジか異なったチームに分ける。 例） デザイナー x 2 エンジニア x 1 サポート担当者 x 1 プロトタイパー x 1 スプリントマスター x 1 リサーチャー x 1 19 Sprint Team
• 20. 既存のデザインに関する経緯を把握する 既存プロダクトの場合は特に、スプリントマスターが Design Audit (デザイン監査) を リードする。 Design Audit には以下のような活動が含まれる。効果的なスプリントのために必要な情 報を集める。 1. キーとなる stakeholder やプロジェクトをリードする人にインタビューをする 2. 既存のすべてのドキュメントをレビューする 3. 関係するユーザーリサーチをレビューする 4. 現在のデザインをレビューする 5. コアとなるユースケースを特定＆レビューする 20 Design Audit
• 21. 準備物 21 Resource 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 Materials 5 ⽇日間の時間。スプリントの間、すべて の⼈人がすべての時間に参加できるように する Time 以下のものをそろえる。
• 22. まず最初にインタビューするユーザーをリクルートしてから始める 次にやることはインタビューするユーザー 5 人を確保すること。今現時点で何の製品もな く、何が問題か明らかでなくても、とにかく 5 日目のユーザーインタビューのユーザーを リクルートして、インタビューの時間割を決める。 何故 5 人かは Nielsen Norman Group のリサーチを参照のこと 22 Recruit, Recruit, Recruit Users ⽉月 ⽕火 ⽔水 ⽊木 10:00 〜～ 10:30 11:00 〜～ 11:30 12:00 〜～ 12:30 13:00 〜～ 13:30 14:00 〜～ 14:30
• 23. Day 0 用の tips • インタビューのユーザー集めは人づてになることが多いが（特に日本はユーザーインタ ビューに応じてくれる人が少ない）、工数を減らすために外部のサービスを使ったほう が楽だしスクリーニングできる。外部のサービスには以下のようなものがある。 • Craigslist • ゴチソー • 事前にみんなで意識を合わせておくべきことは以下 • 時間を守る。5 分と言われたら 5 分で必ず収める。例外は認められない。 • PC は 4 日目までほぼ使わない。必要がないときは閉じておく。メールもチェック しない。 • スケッチを恐れない • 「絵心がない」は禁句。Day 3 までは伝われば何を描いてもいい • スケッチであることを示すために、太めのペンを使うことを推奨 23 Tips for Day 0
• 24. Understand Day 1 24
• 25. Day 1 の成果物はユーザーストーリーダイアグラム http://www.gv.com/lib/the-product-design-sprint-understandday-1 25 Day 1 Outcome is User Story , looks Like:
• 26. Day 1 の目的 ユーザーのニーズ、ビジネスニーズ、テクノロジのキャパシティを特定し、何がキーとな る戦略でどこにフォーカスするのかを決める。 そのために： 1. 問題に対する全員の知識や見解を共有し、現状の理解を一致させる 2. 今回のスプリントの中でフォーカスするべき一つの問題を決める 26 Objectives of Day 1
• 27. Day 1 の主なプロセス Day 1 のプロセスはエクササイズによる問題に対する理解の一致と、 問題の発見に充てられる。 最終的にはユーザーストーリーと、その中で今回のスプリントで解決 したい問題を決める。そのユーザーストーリーは最終日までの議論の 土台となるので、腹落ちしていないところがあれば各自必ず言うこと 27 Day 1 Process 360 Lightning Talk (15 - 30 分) 競合調査 (10 - 30 分) 顧客インタビュー (30 - 240 分) Stakeholder Map (30 分) 学びや洞察の要約 (30 分) ユーザストーリー (30 分) デザイン原則決定 (30 分) 解決したい問題の 決定 1 2 3 4 5 6 7 8
• 28. 360 ライトニングトーク 360 Lightning Talks はスプリントチーム全体で、様々な視点から 課題を検討するために行われる。特にビジネス、ユーザー、テクノロ ジの 3 つの観点について検討することを忘れないようにする。 少なくとも以下の議題については話すようにすること。 1. ビジネスゴールとサクセスメトリクス (5 分) 2. 技術的な可能性とチャレンジ (5 分) 3. 関係するユーザーリサーチ (5 分) サクセスメトリクスの設定については HEART Framework を参照。 28 1.1 360 Degree Lightning Talk 360 Lightning Talk (15 - 30 分) 競合調査 (10 - 30 分) 顧客インタビュー (30 - 240 分) Stakeholder Map (30 分) 学びや洞察の要約 (30 分) ユーザストーリー (30 分) デザイン原則決定 (30 分) 解決したい問題の 決定 1 2 3 4 5 6 7 8
• 29. 29 HEART Framework & Goals-Signals-Metrics UX のゴールやメトリクスを設定するときには HEART Framework と Goals-Signals-Metrics プロセスが使いやすい (Google でも利用)。 今回のスプリントの中で HEART の中でどれを改善したいのか選び、 Goal から Metrics を決める。以下のような表の一行が埋められる。 • Goals: そもそも達成したいこと (Youtube のビデオを見つけやすくする、等) • Signals: ゴールに対する少し低いレベルの数値 (Youtube のビデオ視聴時間、等) • Metrics: より詳細なレベル (A/B テストが行えるぐらい) の数値 (Youtube の一日 のユーザーあたりのビデオ視聴時間の平均、等) Definition Goals Signals Metrics Happiness ユーザーの態度度（満⾜足度度、使いやすさ、NPS） Engagement ユーザーの関与（頻度度、関わりの深さ：PV, DAU） Adoption 製品や機能に対する新規ユーザー（過去⼀一週間の登録 ユーザー、新機能利利⽤用） Retention 既存ユーザーの動向（次に帰ってくる時間、チャーン レート） Task Success タスクの成功率率率（タスク達成の時間、成功率率率） 360 Lightning Talk (15 - 30 分) 競合調査 (10 - 30 分) 顧客インタビュー (30 - 240 分) Stakeholder Map (30 分) 学びや洞察の要約 (30 分) ユーザストーリー (30 分) デザイン原則決定 (30 分) 解決したい問題の 決定 1 2 3 4 5 6 7 8
• 30. 競合の調査 チームをインスパイアして、やる気をキックスタートすることができ そうなプロダクトやサービスを調査する。 3 ‒ 10 の似たようなプロジェクトを選び簡単なレビューをしてみる こと。 競合だけでなく、例えば EC サイトのようなサービスを作っている場 合は Google Play や App Store などの類似のサービスを探して、ど のように商品をリスト化してみると良い。 30 1.2 Competitive Overview 360 Lightning Talk (15 - 30 分) 競合調査 (10 - 30 分) 顧客インタビュー (30 - 240 分) Stakeholder Map (30 分) 学びや洞察の要約 (30 分) ユーザストーリー (30 分) デザイン原則決定 (30 分) 解決したい問題の 決定 1 2 3 4 5 6 7 8
• 31. 顧客インタビュー 顧客こそプロダクトが良いか悪いかを判断する究極の審判である。そ のため、スプリントをインタビューから始めるのはとても良いアイデ アと言える。 既存のプロダクトのインタビューではどうやってユーザーがプロダク トを使っているのか、そして好きなところや嫌いなところなどを聞く。 新しいプロダクトの場合は、プロダクトが解決したい課題をユーザー が他のどんな方法で解決しているかを中心に聞く。 Lean Customer Development の手法などを参照すると良い。（筆 者の下記ドキュメントも参照のこと） 31 1.3 User Interview 360 Lightning Talk (15 - 30 分) 競合調査 (10 - 30 分) 顧客インタビュー (30 - 240 分) Stakeholder Map (30 分) 学びや洞察の要約 (30 分) ユーザストーリー (30 分) デザイン原則決定 (30 分) 解決したい問題の 決定 1 2 3 4 5 6 7 8
• 32. 顧客インタビュー - フィールドビジット 必要があればインタビューに加えてフィールドビジットも検討する。 顧客にインタビューするよりも、顧客のもとに出向いて顧客がプロダ クトを使うコンテキストを見てみることがより効果的なケースもある。 たとえばテクニカルサポートを行うチームのためのプロダクトを作っ ている場合、彼らがサポートをしている現場に赴き、何をしているの かを観察するのかを見てみると良い洞察が得られやすい。 フィールドビジットはインタビューの効果があるだけではなく、チー ムがコンテキストを理解するのに役立つ。 32 1.3 User Interview: Field Visit 360 Lightning Talk (15 - 30 分) 競合調査 (10 - 30 分) 顧客インタビュー (30 - 240 分) Stakeholder Map (30 分) 学びや洞察の要約 (30 分) ユーザストーリー (30 分) デザイン原則決定 (30 分) 解決したい問題の 決定 1 2 3 4 5 6 7 8
• 33. 関係者マップ プロダクトやサービスは複数のタイプの顧客に対して設計されている ことがある。Stakeholder map では関係しそうな人をリスト化し、 どの stakeholder に注目するかを決める。順序は以下の通り。 1. プロダクトに関係する stakeholder をリスト化する (10 分) 2. 関係者を意味のあるセクションにグループ化する (2 分) 3. スプリント中にフォーカスしてデザインする stakeholder を決め る。またその順序も決める。 4. それぞれのセクションのグループに分けてチームを作るかどうか を検討する たとえば医療系サービスでは、「医療関係者 (医者、ナース、ER)」 「サポートグループ (オンライン、対面)」「患者 (患者本人、子供、 親、友達)」など、3 つのグループと複数の関係者が考えられる。 33 1.4 Stakeholder Map 360 Lightning Talk (15 - 30 分) 競合調査 (10 - 30 分) 顧客インタビュー (30 - 240 分) Stakeholder Map (30 分) 学びや洞察の要約 (30 分) ユーザストーリー (30 分) デザイン原則決定 (30 分) 解決したい問題の 決定 1 2 3 4 5 6 7 8
• 34. 関係者マップ 理解を深めるために、最初のアイデアや洞察をまとめる。 ポストイットを使いアイデアを描き、張り出して見てグループ化する。 良いアイデアについては Silent Critique (後述) で投票し、どの洞察 をより深堀りするのかを決める。 これは「最初のチェック」であり、方向性の最終決定ではないことに 注意すること。また How might we (どうやったらできるか) とい うことを中心に考えてみると良い。 34 1.5 Summary of Learnings and First Ideas 360 Lightning Talk (15 - 30 分) 競合調査 (10 - 30 分) 顧客インタビュー (30 - 240 分) Stakeholder Map (30 分) 学びや洞察の要約 (30 分) ユーザストーリー (30 分) デザイン原則決定 (30 分) 解決したい問題の 決定 1 2 3 4 5 6 7 8
• 35. ユーザーストーリー 35 1.6 User Story 360 Lightning Talk (15 - 30 分) 競合調査 (10 - 30 分) 顧客インタビュー (30 - 240 分) Stakeholder Map (30 分) 学びや洞察の要約 (30 分) ユーザストーリー (30 分) デザイン原則決定 (30 分) 解決したい問題の 決定 1 2 3 4 5 6 7 8 共通理解の上で、協調しながらユーザーストーリーのマップを描く。 必要があれば「最初の利用者」「再来者」「エキスパート」など場合 分けをしてみる。 その際には重要なユーザーストーリーに絞ること。何が重要かは、今 回のスプリントで解決したい問題による。たとえば、 • 顧客の製品の理解を助けたい → 顧客が製品を初めて見た時の体 験を改善する • 新しい製品のコンセプトを作りたい → Value Prop とコアとなる機能 を決める • Landing Page のコンバージョンを 上げたい → なぜ顧客が LP にた どり着くのか、彼らのゴールは何か を理解したい
• 36. デザイン原則の定義 3 つの単語でプロダクトを記述できないか考えてみる。たとえば「簡 単さ」「楽しさ」や「完璧さ」「パワフルさ」なのか。 1. 個々人でチームが気にするべきデザイン原則をリスト化する 2. ベストなアイデアをチームで検討して選ぶ 最終的に顧客を通して検証するときに、この 3 つの原則が伝わってい るかどうかを顧客に聞いてみると良い。 36 1.7 Defining Design Principles 360 Lightning Talk (15 - 30 分) 競合調査 (10 - 30 分) 顧客インタビュー (30 - 240 分) Stakeholder Map (30 分) 学びや洞察の要約 (30 分) ユーザストーリー (30 分) デザイン原則決定 (30 分) 解決したい問題の 決定 1 2 3 4 5 6 7 8
• 37. 解決したい問題の決定 すべてのアイデアについてプロトタイプを作ることはできないので、 このスプリントでどの問題/アイデアにフォーカスするかを決める。 決めるうえで重要なのは、 • プロトタイプを見せたときに、ユーザーから何を学びたいのか？ • 学ぶためにどんなプロトタイプを作るべきなのか？ • 問いかけるのをためらうぐらい「明確な質問」をしてみる：みんな の理解が進む をしっかりと考える。 ファシリテーターは時間制限を付けて問題を決めるようにする。 37 1.8 Focus on the Problem 360 Lightning Talk (15 - 30 分) 競合調査 (10 - 30 分) 顧客インタビュー (30 - 240 分) Stakeholder Map (30 分) 学びや洞察の要約 (30 分) ユーザストーリー (30 分) デザイン原則決定 (30 分) 解決したい問題の 決定 1 2 3 4 5 6 7 8
• 38. Day 1 用の tips • 問題に対する共通の理解をすることが大事 • 時間がないことをみんなに理解してもらう：インタビューまですでに残り 4 日 38 Tips for Day 1
• 39. Diverge Day 2 39
• 40. Day 2 の成果物はストーリーボードとそれに対する投票（決定） Crazy 8s や、それを基にしたストーリーボードの作成、そして最終的な投票結果が Day 2 の成果物となる。 http://www.gv.com/lib/the-product-design-sprint-divergeday2 40 Day 2 Outcome: Voted Storyboards
• 41. Day 2 の目的 1. Day 1 で決めた問題を解決するための多くの可能性を明るみに出す 2. 短い期間で可能性を出すために、時間に明確な制限を設けて進めていく 41 Objectives of Day 2: Diverge
• 42. Day 2 のプロセス Day 2 のプロセスで重要なのは • 各自が個別に静かに自分のアイデアを書き出す (No Brainstorming!!) • 実は古いアイデア（以前思いついていたアイデア）が有効だったり する……古いアイデアから書き出そう！（新しく思いついたアイデ アには往々にして過大評価の傾向にある） • 紙を使おう。早く書こう。High fidelity なモックアップは不要。神 を使えばみんなで貢献できるし、特定のアイデアに固執することも なくなる。できれば太いペンを使おう。 気を付けておきたいのは、 • Storyboard (Step 5) を書き出すまでは誰とも何もシェアしない それまで気にせず書こう！ 42 Day 2 Process 問題を分けて選ぶ マインドマップ (10 - 15 分) Crazy 8s (7 分) 1 Big Idea & Storyboard (20 分) Silent Critique (5 - 10 分) 3 min Critique (3 分/idea) Super Vote (5 分) デザイン批評 (必要があれば) 1 2 3 4 5 6 7 8
• 43. ユーザーストーリーをチャンクに分けられる場合は分ける ユーザーストーリーダイアグラムが2つ以上のチャンクに分かれる場 合（多くの場合はそうなる）は、問題を分けてから取り組む。 2つ以上のチャンクに分かれた場合、それぞれの問題について Step 2 以降のサイクルを回していく。ただしそれぞれの問題に別のチームを アサインするのは避けること。全体観がなくなる。 チャンクが多すぎる場合は、今回のスプリントで行う問題をさらに小 さく選ぶこと。 43 2.1 Choose Part of the Problem 問題を分けて選ぶ マインドマップ (10 - 15 分) Crazy 8s (7 分) 1 Big Idea & Storyboard (20 分) Silent Critique (5 - 10 分) 3 min Critique (3 分/idea) Super Vote (5 分) デザイン批評 (必要があれば) 1 2 3 4 5 6 7 8
• 44. マインドマップ 44 2.2 Mind Map 問題を分けて選ぶ マインドマップ (10 - 15 分) Crazy 8s (7 分) 1 Big Idea & Storyboard (20 分) Silent Critique (5 - 10 分) 3 min Critique (3 分/idea) Super Vote (5 分) デザイン批評 (必要があれば) 1 2 3 4 5 6 7 8 思いついたものをどんどん繋げていマインドマップを紙に書いていく。 マインドマップは今後の UI スケッチの cheat sheet となる。自分し か見ないので、絵でも文字でもリストでもなんでもいい。 How might we (どうやったらできるか) を中心に意識して書くと良 い。
• 45. 5 分で 8 つのデザインを描いていく 45 2.3 Crazy8s 問題を分けて選ぶ マインドマップ (10 - 15 分) Crazy 8s (7 分) 1 Big Idea & Storyboard (20 分) Silent Critique (5 - 10 分) 3 min Critique (3 分/idea) Super Vote (5 分) デザイン批評 (必要があれば) 1 2 3 4 5 6 7 8 A4 (A3) の紙を 8 つのパネルができるように折り、それぞれのパネ ルに問題を解決できるようなデザインをなんでもいいので書いていく。 5 分ですべてを完成させる、つまり 1 パネル 40 秒で書こう！（実際 は 30 秒で書いて 10 秒休むぐらい） 詰まってしまった場合は、前のスケッチを少し変えてみたりして、深 堀りしてみてもよい。また古いアイデアでも OK。 Crazy 8s は慣れないうちは 2 度行うとコツがつかめる。 このとき Bit Timer を使うと便利。
• 46. 5 分で 8 つのデザインを描いていく 46 2.4 1 Big Idea & Storyboard 問題を分けて選ぶ マインドマップ (10 - 15 分) Crazy 8s (7 分) 1 Big Idea & Storyboard (20 分) Silent Critique (5 - 10 分) 3 min Critique (3 分/idea) Super Vote (5 分) デザイン批評 (必要があれば) 1 2 3 4 5 6 7 8 Crazy8s で出たアイデアの中で、個々人で一つのアイデアを選び、 5 分かけてより詳細に描いてもらう。1 ページに収まらない複雑なア イデアのときは、キーとなるステップを中心にストーリーやフローで 描いてもらうようにする。その際の注意点は以下の通り。 • 独立させる（口頭の説明がなくても意味が分かるように） • 匿名のままにする（自分の名前を書かない） • アイデアにタイトルを付ける（あとで議論しやすくするため） 終わったら紙を壁に張り付けていく。美術館の絵画のように横一列に。
• 47. 喋らずに、良いと思ったアイデアにシールを貼っていく 47 2.5 Silent Critique 問題を分けて選ぶ マインドマップ (10 - 15 分) Crazy 8s (7 分) 1 Big Idea & Storyboard (20 分) Silent Critique (5 - 10 分) 3 min Critique (3 分/idea) Super Vote (5 分) デザイン批評 (必要があれば) 1 2 3 4 5 6 7 8 全員が丸型のシールを持ち、壁に張り出されたアイデアのうち、良い と思ったものにシールを張っていく。シールを貼る数に制限はないし、 自分のアイデアにシールを貼って行ってもいい。 ただしこのとき誰もしゃべらないようにすること。 この結果、アイデアに対するヒート マップが出来上がり、どのアイデアに 人気が集まっているかが一目でわかる。
• 48. みんなが良いと思ったアイデアの発案者は 3 分間でそのアイデアの詳細を話す権利を得る 全員でどのアイデアが好きだったかを議論し、人気のあるアイデアを 書いた人に 3 分間以内で説明してもらう。（全員が全員のアイデアを 話すのは時間がかかりすぎるので避ける） 必要であれば、写真でアイデアを撮って、それを PC に取り込んでプ ロジェクターに映しながら検討するのもいい（ただし時間は 15 分+) 48 2.6 Three-minute Critique 問題を分けて選ぶ マインドマップ (10 - 15 分) Crazy 8s (7 分) 1 Big Idea & Storyboard (20 分) Silent Critique (5 - 10 分) 3 min Critique (3 分/idea) Super Vote (5 分) デザイン批評 (必要があれば) 1 2 3 4 5 6 7 8
• 49. 決定権者を中心に、ベストなデザインを決定する 全員が special なシール（シールにマークを書いたりしたもの）を 1 or 2 つ持ち、ベストだと思うアイデアに super vote する。 もし CEO がすべての決定権を持つような文化のチームであれば、 CEO に 3 つのシールを渡してもいいし、CXO なら CXO に渡す。 そこは正直に、make the call できる人に extra vote の権利を作ろ う。 エリート主義的ではあるが、コンセンサスはデザインを殺すし、決定 権者が納得していない案を進めるとあとで後悔する。 49 2.7 Super Vote 問題を分けて選ぶ マインドマップ (10 - 15 分) Crazy 8s (7 分) 1 Big Idea & Storyboard (20 分) Silent Critique (5 - 10 分) 3 min Critique (3 分/idea) Super Vote (5 分) デザイン批評 (必要があれば) 1 2 3 4 5 6 7 8
• 50. デザイン批評 決定権者が納得できない場合は Design Critique を行う。ただし必ず 時間を短時間にして行うこと！ Google Ventures の提案するデザイン批評の注意点は以下の通り。 http://www.gv.com/lib/critique 50 2.8 Design Critique 問題を分けて選ぶ マインドマップ (10 - 15 分) Crazy 8s (7 分) 1 Big Idea & Storyboard (20 分) Silent Critique (5 - 10 分) 3 min Critique (3 分/idea) Super Vote (5 分) デザイン批評 (必要があれば) 1 2 3 4 5 6 7 8 批評ガイドライン • 率直であること • 詳細であること • ゴールとすべて関連づけ ること • うまくいっているところ を認めること • 課題が先で、ソリュー ションは後 • 命令ではなく示唆である こと • 楽しもう ステージの設定 • ビジネスのゴールを確認 する • 顧客のゴールを確認する • 制限を確認する • スケジュールを確認する • 同意できるかのチェック • 忠実度の期待値の設定 • フィードバックの方向付 け 体験をシミュレートする • タスクを選ぶ • コンテキストを確認する • 紙ではなくスクリーンで • ラフなプロトタイプ • 熱くピッチしない • フィードバックを黙って 紙に書き出す
• 51. 次のチャンクに進む サイクルが終わったら、次にフォーカスすべきチャンクについて議論 し、チャンクを決める。そして次のチャンクで同じサイクルを回す。 2 回目以降のサイクルはもっと簡単なので安心しよう！ でも大体 1 日 2, 3 回すると疲れ切るので注意。 51 2.x Next Chunk 問題を分けて選ぶ マインドマップ (10 - 15 分) Crazy 8s (7 分) 1 Big Idea & Storyboard (20 分) Silent Critique (5 - 10 分) 3 min Critique (3 分/idea) Super Vote (5 分) デザイン批評 (必要があれば) 1 2 3 4 5 6 7 8
• 52. Decide Day 3 52
• 53. Day 3 Outcomes: Whiteboard User Story http://www.gv.com/lib/the-product-design-sprint-decideday3 53
• 54. http://www.gv.com/lib/the-product-design-sprint-decideday3 54 Battle Royale
• 55. Day 3 の目的 1. どの解決策のプロトタイプを作るのか、Best Shot もしくは Battle Royale するかを 決める Point • 意思決定はつらいものだけれど、すべてのアイデアをプロトタイピングしたりテストで きないので絞る必要がある • スプリント中は、通常の会社の意思決定の仕組みよりもより 民主的 になる傾向がある が、これは実際にプロダクトなので、会社の意思決定の仕組みを採用する。たとえば CEO がやるといったらやる！という会社ならこのスプリントでもそうするし、ファシリ テーターはそのように促さなければならない（衆愚の罠にかからないように） • ファシリテーターは Make the call (最終決定してくれ) と決定権者に言い続ける 55 Objectives of Day 3
• 56. Day 3 のプロセス Day 3 では主に「どのプロトタイプを作って最終日に検証するか」を 決める。議論していると、議論の最中に新たにスケッチや探索が必要 な場合がある。そのときは怖れずに Day 1 や Day 2 のプロセスに戻 ること。 最初にするのはコンフリクトを探す。 コンフリクトを探すために、前日のストーリーボードをじっくりと読 み込むところから始める。準備が整ったら次に進もう。 56 Day 3 Process 意見のコンフリク トを探す best shot か battle royale かを決める 前提とテストの方 法を決める 詳細なユーザース トーリーを描く 1 2 3 4
• 57. 皆の意見が分かれている場所、コンフリクトを探す 同じ問題に対する複数のアプローチが出ている場合、それを Conflict と呼ぶ。この Conflict が製品のための金脈となる。 Conflict はそれぞれポストイットに書き出すこと。たとえば、 Landing Page のユーザーダイアグラムに、「ビデオ」「一枚ぺら」 「一枚の製品画像」という3案が出ている場合 Conflict が発生してい る。 すべての Conflict をポストイットに書き出して、カテゴリに分けて 壁に貼っていく。 57 3.1 Search for Conflicts 意見のコンフリク トを探す best shot か battle royale かを決める 前提とテストの方 法を決める 詳細なユーザース トーリーを描く 1 2 3 4 通常デザイナーはアプローチを一つ選 び、詳細なプロトにして持っていくが、 このようにすることで決定すべきポイ ントがマップされ、さまざまな可能性 が検討されるようになる。
• 58. コンフリクトを解消する (best shot を選ぶ) か、もしくはコンフリクトを並立させて battle roylae を行う コンフリクトに対して二つの対処法がある。「Best Shot」か 「Battle Royale」である。Best な一つのプロトタイプだけを作るか、 複数のプロトタイプを作るか、である。 Best shot はプロトタイプをより早く作れるし、ユーザースタディも 簡単になるし、ユーザーの競合に対する反応なども聞く時間ができる。 Battle royale は新しい領域に対するアプローチの時に有効で、どの 方法がユーザーにとって最適なのかが分かる。ただし時間はかかるし、 ユーザースタディの効率も悪くなる。 なお面白いことに、 Battle royale はダークホース的なデザインが ユーザースタディでは最もウケが良かったりする驚きを提供してくれ る。 もちろんこれらのハイブリッドでも問題がない。たとえば best shot でプロトを作ってみたものの、ユーザースタディでうまくいかなけれ ば battle royale を行う、など。 最終的には gut check を行って best shot か battle かを決める。 納得していない人が多ければ battle すべき。 58 3.2 Best Shot or Battle Royale? 意見のコンフリク トを探す best shot か battle royale かを決める 前提とテストの方 法を決める 詳細なユーザース トーリーを描く 1 2 3 4
• 59. 検証するべき前提 (assumption) と、それに対応するテストの方法を決める ユーザースタディでテストしたいことを決めるには、前提や想定 (assumption) を明らかにすることが有効。 テストに対する前提にはたとえば、ユーザーの前提（e.g. 写真をアッ プロードしたいユーザーがいる）、ビジネスの前提（e.g. 市場規模）、 技術の前提、メッセージングの前提などがある。 これらの前提を確認するためにプロトタイプを使ってテストする。た とえば、ユーザーが製品を使って写真を快くシェアするかどうか、と いったようなものをプロトタイプを使ってもらってテストする。 59 3.3 Test Your Assumptions 意見のコンフリク トを探す best shot か battle royale かを決める 前提とテストの方 法を決める 詳細なユーザース トーリーを描く 1 2 3 4 技術の前提はエンジニアに試してもら えばいいが、そのほかの前提すべてを テストできそうにない場合は重要度の 低いものは次に回す。 どのコンフリクトを探求すべきか、ど の前提のテストをするかを決めれば、 次はついにプロトタイピングの時間。
• 60. 詳細なユーザーストーリーをホワイトボードに描き、プロトタイピングのベースとする プロトタイピングする前に詳細なストーリーボードをホワイトボード に書いていく。ユーザーが実際に体験するものになるので、click by click で画面を分ける。これがプロトタイプの spec になる。なおこ のストーリーボードはスプリント最後のグループワークである。 ホワイトボードに大きなグリッドを描き、それぞれの大きさは A4 の 紙 2 つ分ぐらい。 それぞれのセルには一つのアクションを置く。クリックやテキスト入 力、ピンチなどなど。セルの画面の詳細は気にしなくていいが、すべ てのアクションがストーリーに入っていることが重要。 60 3.4 Whiteboard the User Story 意見のコンフリク トを探す best shot か battle royale かを決める 前提とテストの方 法を決める 詳細なユーザース トーリーを描く 1 2 3 4 書いている途中に、ユーザースタディ のことを考えながら書くといい。どう やって製品にたどり着くのか？等 ファシリテーターは⼀一⼈人が全部を書か ないように気を付ける。グループ全体 が参与するように気を付ける。
• 61. Day 3 の tips • 常に戦う準備をしておくこと (Keep the gloves off) • ストーリーボードを描くには、たくさんの小さな決定をしなければならない。その ときに集団の同意を取るのではなく、CEO に make the call してもらう。 • どうしても決められないときは battle royale にする • ただし Battle royale を「決めることから逃げる」ことに使わない • チームが新しかったり、意見にバイアスがかかっている傾向にあれば「Thinking Hats」のメソッドを使い、無理やり視点を変えさせてみるのも良い。 • アイデア発想者 • 楽観主義者 • 悲観主義者 • 技術的な実現可能性チェッカー • ユーザーアドボケイト • など 61 Tips for Day 3
• 62. Prototype Day 4 62
• 63. Day 4 の成果物は「ユーザーに見せることができて」「最大限の学習効果が得られる」プロトタイプ ユーザーに触ってフィードバックをもらえるプロトタイプが Day 4 の成果物となる 63 Day 4 Outcomes: Prototype
• 64. Day 4 の目的 1. Day 3 のストーリーボードを基に、ユーザースタディのための High Fidelity なプロ トタイプを作る Point • Crazy Deadline はすぐそこ：明日にはユーザースタディが始まる • プロトタイプは Day 5 の Validate を通した「学習」のためにあることを忘れないこと （デザイン上の傑作はいらない） • 学習を行うに十分なプロトタイプ作成のポイント • 見た目が最低限リアルであること (Keynotopia などを使う) • リアルなテキストを書くこと（lorem ipsum ではないテキスト） • データの品質や Email のパーソナルコンテンツに関係する場合はコードを書く • でも十中八九 PowerPoint や Keynote で事足りる • プロトタイピングサービスをうまく使おう 64 Objectives of Day 4
• 65. パワポと Keynote をプロトタイプに使いましょう PowerPoint や Keynote がメインのプロトタイピングツールとなる。これらなら: • デザイナーでなくてもデザインできる • アニメーションも簡単 • PDF にしてしまえばモバイルでも開ける • ユーザースタディのフィードバックも反映しやすい。 現実の製品に近づけるには、Keynotopia などの素材をうまく使う。 コードを書き出すと時間がかかるので、コードは極力書かないようにする 65 PowerPoint / Keynote: Prototyping Tool
• 66. Day 4 のプロセス プロトタイピングの時間は少ないので、Time Timer で管理していく。 完璧なものを作るならデザイナー一人でやったほうがよいが、今回は ユーザーテストに Good Enough なプロトを作るのが目的なので、 • 役割分担しながら全員で行う • 1 人もしくは少数のプロトタイパーが作る のどちらで進めるかを決める。 プロトタイパーに任せる場合は、残りの人たちは Day 5 のインタ ビュースクリプト作成などを行うと良い。 66 Day 4 Process 作業分担を決める Asset Library を 作る（必要あれば） 各自作業を行う Lightning Critique を定期的に行う (5分) Outsider Review を行う (30 分) 細部をチェックす る 1 2 3 4 5 6
• 67. 役割を分けて担当を明確にする 極力多くの人が PowerPoint や Keynote を持っているのがベスト。 それぞれ画面の担当を振り分けて、最終的なクリーンアップはデザイ ナーが行えばいい。 担当振り分けの際、昨日のストーリーボードを見て、battle royale のところはチャンクを分けてアサインする。進みの速い人を大変なと ころにアサインしていくなどの工夫が必要。 一人を「Stitcher」としてアサインすること。スライドを一つにまと めてフローにする。Battle royale の場合はそれぞれに stitcher を用 意。 そのほかメールチェックしている人がいたら指摘する人、時間管理す る人（1時間に1回休憩を入れる人）などが必要（ファシリテーターが 兼任する場合も）。 67 4.1 Divide and Conquer 作業分担を決める Asset Library を 作る（必要あれば） 各自作業を行う Lightning Critique を定期的に行う (5分) Outsider Review を行う (30 分) 細部をチェックす る 1 2 3 4 5 6
• 68. ライブラリが必要なら作る 共通のビルディングブロックが発生しそうなところは、アセットライ ブラリ化を検討する。テンプレートを作ったり、スクリーンショット や、ユーザーアバター、ロゴ、サンプルテキスト等々、必要だと思う ものはライブラリ化する。 ブラウザーバーなどもリアリズムのためには大事なので、持っていな い場合は必ずつくること。 68 4.2 Build an Asset Library 作業分担を決める Asset Library を 作る（必要あれば） 各自作業を行う Lightning Critique を定期的に行う (5分) Outsider Review を行う (30 分) 細部をチェックす る 1 2 3 4 5 6
• 69. 各自作業！ 各自担当した UI 作成の作業！ 1 時間に一度ぐらいは休憩を取りましょう。 69 4.3 Work 作業分担を決める Asset Library を 作る（必要あれば） 各自作業を行う Lightning Critique を定期的に行う (5分) Outsider Review を行う (30 分) 細部をチェックす る 1 2 3 4 5 6
• 70. 簡単な批評を行う 途中で簡単な critique を行うのが有効。一貫性を担保するためや、 外からデザインを見てもらってフィードバックをもらう。 しかし critique は時間を使う傾向にあるので、5 分に収めることを 推奨する。 他人のデザインを見て他のデザインを進めたくなる場合、それは次回 のスプリントのためにとっておく。（Lightning critique は疑問を生 むのに良い機会となるけれど、この画面は今作っている人が責任を もって作っているものと心得る） 70 4.4 Lightning Critique 作業分担を決める Asset Library を 作る（必要あれば） 各自作業を行う Lightning Critique を定期的に行う (5分) Outsider Review を行う (30 分) 細部をチェックす る 1 2 3 4 5 6
• 71. 外の人を読んで簡単なレビューを行ってもらう 30 分、今日デザインに関わっていない人にユーザーリサーチャーと して来てもらう。もしくは PowerPoint などを持っていなかった人で もいい。外からの目は groupthink の罠から遠ざけてくれる。 できれば一日の早い段階で見てもらうこと。遅かったらもう出来上 がってしまっているので、できれば早いうちに見てもらう。 71 4.5 Review with an Outsider 作業分担を決める Asset Library を 作る（必要あれば） 各自作業を行う Lightning Critique を定期的に行う (5分) Outsider Review を行う (30 分) 細部をチェックす る 1 2 3 4 5 6
• 72. 十分な製品に見えるように細部に気を付ける マウスポインタやテキスト、ユーザーがどこをクリックするか、とか、 テキスト入力後の画面など、細かいところはできるだけ入力するよう にする。そのほうがユーザースタディがよりリアルになる。 そのほか細部で気を付ける点として、 • 一貫性やタイポには気を付けること。特にユーザーデータ（山田太 郎とかになっていないか）。 • コンテンツは最新で関連のあるものにしておくこと。たとえばシア トルでテストするなら、新聞は Seattle Times にすべき。 • スタックしたときには「何を学ぼうとしているか」を思い出すこと。 30分をボタンのスタイルなどで失ってはいけない。ユーザーに何の Value Prop を理解してもらいたいかを考える。 「細部」の具体的な例として Google Ventures で実際に作られた以 下のプロトタイプが参考になる。 https://www.dropbox.com/sh/b5le4kch8m3eor8/aZ6qZcUBTk /Design%20Staff%20Prototypes 72 4.6 Crucial Details 作業分担を決める Asset Library を 作る（必要あれば） 各自作業を行う Lightning Critique を定期的に行う (5分) Outsider Review を行う (30 分) 細部をチェックす る 1 2 3 4 5 6
• 73. Validate Day 5 73
• 74. 74 Day 5 Outcome: Scoreboard
• 75. 75 LearnDesign Sprint は迅速な学習にフォーカスする
• 76. Day 5 の目的 1. どのアイデアが受け入れられ、どのアイデアが受け入れられないのかを、ユーザーに プロトタイプを見せることによってテストを行い、テストを通して学ぶ Tips • インタビューはユーザビリティテストではない！ 「顧客が製品をどのように理解した か」「競合製品や代替品として何を使っているか」などを学習するためのテスト 76 Objectives of Day 5
• 77. インタビューを効果的に行うためのリソース集 インタビューを行うコツを解説したリソースは多数あるので、外部リソースを参照のこと。 「半構造化インタビュー」で検索すればある程度 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) 77 New to Interview?
• 78. Day 5 のプロセス 始める前に何より、インタビューは学習するために行うということを 意識すること。プロトタイプを改善していくための示唆を得る。 インタビューする人と観察する人は分ける。ユーザーにとって不快に ならないように、できれば大勢の観察者は異なる部屋で観察を行うこ と。 78 Day 5 Process キークエスチョン をリスト化する 観察ルームをセッ トアップする AV テストを行う 役割分担を決める インタビューを行 う (BR 案すべて) 振り返りミーティ ングを毎回行う 1 2 3 4 5 6 次のスプリントの 検討をする 7
• 79. キーとなる質問をリスト化して半構造化インタビューの準備を行う 全員でキーとなる質問をリスト化して、半構造化インタビューに備え る。そのための Tips として、 • Conflict と assumption についてもう一度確認すること。ユー ザースタディでテスト可能な assumption であればリストに加える。 • Battle royale 状態のプロトタイプがあるかどうか。もしあるので あればインタビュワーはその違いをきちんと理解して正しい質問を すること • 本物の競合製品などを比較のために見せることを検討する • 今日のユーザーテストはユーザビリティテストではないことに気を 付ける。ユーザーがきちんと製品を理解できているか、どんな競合 製品や代替品を使っているかなどを見つけるためのテストである • 予想だにしなかったインサイトを見つけること フォーマットは独自のものでも良い 79 5.1 List Your Key Questions キークエスチョン をリスト化する 観察ルームをセッ トアップする AV テストを行う 役割分担を決める インタビューを行 う (BR 案すべて) 振り返りミーティ ングを毎回行う 1 2 3 4 5 6 次のスプリントの 検討をする 7
• 80. 観察ルームをセットアップする インタビュールームと観察ルームをできれば分けて行う。そのために、 観察ルームをセッティングする必要がある。 観察ルームからはビデオでインタビューセッションの内容が見れたり、 ノートをとれたりするような環境にすること。そのために、 • 部屋全体の雰囲気を撮影するための PC の カメラ + 音声を拾って Skype や Hangout での共有 • ユーザー操作用 PC での Skype を通した PC 操作画面の共有 • Miracast / Airplay でのユーザー操作モバイルの画面の共有 などをセットする。 80 5.2 Set Up the Observation Room キークエスチョン をリスト化する 観察ルームをセッ トアップする AV テストを行う 役割分担を決める インタビューを行 う (BR 案すべて) 振り返りミーティ ングを毎回行う 1 2 3 4 5 6 次のスプリントの 検討をする 7
• 81. AV テストを行う 利用するツールの AV テストは必ず事前に行う。特に、 • 音質 • ビデオの位置 • 画面共有の状況 については必ずチェックする。 音質が悪ければ conferencing microphone などを用意する。また、 観察ルーム側のマイクは mute にしておく。 このテストはできるだけ毎セッションごとに行う。大体デモには悪魔 が潜む。 81 5.3 Test the AV Ahead of Time キークエスチョン をリスト化する 観察ルームをセッ トアップする AV テストを行う 役割分担を決める インタビューを行 う (BR 案すべて) 振り返りミーティ ングを毎回行う 1 2 3 4 5 6 次のスプリントの 検討をする 7
• 82. 役割分担を決める インタビュワーと観察ルームの2つで大きく役割分担を行う。 観察ルームの中でさらに役割分担を行う。 • 基本的に全員紙にノートを取る役目を負う。良いところも悪いとこ ろも予想外のことも、気づいたことはすべてノートにメモっておく （PC は閉じておくことが望ましい） • 一人のみ PC を開いて裁判報告官のようにすべての言葉をリアルタ イムに筆記するようにする（疲れるので毎回変わると良い）。これ はのちにリファレンスとして利用される。録音に逃げないように。 82 5.4 Roles キークエスチョン をリスト化する 観察ルームをセッ トアップする AV テストを行う 役割分担を決める インタビューを行 う (BR 案すべて) 振り返りミーティ ングを毎回行う 1 2 3 4 5 6 次のスプリントの 検討をする 7
• 83. 効果的なインタビューを行う インタビューを行う。 83 5.5 Doing an Interview キークエスチョン をリスト化する 観察ルームをセッ トアップする AV テストを行う 役割分担を決める インタビューを行 う (BR 案すべて) 振り返りミーティ ングを毎回行う 1 2 3 4 5 6 次のスプリントの 検討をする 7
• 84. 1セッションが終わるごとにスコアボードに全員で記入していく スコアボードを用意して、皆のノートをまとめていく。列ごとにイン タビュイーの枠を設け、行は各インタビューパート（バックグラウン ドや、プロトタイプ 1 / 2、etc）に充てる インタビューセッション一つが終わるごとに、スコアボードに全員の 気づきを書いていく。そのとき、 • 緑色：良かった点 • 赤色：問題点、疑問点 • 黒色：その他 としておくと分かりやすい。 84 5.6 Make a Scoreboard キークエスチョン をリスト化する 観察ルームをセッ トアップする AV テストを行う 役割分担を決める インタビューを行 う (BR 案すべて) 振り返りミーティ ングを毎回行う 1 2 3 4 5 6 次のスプリントの 検討をする 7 書き終え次第、次のインタビュイーへ のインタビューを⾏行行う。
• 85. インタビューの傾向 インタビューを行うと、観察者側は大体こういうパターンをたどる傾向にある。 • 1つ目のセッション「俺たちは天才だ」「俺たちはバカだ」 • 人はそれぞれ違うので気にしないこと。次のセッションに行こう • 2 ∼ 4 つ目のセッション「これは複雑だ…」 • 5 ∼ 6 つ目のセッション「パターンが見えてきた！」 • パターンが見えてきたらノートをダブルチェックするとさらに有効。スコアボード に 2, 3 度出てきたことをチェックして、大きな印をつけておく 「うまくいったこと」「解決すべき問題点」がインタビューを通して分かってきたら、次 にやるべきことを CEO や決定権者がリスト化しておく。 85 Observing Humans
• 86. 次のスプリントの計画を立てる インタビューがすべて終了したら、スプリントを終わる前に次のスプ リントについて検討する。その時、ケースによって次のスプリントを 行うかどうかを決める。 A) ほとんどの物事がうまくいったケース 修正すべき点を見つけて、プロトタイプを修正し、Day 3 (Decide) からやり直す と良い B) いくつかの大きな疑問が生まれたケース 最も多いケースがこちら。いくつかは上手くいったが、いくつかは微調整が必要、 いくつかはダメ、というケース。幸いなことにプロトタイプは修正しやすいので、 次のスプリントに行く。次のスプリントは Day 2 (Diverge) からやり直すと良い C) 全部だめだったケース よくあるケース。ただ失敗ではない。何がダメだったか学べたのは前進であるし、 実際にモノを何か月も使って作ってリリースしたときよりも短い時間で分かった のは良いことだと思おう。次のスプリントは Day 1 (Understand) から始めると 良い。その時に今回の結果を Day 1 の Exercise のときに使おう。 86 5.7 How to Start the Next Sprint キークエスチョン をリスト化する 観察ルームをセッ トアップする AV テストを行う 役割分担を決める インタビューを行 う (BR 案すべて) 振り返りミーティ ングを毎回行う 1 2 3 4 5 6 次のスプリントの 検討をする 7
• 87. Day 5 の tips • リサーチの前に • 必ず何を学びたいのかを明確にすること • ユーザーを dis らない • ユーザーが何かに困ったり手が止まったりしてもユーザーを非難しない。デザイン をテストしているのであって、ユーザーが変な行動をとったのはデザインのせいで あり改善ポイントと考える • インタビューのこつ（代表的なもの） • メモのときには Why に集中する • ユーザーが考えていることを口に出していってもらう (Think aloud) • ユーザーが言ったことだけではなく行動も観察する • チームのエンジニアに聞いて、技術的な実現性のチェックも怠らない 87 Tips for Day 5
• 88. See You Next Sprint!! 88