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

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

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

実施の際は
v2
もご確認ください。

http://www.slideshare.net/takaumada/design-‐sprint-‐guidebook-‐v2
3
Version
2
があります

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

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

デザインスプリントを実施して効果を上げたスタートアップの例例
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
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
以下のものをそろえる。

まず最初にインタビューするユーザーをリクルートしてから始める
次にやることはインタビューするユーザー 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

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

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

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

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

話すべきトピックを決める
トピックを決める。トピックには以下のような例例がある。トピックは
価値がないと判断すれば抜いても構わないし、追加しても構わない。
• 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
リーを描く

現状理理解を共通にするために各トピックで 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
1.3
Sketch
the
Most
Important
User
Story
Topic
を決める
(Topic
× 10
分)
リーを描く
1
2
3
4
• 新しい製品のコンセプトを作りたい
→ Value Prop とコアとなる機能を
決める
• Landing
Page
のコンバージョンを上
げたい → なぜ顧客が LP
にたど
り着くのか、彼らのゴールは何かを
理理解したい

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

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 タスクの成功率率率（タスク達成の時間、成功率率率）

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

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

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

ユーザーストーリーをチャンクに分けられる場合は分ける
ユーザーストーリーダイアグラムが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

各⾃自がアイデアをノートに書いていく
ホワイトボードに書いてあるユーザーダイアグラムや、昨⽇日のディス
カッションの結果の “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

アイデアを⽣生むためのマインドマップを作る
思いついたものをどんどん繋げていマインドマップを紙に書いていく。
マインドマップは今後の 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

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

最も気に⼊入ったデザインのアイデアを最低 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
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

みんなが良良いと思ったアイデアの発案者は 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

決定権者を中⼼心に、ベストなデザインを決定する
全員が “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

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

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

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

最初にするのはコンフリクトを探すこと。
コンフリクトを探すために、前⽇日のストーリーボードをじっくりと読
み込むところから始める。準備が整ったら次に進もう。
36
Day
3
Process
意⾒見見のコンフリク
トを探す
best
shot
か battle

royaleかを決める
前提とテストの⽅方
法を決める
詳細なユーザース
トーリーを描く
1
2
3
4

皆の意⾒見見が分かれている場所、コンフリクトを探す
同じ問題に対する複数のアプローチが出ている場合、それを Conflict

と呼ぶ。この Conflict
が製品のための⾦金金脈となる。
Conflict はそれぞれポストイットに書き出すこと。たとえば、Landing
Page のユーザーダイアグラムに、「ビデオ」「⼀一枚ぺら」「⼀一枚の製
品画像」という3案が出ている場合 Conflict
が発⽣生している。
すべての Conflict
をポストイットに書き出して、カテゴリに分けて壁
に貼っていく。
37
3.1
Search
for
Conflicts
トを探す
best
shot
か battle

法を決める
1
2
3
4
通常デザイナーはアプローチを⼀一つ選
び、詳細なプロトにして持っていくが、
このようにすることで決定すべきポイ
ントがマップされ、さまざまな可能性
が検討されるようになる。

コンフリクトを解消する (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

法を決める
1
2
3
4

検証するべき前提 (assumption)
と、それに対応するテストの⽅方法を決める
ユーザースタディでテストしたいことを決めるには、前提や想定
(assumption)
を明らかにすることが有効。
テストに対する前提にはたとえば、ユーザーの前提（e.g.
写真をアッ
プロードしたいユーザーがいる）、ビジネスの前提（e.g.
市場規模）、
技術の前提、メッセージングの前提などがある。
これらの前提を確認するためにプロトタイプを使ってテストする。た
とえば、ユーザーが製品を使って写真を快くシェアするかどうか、と
いったようなものをプロトタイプを使ってもらってテストする。
39
3.3
Test
Your
Assumptions
トを探す
best
shot
か battle

法を決める
1
2
3
4
技術の前提はエンジニアに試してもら
えばいいが、そのほかの前提すべてを
テストできそうにない場合は重要度度の
低いものは次に回す。
どのコンフリクトを探求すべきか、ど
の前提のテストをするかを決めれば、
次はついにプロトタイピングの時間。

詳細なユーザーストーリーをホワイトボードに描き、プロトタイピングのベースとする
プロトタイピングする前に詳細なストーリーボードをホワイトボード
に書いていく。ユーザーが実際に体験するものになるので、click
by

click
で画⾯面を分ける。これがプロトタイプの spec
になる。なおこのス
トーリーボードはスプリント最後のグループワークである。
ホワイトボードに⼤大きなグリッドを描き、それぞれの⼤大きさは A4
の
紙 2
つ分ぐらい。
それぞれのセルには⼀一つのアクションを置く。クリックやテキスト⼊入
⼒力力、ピンチなどなど。セルの画⾯面の詳細は気にしなくていいが、すべ
てのアクションがストーリーに⼊入っていることが重要。
40
3.4
Whiteboard
the
User
Story
トを探す
best
shot
か battle

法を決める
1
2
3
4
書いている途中に、ユーザースタディ
のことを考えながら書くといい。どう
やって製品にたどり着くのか？等
ファシリテーターは⼀一⼈人が全部を書か
ないように気を付ける。グループ全体
が参与するように気を付ける。

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

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

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

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

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

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

ライブラリが必要なら作る
共通のビルディングブロックが発⽣生しそうなところは、アセットライ
ブラリ化を検討する。テンプレートを作ったり、スクリーンショット
や、ユーザーアバター、ロゴ、サンプルテキスト等々、必要だと思う
ものはライブラリ化する。
ブラウザーバーなどもリアリズムのためには⼤大事なので、持っていな
い場合は必ずつくること。
48
4.2
Build
an
Asset
Library
Asset
Library
を作る
分)
Outsider Review を
⾏行行う (30
分)
る
1
2
3
4
5
6

