Design Sprint Process / デザインスプリントの実際のプロセスについて
488 likes150,529 views
デザインスプリントのプロセスと流れについて説明します。 Version 2: http://www.slideshare.net/takaumada/design-sprint-guidebook-v2
Design Sprint Process / デザインスプリントの実際のプロセスについて
- 1. Design Sprint Process デザインスプリントのプロセス詳細について v2: http://www.slideshare.net/takaumada/design-‑sprint-‑guidebook-‑v2 Takaaki Umada August 25, 2014 (v 0.1, draft) Big Thanks to Google Ventures 1
- 2. このスライドは Design Sprint のファシリテーター向けに作られている • Design Sprint のおおよその流流れをつかめるように、プロセスを中⼼心に説明する • Design Sprint の意義について知りたい場合は別の資料料を参考のこと • http://www.slideshare.net/takaumada/design-‐sprint 2 Objectives of this Deck
- 3. 実施の際は v2 もご確認ください。 http://www.slideshare.net/takaumada/design-‐sprint-‐guidebook-‐v2 3 Version 2 があります
- 5. タイムライン 5 Timeline 1Day Understand (理理解する) チームの意⾒見見を聞いたり、リサーチや競合 製品を通して解決したい問題を深掘りする (2 〜～ 5 時間) 2Day Diverge (発散する) できるだけ多くの解決策をラピッドに作る (2 時間 〜～ 1 ⽇日) 3Day Decide (決める) もっともすぐれたアイデアを選び、全員で ユーザーストーリーに同意する (2 〜～ 5 時間) 4Day Prototype (プロトする) ユーザーに実際に⾒見見せれるものを素早く （汚く）全員で作り上げる (4 〜～ 8 時間) 5Day Validate (検証する) ビルの外に出て、プロトタイプを実際の ユーザーに⾒見見せ、何が良良くて何が悪いのか を素早く学ぶ (4 〜～ 6 時間) 0Day Prepare (準備する) 必要な⼈人とモノを集める (所要時間は数時 間)
- 6. デザインスプリントを実施して効果を上げたスタートアップの例例 And Others…. • Gmail, Google X, From Google Ventures 6 Case Study: Design Sprint Blue Bottle Coffee Pocket CustomMade Sales growth & Time on site x2 New users saved the first item more +58% Customer engagement +300%
- 8. 準備物 8 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 以下のものをそろえる。
- 9. まず最初にインタビューするユーザーをリクルートしてから始める 次にやることはインタビューするユーザー 5 ⼈人を確保すること。今現時点で何の製品もな く、何が問題か明らかでなくても、とにかく 5 ⽇日⽬目のユーザーインタビューのユーザーを リクルートして、インタビューの時間割を決める。 何故 5 ⼈人かは Nielsen Norman Group のリサーチを参照のこと 9 Recruit, Recruit, Recruit Users ⽉月 ⽕火 ⽔水 ⽊木 10:00 〜～ 10:30 11:00 〜～ 11:30 12:00 〜～ 12:30 13:00 〜～ 13:30 14:00 〜～ 14:30
- 10. Day 0 ⽤用の tips • インタビューのユーザー集めは⼈人づてになることが多いが（特に⽇日本はユーザーインタ ビューに応じてくれる⼈人が少ない）、⼯工数を減らすために外部のサービスを使ったほう が楽だしスクリーニングできる。外部のサービスには以下のようなものがある。 • Craigslist • ゴチソー • 事前にみんなで意識識を合わせておくべきことは以下 • 時間を守る。5 分と⾔言われたら 5 分で必ず収める。例例外は認められない。 • PC は 4 ⽇日⽬目までほぼ使わない。必要がないときは閉じておく。メールもチェックし ない。 • スケッチを恐れない • 「絵⼼心がない」は禁句句。Day 3 までは伝われば何を描いてもいい • スケッチであることを⽰示すために、太めのペンを使うことを推奨 10 Tips for Day 0
- 12. Day 1 の成果物はユーザーストーリーダイアグラム http://www.gv.com/lib/the-‐product-‐design-‐sprint-‐understandday-‐1 12 Day 1 Outcome is “User Story”, looks Like:
- 13. Day 1 の⽬目的 1. 問題に対する全員の知識識や⾒見見解を共有し、現状の理理解を⼀一致させる 2. 今回のスプリントの中でフォーカスするべき⼀一つの問題を決める 13 Objectives of Day 1
- 14. Day 1 の主なプロセス Day 1 のプロセスはエクササイズによる問題に対する理理解の⼀一致と、 問題の発⾒見見に充てられる。 最終的には皆が合意するユーザーストーリーを描くことになり、その ユーザーストーリーは最終⽇日までの議論論の⼟土台となるので、腹落落ちし ていないところがあれば各⾃自必ず⾔言うこと 14 Day 1 Process Topic を決める エクササイズする (Topic × 10 分) ユーザーストー リーを描く 本スプリントで解 決する問題を決める 1 2 3 4
- 15. 話すべきトピックを決める トピックを決める。トピックには以下のような例例がある。トピックは 価値がないと判断すれば抜いても構わないし、追加しても構わない。 • Business opportunity (市場やビジネス機会について話す) • Lightning demos (競合製品や類似製品を⾒見見てみる) • Lay it out (現製品を使ってユーザーの疑似体験をしてみる) • Success metrics (デザイン上のメトリクスを決める。HEART フレーム ワークなどが参考になる) • Existing research (製品の調査データを使って顧客について知る) • Team interviews (社内のエキスパートに問題について聞いて回る。特 にカスタマーサービスの⼈人は貴重な情報を持っている) • Analytics (機能の usage データやドロップレートなどを⾒見見てみる) 15 1.1 Choose the Topic Topic を決める エクササイズする (Topic × 10 分) 1 2 3 4 ユーザーストー リーを描く 本スプリントで解 決する問題を決める
- 16. 現状理理解を共通にするために各トピックで 10 分のエクササイズ（議論論）を⾏行行う 選んだトピックについて、それぞれ 10 分間議論論する。必ず 10 分の上 限は守ること。 How might we… (… をどうやったら解決できるか?) という疑問形の フォーマットで問うことで適切切な機会を⾒見見つけることができる（e.g. How might we build trust?How might we figure out the user’s style?）。疑 問はすべてポストイットに書いておく。 エクササイズが難しい場合は⼗十分なデータを持っていないというケー スが多いため、⼩小規模なユーザースタディをしたりごく短いオンライ ンサーベイをしたりして新鮮なデータをスプリントを始める前に取っ てくること。 16 1.2 Exercise Topic を決める エクササイズする (Topic × 10 分) 1 2 3 4 ユーザーストー リーを描く 本スプリントで解 決する問題を決める
- 17. 最も重要なユーザーストーリーをスケッチする 共通理理解の上で、協調しながらユーザーストーリーのマップを描く。 描くのはファシリテーター。 その際には重要なユーザーストーリーに絞ること。何が重要かは、今 回のスプリントで解決したい問題による。たとえば、 • 顧客の製品の理理解を助けたい → 顧客が製品を初めて⾒見見た時の体 験を改善する 17 1.3 Sketch the Most Important User Story Topic を決める エクササイズする (Topic × 10 分) ユーザーストー リーを描く 本スプリントで解 決する問題を決める 1 2 3 4 • 新しい製品のコンセプトを作りたい → Value Prop とコアとなる機能を 決める • Landing Page のコンバージョンを上 げたい → なぜ顧客が LP にたど り着くのか、彼らのゴールは何かを 理理解したい
- 18. 今回のスプリントのスコープを決める すべてのアイデアについてプロトタイプを作ることはできないので、 このスプリントでどの問題/アイデアにフォーカスするかを決める。 決めるうえで重要なのは、 • プロトタイプを⾒見見せたときに、ユーザーから何を学びたいのか？ • 学ぶためにどんなプロトタイプを作るべきなのか？ • 問いかけるのをためらうぐらい「明確な質問」をしてみる：みんな の理理解が進む をしっかりと考える。 ファシリテーターは時間制限を付けて問題を決めるようにする。 18 1.4 Focus on the Problem Topic を決める エクササイズする (Topic × 10 分) ユーザーストー リーを描く 本スプリントで解 決する問題を決める 1 2 3 4
- 19. Day 1 ⽤用の tips • 問題に対する共通の理理解をすることが⼤大事 • 時間がないことをみんなに理理解してもらう：インタビューまですでに残り 4 ⽇日 • HEART Framework と Goals-‐Signals-‐Metrics process をうまく使う • Goals: そもそも達成したいこと (Youtube のビデオを⾒見見つけやすくする、等) • Signals: ゴールに対する少し低いレベルの数値 (Youtube のビデオ視聴時間、等) • Metrics: より詳細なレベル (A/B テストが⾏行行えるぐらい) の数値 (Youtube の⼀一⽇日のユー ザーあたりのビデオ視聴時間の平均、等) 19 Tips for Day 1 Definition Goals Signals Metrics Happiness ユーザーの態度度（満⾜足度度、使いやすさ、NPS） Engagement ユーザーの関与（頻度度、関わりの深さ：PV, DAU） Adoption 製品や機能に対する新規ユーザー（過去⼀一週間の登録ユーザー、新機能利利⽤用） Retention 既存ユーザーの動向（次に帰ってくる時間、チャーンレート） Task Success タスクの成功率率率（タスク達成の時間、成功率率率）
- 20. Diverge Day 2 20
- 21. Day 2 の成果物はストーリーボードとそれに対する投票（決定） Crazy 8s や、それを基にしたストーリーボードの作成、そして最終的な投票結果が Day 2 の 成果物となる。 http://www.gv.com/lib/the-‐product-‐design-‐sprint-‐divergeday2 21 Day 2 Outcome: Voted Storyboards
- 22. Day 2 の⽬目的 1. Day 1 で決めた問題を解決するための多くの可能性を明るみに出す 2. 短い期間で可能性を出すために、時間に明確な制限を設けて進めていく 22 Objectives of Day 2: Diverge
- 23. Day 2 のプロセス Day 2 のプロセスで重要なのは • 各⾃自が個別に静かに⾃自分のアイデアを書き出す (No Brainstorming!!) • 実は古いアイデア（以前思いついていたアイデア）が有効だったり する……古いアイデアから書き出そう！（新しく思いついたアイデア には往々にして過⼤大評価の傾向にある） • 紙を使おう。早く書こう。High fidelity なモックアップは不不要。神を 使えばみんなで貢献できるし、特定のアイデアに固執することもな くなる。できれば太いペンを使おう。 気を付けておきたいのは、 • Storyboard (Step 5) を書き出すまでは誰とも何もシェアしない それまで気にせず書こう！ 23 Day 2 Process 問題を分けて選ぶ ノートを取る (5 分) マインドマップ (10 -‐ 15 分) Crazy 8s (5 分) ストーリーボード (10 -‐ 20 分) Silent Critique (5 -‐ 10 分) 3 min Critique (3 分/idea) Super Vote (5 分) 1 2 3 4 5 6 7 8
- 24. ユーザーストーリーをチャンクに分けられる場合は分ける ユーザーストーリーダイアグラムが2つ以上のチャンクに分かれる場 合（多くの場合はそうなる）は、問題を分けてから取り組む。 2つ以上のチャンクに分かれた場合、それぞれの問題について Step 2 以降降のサイクルを回していく。ただしそれぞれの問題に別のチームを アサインするのは避けること。全体観がなくなる。 チャンクが多すぎる場合は、今回のスプリントで⾏行行う問題をさらに⼩小 さく選ぶこと。 24 2.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 分) 1 2 3 4 5 6 7 8
- 25. 各⾃自がアイデアをノートに書いていく ホワイトボードに書いてあるユーザーダイアグラムや、昨⽇日のディス カッションの結果の “How might we” (どうやったら解決できるか) ポス トイットを貼り出したり、あるいはノートを貼り出したりして、昨⽇日 の議論論を脳に叩き込む。 そのときそれぞれがノートや紙を持ち、有⽤用だと思ったものを書いて おく。 25 2.2 Take Notes 問題を分けて選ぶ ノートを取る (5 分) マインドマップ (10 -‐ 15 分) Crazy 8s (5 分) ストーリーボード (10 -‐ 20 分) Silent Critique (5 -‐ 10 分) 3 min Critique (3 分/idea) Super Vote (5 分) 1 2 3 4 5 6 7 8
- 26. アイデアを⽣生むためのマインドマップを作る 思いついたものをどんどん繋げていマインドマップを紙に書いていく。 マインドマップは今後の UI スケッチの cheat sheet となる。⾃自分しか ⾒見見ないので、絵でも⽂文字でもリストでもなんでもいい。 26 2.3 Mind Map 問題を分けて選ぶ ノートを取る (5 分) マインドマップ (10 -‐ 15 分) Crazy 8s (5 分) ストーリーボード (10 -‐ 20 分) Silent Critique (5 -‐ 10 分) 3 min Critique (3 分/idea) Super Vote (5 分) 1 2 3 4 5 6 7 8
- 27. 5 分で 8 つのデザインを描いていく A4 (A3) の紙を 8 つのパネルができるように折り、それぞれのパネルに 問題を解決できるようなデザインを、なんでもいいので書いていく。 5 分ですべてを完成させる、つまり 1 パネル 40 秒で書こう！（実際は 30 秒で書いて 10 秒休むぐらい） 詰まってしまった場合は、前のスケッチを少し変えてみたりして、深 堀りしてみてもよい。また古いアイデアでも OK。 Crazy 8s は慣れないうちは 2 度度⾏行行うとコツがつかめる。 このとき Bit Timer を使うと便便利利。 27 2.4 Crazy Eights 問題を分けて選ぶ ノートを取る (5 分) マインドマップ (10 -‐ 15 分) Crazy 8s (5 分) ストーリーボード (10 -‐ 20 分) Silent Critique (5 -‐ 10 分) 3 min Critique (3 分/idea) Super Vote (5 分) 1 2 3 4 5 6 7 8
- 28. 最も気に⼊入ったデザインのアイデアを最低 1 つ以上ポストイットに描く このステップではユーザーストーリーダイアグラムをより具体的にし ていく。 まず A4 の紙に 3 つのポストイットを貼る。それぞれのポストイット がストーリーボードの 1 フレームに対応すると考える。 28 2.5 Storyboard 問題を分けて選ぶ ノートを取る (5 分) マインドマップ (10 -‐ 15 分) Crazy 8s (5 分) ストーリーボード (10 -‐ 20 分) Silent Critique (5 -‐ 10 分) 3 min Critique (3 分/idea) Super Vote (5 分) 1 2 3 4 5 6 7 8 マインドマップと Crazy 8s の中からベ ストだと思う 1 つ以上を選び、その詳 細を書いていく。注意点は、 • それぞれを独⽴立立させる（⼝口頭の説明 がなくても意味が分かるように） • 匿匿名のままにする（⾃自分の名前を書 かない） • アイデアにタイトルを付ける（あと で議論論しやすくするため） 終わったら紙を壁に張り付けていく。 美術館の絵画のように横⼀一列列に。
- 29. 喋らずに、良良いと思ったアイデアにシールを貼っていく 全員が丸型のシールを持ち、壁に張り出されたアイデアのうち、良良い と思ったものにシールを張っていく。シールを貼る数に制限はないし、 ⾃自分のアイデアにシールを貼って⾏行行ってもいい。 ただしこのとき誰もしゃべらないようにすること。 この結果、アイデアに対するヒートマップが出来上がり、どのアイデ アに⼈人気が集まっているかが⼀一⽬目でわかる。 29 2.6 Silent Critique 問題を分けて選ぶ ノートを取る (5 分) マインドマップ (10 -‐ 15 分) Crazy 8s (5 分) ストーリーボード (10 -‐ 20 分) Silent Critique (5 -‐ 10 分) 3 min Critique (3 分/idea) Super Vote (5 分) 1 2 3 4 5 6 7 8
- 30. みんなが良良いと思ったアイデアの発案者は 3 分間でそのアイデアの詳細を話す権利利を得る 全員でどのアイデアが好きだったかを議論論し、⼈人気のあるアイデアを 書いた⼈人に 3 分間以内で説明してもらう。（全員が全員のアイデアを 話すのは時間がかかりすぎるので避ける） 必要であれば、写真でアイデアを撮って、それを PC に取り込んでプ ロジェクターに映しながら検討するのもいい（ただし時間は 15 分+) 30 2.7 Three-‐minute Critique 問題を分けて選ぶ ノートを取る (5 分) マインドマップ (10 -‐ 15 分) Crazy 8s (5 分) ストーリーボード (10 -‐ 20 分) Silent Critique (5 -‐ 10 分) 3 min Critique (3 分/idea) Super Vote (5 分) 1 2 3 4 5 6 7 8
- 31. 決定権者を中⼼心に、ベストなデザインを決定する 全員が “special” なシール（シールにマークを書いたりしたもの）を 1 or 2 つ持ち、ベストだと思うアイデアに super vote する。 もし CEO がすべての決定権を持つような⽂文化のチームであれば、CEO に 3 つのシールを渡してもいいし、CXO なら CXO に渡す。そこは正直 に、make the call できる⼈人に extra vote の権利利を作ろう。 エリート主義的ではあるが、コンセンサスはデザインを殺すし、決定 権者が納得していない案を進めるとあとで後悔する。 サイクルが終わったら、次にフォーカスすべきチャンクについて議論論 し、チャンクを決める。そして次のチャンクで同じサイクルを回す。 2 回⽬目以降降のサイクルはもっと簡単なので安⼼心しよう！ でも⼤大体 1 ⽇日 2, 3 回すると疲れ切切るので注意。 31 2.8 Super Vote 問題を分けて選ぶ ノートを取る (5 分) マインドマップ (10 -‐ 15 分) Crazy 8s (5 分) ストーリーボード (10 -‐ 20 分) Silent Critique (5 -‐ 10 分) 3 min Critique (3 分/idea) Super Vote (5 分) 1 2 3 4 5 6 7 8
- 32. Decide Day 3 32
- 33. Day 3 Outcomes: Whiteboard User Story http://www.gv.com/lib/the-‐product-‐design-‐sprint-‐decideday3 33
- 34. http://www.gv.com/lib/the-‐product-‐design-‐sprint-‐decideday3 34 Battle Royale
- 35. Day 3 の⽬目的 1. どの解決策のプロトタイプを作るのか、Best Shot もしくは Battle Royale するかを決める Point • 意思決定はつらいものだけれど、すべてのアイデアをプロトタイピングしたりテストで きないので絞る必要がある • スプリント中は、通常の会社の意思決定の仕組みよりもより “⺠民主的” になる傾向がある が、これは実際にプロダクトなので、会社の意思決定の仕組みを採⽤用する。たとえば CEO がやるといったらやる！という会社ならこのスプリントでもそうするし、ファシリ テーターはそのように促さなければならない（衆愚の罠にかからないように） • ファシリテーターは “Make the call” (最終決定してくれ) と決定権者に⾔言い続ける 35 Objectives of Day 3
- 36. Day 3 のプロセス 最初にするのはコンフリクトを探すこと。 コンフリクトを探すために、前⽇日のストーリーボードをじっくりと読 み込むところから始める。準備が整ったら次に進もう。 36 Day 3 Process 意⾒見見のコンフリク トを探す best shot か battle royaleかを決める 前提とテストの⽅方 法を決める 詳細なユーザース トーリーを描く 1 2 3 4
- 37. 皆の意⾒見見が分かれている場所、コンフリクトを探す 同じ問題に対する複数のアプローチが出ている場合、それを Conflict と呼ぶ。この Conflict が製品のための⾦金金脈となる。 Conflict はそれぞれポストイットに書き出すこと。たとえば、Landing Page のユーザーダイアグラムに、「ビデオ」「⼀一枚ぺら」「⼀一枚の製 品画像」という3案が出ている場合 Conflict が発⽣生している。 すべての Conflict をポストイットに書き出して、カテゴリに分けて壁 に貼っていく。 37 3.1 Search for Conflicts 意⾒見見のコンフリク トを探す best shot か battle royaleかを決める 前提とテストの⽅方 法を決める 詳細なユーザース トーリーを描く 1 2 3 4 通常デザイナーはアプローチを⼀一つ選 び、詳細なプロトにして持っていくが、 このようにすることで決定すべきポイ ントがマップされ、さまざまな可能性 が検討されるようになる。
- 38. コンフリクトを解消する (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 すべき。 38 3.2 Best Shot or Battle Royale? 意⾒見見のコンフリク トを探す best shot か battle royaleかを決める 前提とテストの⽅方 法を決める 詳細なユーザース トーリーを描く 1 2 3 4
- 39. 検証するべき前提 (assumption) と、それに対応するテストの⽅方法を決める ユーザースタディでテストしたいことを決めるには、前提や想定 (assumption) を明らかにすることが有効。 テストに対する前提にはたとえば、ユーザーの前提（e.g. 写真をアッ プロードしたいユーザーがいる）、ビジネスの前提（e.g. 市場規模）、 技術の前提、メッセージングの前提などがある。 これらの前提を確認するためにプロトタイプを使ってテストする。た とえば、ユーザーが製品を使って写真を快くシェアするかどうか、と いったようなものをプロトタイプを使ってもらってテストする。 39 3.3 Test Your Assumptions 意⾒見見のコンフリク トを探す best shot か battle royaleかを決める 前提とテストの⽅方 法を決める 詳細なユーザース トーリーを描く 1 2 3 4 技術の前提はエンジニアに試してもら えばいいが、そのほかの前提すべてを テストできそうにない場合は重要度度の 低いものは次に回す。 どのコンフリクトを探求すべきか、ど の前提のテストをするかを決めれば、 次はついにプロトタイピングの時間。
- 40. 詳細なユーザーストーリーをホワイトボードに描き、プロトタイピングのベースとする プロトタイピングする前に詳細なストーリーボードをホワイトボード に書いていく。ユーザーが実際に体験するものになるので、click by click で画⾯面を分ける。これがプロトタイプの spec になる。なおこのス トーリーボードはスプリント最後のグループワークである。 ホワイトボードに⼤大きなグリッドを描き、それぞれの⼤大きさは A4 の 紙 2 つ分ぐらい。 それぞれのセルには⼀一つのアクションを置く。クリックやテキスト⼊入 ⼒力力、ピンチなどなど。セルの画⾯面の詳細は気にしなくていいが、すべ てのアクションがストーリーに⼊入っていることが重要。 40 3.4 Whiteboard the User Story 意⾒見見のコンフリク トを探す best shot か battle royaleかを決める 前提とテストの⽅方 法を決める 詳細なユーザース トーリーを描く 1 2 3 4 書いている途中に、ユーザースタディ のことを考えながら書くといい。どう やって製品にたどり着くのか？等 ファシリテーターは⼀一⼈人が全部を書か ないように気を付ける。グループ全体 が参与するように気を付ける。
- 41. Day 3 の tips • 常に戦う準備をしておくこと (Keep the gloves off) • ストーリーボードを描くには、たくさんの⼩小さな決定をしなければならない。その ときに集団の同意を取るのではなく、CEO に “make the call” してもらう。 • どうしても決められないときは battle royale にする • ただし Battle royale を「決めることから逃げる」ことに使わない 41 Tips for Day 3
- 43. Day 4 の成果物は「ユーザーに⾒見見せることができて」「最⼤大限の学習効果が得られる」プロトタイプ ユーザーに触ってフィードバックをもらえるプロトタイプが Day 4 の成果物となる 43 Day 4 Outcomes: Prototype
- 44. Day 4 の⽬目的 1. Day 3 のストーリーボードを基に、ユーザースタディのための High Fidelity なプロトタ イプを作る Point • Crazy Deadline はすぐそこ：明⽇日にはユーザースタディが始まる • プロトタイプは Day 5 の Validate を通した「学習」のためにあることを忘れないこと（デ ザイン上の傑作はいらない） • 学習を⾏行行うに⼗十分なプロトタイプ作成のポイント • ⾒見見た⽬目が最低限リアルであること (Keynotopia などを使う) • リアルなテキストを書くこと（lorem ipsum ではないテキスト） • データの品質や Email のパーソナルコンテンツに関係する場合はコードを書く • でも⼗十中⼋八九 PowerPoint や Keynote で事⾜足りる • プロトタイピングサービスをうまく使おう 44 Objectives of Day 4
- 45. パワポと Keynote をプロトタイプに使いましょう PowerPoint や Keynote がメインのプロトタイピングツールとなる。これらなら: • デザイナーでなくてもデザインできる • アニメーションも簡単 • PDF にしてしまえばモバイルでも開ける • ユーザースタディのフィードバックも反映しやすい。 現実の製品に近づけるには、Keynotopia などの素材をうまく使う。 コードを書き出すと時間がかかるので、コードは極⼒力力書かないようにする 45 PowerPoint / Keynote: Prototyping Tool
- 46. Day 4 のプロセス プロトタイピングの時間は少ないので、Time Timer で管理理していく。 完璧なものを作るならデザイナー⼀一⼈人でやったほうがよいが、今回は ユーザーテストに Good Enough なプロトを作るのが⽬目的なので、この プロセスは役割分担しながら全員でやったほうが早い。 46 Day 4 Process 作業分担を決める Asset Library を作る （必要あれば） 各⾃自作業を⾏行行う Lightning Critique を 定期的に⾏行行う (5 分) Outsider Review を ⾏行行う (30 分) 細部をチェックす る 1 2 3 4 5 6
- 47. 役割を分けて担当を明確にする 極⼒力力多くの⼈人が PowerPoint や Keynote を持っているのがベスト。それ ぞれ画⾯面の担当を振り分けて、最終的なクリーンアップはデザイナー が⾏行行えばいい。 担当振り分けの際、昨⽇日のストーリーボードを⾒見見て、battle royale のと ころはチャンクを分けてアサインする。進みの速い⼈人を⼤大変なところ にアサインしていくなどの⼯工夫が必要。 ⼀一⼈人を「Stitcher」としてアサインすること。スライドを⼀一つにまとめ てフローにする。Battle royale の場合はそれぞれに stitcher を⽤用意。 そのほかメールチェックしている⼈人がいたら指摘する⼈人、時間管理理す る⼈人（1時間に1回休憩を⼊入れる⼈人）などが必要（ファシリテーターが 兼任する場合も）。 47 4.1 Divide and Conquer 作業分担を決める Asset Library を作る （必要あれば） 各⾃自作業を⾏行行う Lightning Critique を 定期的に⾏行行う (5 分) Outsider Review を ⾏行行う (30 分) 細部をチェックす る 1 2 3 4 5 6
- 48. ライブラリが必要なら作る 共通のビルディングブロックが発⽣生しそうなところは、アセットライ ブラリ化を検討する。テンプレートを作ったり、スクリーンショット や、ユーザーアバター、ロゴ、サンプルテキスト等々、必要だと思う ものはライブラリ化する。 ブラウザーバーなどもリアリズムのためには⼤大事なので、持っていな い場合は必ずつくること。 48 4.2 Build an Asset Library 作業分担を決める Asset Library を作る （必要あれば） 各⾃自作業を⾏行行う Lightning Critique を 定期的に⾏行行う (5 分) Outsider Review を ⾏行行う (30 分) 細部をチェックす る 1 2 3 4 5 6
- 49. 各⾃自作業！ 各⾃自担当した UI 作成の作業！ 1 時間に⼀一度度ぐらいは休憩を取りましょう。 49 4.3 Work 作業分担を決める Asset Library を作る （必要あれば） 各⾃自作業を⾏行行う Lightning Critique を 定期的に⾏行行う (5 分) Outsider Review を ⾏行行う (30 分) 細部をチェックす る 1 2 3 4 5 6
- 50. 簡単な批評を⾏行行う 途中で簡単な critique を⾏行行うのが有効。⼀一貫性を担保するためや、外 からデザインを⾒見見てもらってフィードバックをもらう。 しかし critique は時間を使う傾向にあるので、5 分に収めることを推奨 する。 他⼈人のデザインを⾒見見て他のデザインを進めたくなる場合、それは次回 のスプリントのためにとっておく。（Lightning critique は疑問を⽣生むの に良良い機会となるけれど、この画⾯面は今作っている⼈人が責任をもって 作っているものと⼼心得る） 50 4.4 Lightning Critique 作業分担を決める Asset Library を作る （必要あれば） 各⾃自作業を⾏行行う Lightning Critique を 定期的に⾏行行う (5 分) Outsider Review を ⾏行行う (30 分) 細部をチェックす る 1 2 3 4 5 6
- 51. 外の⼈人を読んで簡単なレビューを⾏行行ってもらう 30 分、今⽇日デザインに関わっていない⼈人にユーザーリサーチャーとし て来てもらう。もしくは PowerPoint などを持っていなかった⼈人でもい い。外からの⽬目は groupthink の罠から遠ざけてくれる。 できれば⼀一⽇日の早い段階で⾒見見てもらうこと。遅かったらもう出来上 がってしまっているので、できれば早いうちに⾒見見てもらう。 51 4.5 Review with an Outsider 作業分担を決める Asset Library を作る （必要あれば） 各⾃自作業を⾏行行う Lightning Critique を 定期的に⾏行行う (5 分) Outsider Review を ⾏行行う (30 分) 細部をチェックす る 1 2 3 4 5 6
- 52. ⼗十分な製品に⾒見見えるように細部に気を付ける マウスポインタやテキスト、ユーザーがどこをクリックするか、とか、 テキスト⼊入⼒力力後の画⾯面など、細かいところはできるだけ⼊入⼒力力するよう にする。そのほうがユーザースタディがよりリアルになる。 そのほか細部で気を付ける点として、 • ⼀一貫性やタイポには気を付けること。特にユーザーデータ（⼭山⽥田太 郎郎とかになっていないか）。 • コンテンツは最新で関連のあるものにしておくこと。たとえばシア トルでテストするなら、新聞は Seattle Times にすべき。 • スタックしたときには「何を学ぼうとしているか」を思い出すこと。 30分をボタンのスタイルなどで失ってはいけない。ユーザーに何の Value Prop を理理解してもらいたいかを考える。 「細部」の具体的な例例として Google Ventures で実際に作られた以下の プロトタイプが参考になる。 https://www.dropbox.com/sh/b5le4kch8m3eor8/aZ6qZcUBTk/Design%20Staf f%20Prototypes 52 4.6 Crucial Details 作業分担を決める Asset Library を作る （必要あれば） 各⾃自作業を⾏行行う Lightning Critique を 定期的に⾏行行う (5 分) Outsider Review を ⾏行行う (30 分) 細部をチェックす る 1 2 3 4 5 6
- 54. 54 Day 5 Outcome: Scoreboard
- 56. Day 5 の⽬目的 1. どのアイデアが受け⼊入れられ、どのアイデアが受け⼊入れられないのかを、ユーザーに プロトタイプを⾒見見せることによってテストを⾏行行い、テストを通して学ぶ Tips • インタビューはユーザビリティテストではない！ 「顧客が製品をどのように理理解した か」「競合製品や代替品として何を使っているか」などを学習するためのテスト 56 Objectives of Day 5
- 57. インタビューを効果的に⾏行行うためのリソース集 インタビューを⾏行行うコツを解説したリソースは多数あるので、外部リソースを参照のこと。 「半構造化インタビュー」で検索索すればある程度度 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) 57 New to Interview?
- 58. Day 5 のプロセス 始める前に何より、インタビューは学習するために⾏行行うということを 意識識すること。プロトタイプを改善していくための⽰示唆を得る。 インタビューする⼈人と観察する⼈人は分ける。ユーザーにとって不不快に ならないように、できれば⼤大勢の観察者は異異なる部屋で観察を⾏行行うこ と。 58 Day 5 Process キークエスチョン をリスト化する 観察ルームをセッ トアップする AV テストを⾏行行う 役割分担を決める インタビューを⾏行行 う (BR 案すべて) 振り返りミーティ ングを毎回⾏行行う 1 2 3 4 5 6 次のスプリントの 検討をする 7
- 59. キーとなる質問をリスト化して半構造化インタビューの準備を⾏行行う 全員でキーとなる質問をリスト化して、半構造化インタビューに備え る。そのための Tips として、 • Conflict と assumption についてもう⼀一度度確認すること。ユーザースタ ディでテスト可能な assumption であればリストに加える。 • Battle royale 状態のプロトタイプがあるかどうか。もしあるのであれ ばインタビュワーはその違いをきちんと理理解して正しい質問をする こと • 本物の競合製品などを⽐比較のために⾒見見せることを検討する • 今⽇日のユーザーテストはユーザビリティテストではないことに気を 付ける。ユーザーがきちんと製品を理理解できているか、どんな競合 製品や代替品を使っているかなどを⾒見見つけるためのテストである • 予想だにしなかったインサイトを⾒見見つけること フォーマットは独⾃自のものでも良良い 59 5.1 List Your Key Questions キークエスチョン をリスト化する 観察ルームをセッ トアップする AV テストを⾏行行う 役割分担を決める インタビューを⾏行行 う (BR 案すべて) 振り返りミーティ ングを毎回⾏行行う 1 2 3 4 5 6 次のスプリントの 検討をする 7
- 60. 観察ルームをセットアップする インタビュールームと観察ルームをできれば分けて⾏行行う。そのために、 観察ルームをセッティングする必要がある。 観察ルームからはビデオでインタビューセッションの内容が⾒見見れたり、 ノートをとれたりするような環境にすること。そのために、 • 部屋全体の雰囲気を撮影するための PC の カメラ + ⾳音声を拾拾って Skype や Hangout での共有 • ユーザー操作⽤用 PC での Skype を通した PC 操作画⾯面の共有 • Miracast / Airplay でのユーザー操作モバイルの画⾯面の共有 などをセットする。 60 5.2 Set Up the Observation Room キークエスチョン をリスト化する 観察ルームをセッ トアップする AV テストを⾏行行う 役割分担を決める インタビューを⾏行行 う (BR 案すべて) 振り返りミーティ ングを毎回⾏行行う 1 2 3 4 5 6 次のスプリントの 検討をする 7
- 61. AV テストを⾏行行う 利利⽤用するツールの AV テストは必ず事前に⾏行行う。特に、 • ⾳音質 • ビデオの位置 • 画⾯面共有の状況 については必ずチェックする。 ⾳音質が悪ければ conferencing microphone などを⽤用意する。また、観察 ルーム側のマイクは mute にしておく。 このテストはできるだけ毎セッションごとに⾏行行う。⼤大体デモには悪魔 が潜む。 61 5.3 Test the AV Ahead of Time キークエスチョン をリスト化する 観察ルームをセッ トアップする AV テストを⾏行行う 役割分担を決める インタビューを⾏行行 う (BR 案すべて) 振り返りミーティ ングを毎回⾏行行う 1 2 3 4 5 6 次のスプリントの 検討をする 7
- 62. 役割分担を決める インタビュワーと観察ルームの2つで⼤大きく役割分担を⾏行行う。 観察ルームの中でさらに役割分担を⾏行行う。 • 基本的に全員紙にノートを取る役⽬目を負う。良良いところも悪いとこ ろも予想外のことも、気づいたことはすべてノートにメモっておく （PC は閉じておくことが望ましい） • ⼀一⼈人のみ PC を開いて裁判報告官のようにすべての⾔言葉葉をリアルタ イムに筆記するようにする（疲れるので毎回変わると良良い）。これ はのちにリファレンスとして利利⽤用される。録⾳音に逃げないように。 62 5.4 Roles キークエスチョン をリスト化する 観察ルームをセッ トアップする AV テストを⾏行行う 役割分担を決める インタビューを⾏行行 う (BR 案すべて) 振り返りミーティ ングを毎回⾏行行う 1 2 3 4 5 6 次のスプリントの 検討をする 7
- 63. 効果的なインタビューを⾏行行う インタビューを⾏行行う。 63 5.5 Doing an Interview キークエスチョン をリスト化する 観察ルームをセッ トアップする AV テストを⾏行行う 役割分担を決める インタビューを⾏行行 う (BR 案すべて) 振り返りミーティ ングを毎回⾏行行う 1 2 3 4 5 6 次のスプリントの 検討をする 7
- 64. 1セッションが終わるごとにスコアボードに全員で記⼊入していく スコアボードを⽤用意して、皆のノートをまとめていく。列列ごとにイン タビュイーの枠を設け、⾏行行は各インタビューパート（バックグラウン ドや、プロトタイプ 1 / 2、etc）に充てる インタビューセッション⼀一つが終わるごとに、スコアボードに全員の 気づきを書いていく。そのとき、 • 緑⾊色：良良かった点 • ⾚赤⾊色：問題点、疑問点 • ⿊黒⾊色：その他 としておくと分かりやすい。 64 5.6 Make a Scoreboard キークエスチョン をリスト化する 観察ルームをセッ トアップする AV テストを⾏行行う 役割分担を決める インタビューを⾏行行 う (BR 案すべて) 振り返りミーティ ングを毎回⾏行行う 1 2 3 4 5 6 次のスプリントの 検討をする 7 書き終え次第、次のインタビュイーへ のインタビューを⾏行行う。
- 65. インタビューの傾向 インタビューを⾏行行うと、観察者側は⼤大体こういうパターンをたどる傾向にある。 • 1つ⽬目のセッション「俺たちは天才だ」「俺たちはバカだ」 • ⼈人はそれぞれ違うので気にしないこと。次のセッションに⾏行行こう • 2 〜～ 4 つ⽬目のセッション「これは複雑だ…」 • 5 〜～ 6 つ⽬目のセッション「パターンが⾒見見えてきた！」 • パターンが⾒見見えてきたらノートをダブルチェックするとさらに有効。スコアボード に 2, 3 度度出てきたことをチェックして、⼤大きな印をつけておく 「うまくいったこと」「解決すべき問題点」がインタビューを通して分かってきたら、次 にやるべきことを CEO や決定権者がリスト化しておく。 65 Observing Humans
- 66. 次のスプリントの計画を⽴立立てる インタビューがすべて終了了したら、スプリントを終わる前に次のスプ リントについて検討する。その時、ケースによって次のスプリントを ⾏行行うかどうかを決める。 A) ほとんどの物事がうまくいったケース 修正すべき点を⾒見見つけて、プロトタイプを修正し、Day 3 (Decide) からやり直すと 良良い B) いくつかの⼤大きな疑問が⽣生まれたケース 最も多いケースがこちら。いくつかは上⼿手くいったが、いくつかは微調整が必要、 いくつかはダメ、というケース。幸いなことにプロトタイプは修正しやすいので、 次のスプリントに⾏行行く。次のスプリントは Day 2 (Diverge) からやり直すと良良い C) 全部だめだったケース よくあるケース。ただ失敗ではない。何がダメだったか学べたのは前進であるし、 実際にモノを何か⽉月も使って作ってリリースしたときよりも短い時間で分かった のは良良いことだと思おう。次のスプリントは Day 1 (Understand) から始めると良良い。 その時に今回の結果を Day 1 の Exercise のときに使おう。 66 5.7 How to Start the Next Sprint キークエスチョン をリスト化する 観察ルームをセッ トアップする AV テストを⾏行行う 役割分担を決める インタビューを⾏行行 う (BR 案すべて) 振り返りミーティ ングを毎回⾏行行う 1 2 3 4 5 6 次のスプリントの 検討をする 7
- 67. Day 5 の tips • リサーチの前に • 必ず何を学びたいのかを明確にすること • ユーザーを dis らない • ユーザーが何かに困ったり⼿手が⽌止まったりしてもユーザーを⾮非難しない。デザイン をテストしているのであって、ユーザーが変な⾏行行動をとったのはデザインのせいで あり改善ポイントと考える • インタビューのこつ（代表的なもの） • メモのときには Why に集中する • ユーザーが考えていることを⼝口に出していってもらう (Think aloud) • ユーザーが⾔言ったことだけではなく⾏行行動も観察する 67 Tips for Day 5
- 68. See You Next Sprint!! 68
Editor's Notes
- #40: ここで各自書いてもらって、意見交換しながら一人の人が書くｇ