More Related Content Similar to Design Sprint Process / デザインスプリントの実際のプロセスについて (20) More from Takaaki Umada (17) Design Sprint Process / デザインスプリントの実際のプロセスについて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
があります
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
以下のものをそろえる。
10. Day 0 ⽤用の tips
• インタビューのユーザー集めは⼈人づてになることが多いが(特に⽇日本はユーザーインタ
ビューに応じてくれる⼈人が少ない)、⼯工数を減らすために外部のサービスを使ったほう
が楽だしスクリーニングできる。外部のサービスには以下のようなものがある。
• Craigslist
• ゴチソー
• 事前にみんなで意識識を合わせておくべきことは以下
• 時間を守る。5
分と⾔言われたら 5
分で必ず収める。例例外は認められない。
• PC は 4
⽇日⽬目までほぼ使わない。必要がないときは閉じておく。メールもチェックし
ない。
• スケッチを恐れない
• 「絵⼼心がない」は禁句句。Day
3
までは伝われば何を描いてもいい
• スケッチであることを⽰示すために、太めのペンを使うことを推奨
10
Tips
for
Day
0
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
ユーザーストー
リーを描く
本スプリントで解
決する問題を決める
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 タスクの成功率率率(タスク達成の時間、成功率率率)
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
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
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
つ以上を選び、その詳
細を書いていく。注意点は、
• それぞれを独⽴立立させる(⼝口頭の説明
がなくても意味が分かるように)
• 匿匿名のままにする(⾃自分の名前を書
かない)
• アイデアにタイトルを付ける(あと
で議論論しやすくするため)
終わったら紙を壁に張り付けていく。
美術館の絵画のように横⼀一列列に。
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
33. Day
3
Outcomes:
Whiteboard
User
Story
http://www.gv.com/lib/the-‐product-‐design-‐sprint-‐decideday3 33
35. Day 3 の⽬目的
1. どの解決策のプロトタイプを作るのか、Best Shot もしくは Battle
Royale
するかを決める
Point
• 意思決定はつらいものだけれど、すべてのアイデアをプロトタイピングしたりテストで
きないので絞る必要がある
• スプリント中は、通常の会社の意思決定の仕組みよりもより “⺠民主的”
になる傾向がある
が、これは実際にプロダクトなので、会社の意思決定の仕組みを採⽤用する。たとえば
CEO がやるといったらやる!という会社ならこのスプリントでもそうするし、ファシリ
テーターはそのように促さなければならない(衆愚の罠にかからないように)
• ファシリテーターは “Make
the
call”
(最終決定してくれ)
と決定権者に⾔言い続ける
35
Objectives
of
Day
3
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
技術の前提はエンジニアに試してもら
えばいいが、そのほかの前提すべてを
テストできそうにない場合は重要度度の
低いものは次に回す。
どのコンフリクトを探求すべきか、ど
の前提のテストをするかを決めれば、
次はついにプロトタイピングの時間。
41. Day 3 の tips
• 常に戦う準備をしておくこと (Keep
the
gloves
off)
• ストーリーボードを描くには、たくさんの⼩小さな決定をしなければならない。その
ときに集団の同意を取るのではなく、CEO
に “make
the
call”
してもらう。
• どうしても決められないときは battle
royale にする
• ただし Battle royale を「決めることから逃げる」ことに使わない
41
Tips
for
Day
3
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
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
56. Day
5
の⽬目的
1. どのアイデアが受け⼊入れられ、どのアイデアが受け⼊入れられないのかを、ユーザーに
プロトタイプを⾒見見せることによってテストを⾏行行い、テストを通して学ぶ
Tips
• インタビューはユーザビリティテストではない! 「顧客が製品をどのように理理解した
か」「競合製品や代替品として何を使っているか」などを学習するためのテスト
56
Objectives
of
Day
5
59. キーとなる質問をリスト化して半構造化インタビューの準備を⾏行行う
全員でキーとなる質問をリスト化して、半構造化インタビューに備え
る。そのための Tips
として、
• Conflict と assumption
についてもう⼀一度度確認すること。ユーザースタ
ディでテスト可能な assumption
であればリストに加える。
• Battle royale 状態のプロトタイプがあるかどうか。もしあるのであれ
ばインタビュワーはその違いをきちんと理理解して正しい質問をする
こと
• 本物の競合製品などを⽐比較のために⾒見見せることを検討する
• 今⽇日のユーザーテストはユーザビリティテストではないことに気を
付ける。ユーザーがきちんと製品を理理解できているか、どんな競合
製品や代替品を使っているかなどを⾒見見つけるためのテストである
• 予想だにしなかったインサイトを⾒見見つけること
フォーマットは独⾃自のものでも良良い
59
5.1
List
Your
Key
Questions
キークエスチョン
をリスト化する
観察ルームをセッ
トアップする
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
67. Day 5 の tips
• リサーチの前に
• 必ず何を学びたいのかを明確にすること
• ユーザーを dis
らない
• ユーザーが何かに困ったり⼿手が⽌止まったりしてもユーザーを⾮非難しない。デザイン
をテストしているのであって、ユーザーが変な⾏行行動をとったのはデザインのせいで
あり改善ポイントと考える
• インタビューのこつ(代表的なもの)
• メモのときには Why に集中する
• ユーザーが考えていることを⼝口に出していってもらう (Think
aloud)
• ユーザーが⾔言ったことだけではなく⾏行行動も観察する
67
Tips
for
Day
5
Editor's Notes ここで各自書いてもらって、意見交換しながら一人の人が書くg