各⾃自作業！
各⾃自担当した UI
作成の作業！
1
時間に⼀一度度ぐらいは休憩を取りましょう。
49
4.3
Work
Asset
Library
を作る
分)
Outsider Review を
⾏行行う (30
分)
る
1
2
3
4
5
6

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

外の⼈人を読んで簡単なレビューを⾏行行ってもらう
30
分、今⽇日デザインに関わっていない⼈人にユーザーリサーチャーとし
て来てもらう。もしくは PowerPoint
などを持っていなかった⼈人でもい
い。外からの⽬目は groupthink
の罠から遠ざけてくれる。
できれば⼀一⽇日の早い段階で⾒見見てもらうこと。遅かったらもう出来上
がってしまっているので、できれば早いうちに⾒見見てもらう。
51
4.5
Review
with
an
Outsider
Asset
Library
を作る
分)
Outsider Review を
⾏行行う (30
分)
る
1
2
3
4
5
6

⼗十分な製品に⾒見見えるように細部に気を付ける
マウスポインタやテキスト、ユーザーがどこをクリックするか、とか、
テキスト⼊入⼒力力後の画⾯面など、細かいところはできるだけ⼊入⼒力力するよう
にする。そのほうがユーザースタディがよりリアルになる。
そのほか細部で気を付ける点として、
• ⼀一貫性やタイポには気を付けること。特にユーザーデータ（⼭山⽥田太
郎郎とかになっていないか）。
• コンテンツは最新で関連のあるものにしておくこと。たとえばシア
トルでテストするなら、新聞は 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
を作る
分)
Outsider Review を
⾏行行う (30
分)
る
1
2
3
4
5
6

54
Day
5
Outcome:
Scoreboard

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

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

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

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

観察ルームをセットアップする
インタビュールームと観察ルームをできれば分けて⾏行行う。そのために、
観察ルームをセッティングする必要がある。
観察ルームからはビデオでインタビューセッションの内容が⾒見見れたり、
ノートをとれたりするような環境にすること。そのために、
• 部屋全体の雰囲気を撮影するための 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

AV テストを⾏行行う
利利⽤用するツールの AV
テストは必ず事前に⾏行行う。特に、
• ⾳音質
• ビデオの位置
• 画⾯面共有の状況
については必ずチェックする。
⾳音質が悪ければ conferencing
microphone
などを⽤用意する。また、観察
ルーム側のマイクは mute
にしておく。
このテストはできるだけ毎セッションごとに⾏行行う。⼤大体デモには悪魔
が潜む。
61
5.3
Test
the
AV
Ahead
of
Time
トアップする
AV
う (BR
案すべて)
1
2
3
4
5
6
検討をする
7

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

効果的なインタビューを⾏行行う
インタビューを⾏行行う。
63
5.5
Doing an Interview
トアップする
AV
う (BR
案すべて)
1
2
3
4
5
6
検討をする
7

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

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

次のスプリントの計画を⽴立立てる
インタビューがすべて終了了したら、スプリントを終わる前に次のスプ
リントについて検討する。その時、ケースによって次のスプリントを
⾏行行うかどうかを決める。
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

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

See
You
Next
Sprint!!
68

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

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

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

More from Takaaki Umada

More from Takaaki Umada (19)

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

Editor's Notes