Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

45分間で「ユーザー中心のものづくり」ができるまで詰め込む

•
•
Yoshiki Hayama
Yoshiki Hayama

2022年8月9日 ある企業さまでの研修「45分間で『ユーザー中心のものづくり』ができるまで詰め込む」のスライドです。登壇枠が45分という限られた時間のなかで、UXデザイン・UXリサーチのもっとも大切なエッセンスを凝縮してお伝えするようにしました。

1 of 110
Downloaded 879 times
45分間で 「ユーザー中⼼のものづくり」ができるまで詰め込む 2022年8⽉9⽇（⽕） ⽇本ウェブデザイン株式会社 / HCD-Net認定 ⼈間中⼼設計専⾨家 ⽻⼭ 祥樹 @storywriter 1 oViceの チャットで いっしょに 盛りあがってね
oViceの「チャット」で盛りあがろう︕ 2 オラオラオラオラオラ オラオラオラオラオラ オラオラオラ 練習 ・・・と投稿してみよう!!
⽻⼭ 祥樹 @storywriter 3 ⽇本ウェブデザイン株式会社 代表取締役CEO 使いやすいプロダクトをつくる専⾨家 HCD-Net認定 ⼈間中⼼設計専⾨家 Web業界に22年、AIシステムのプロダクトマネージャーとUXデザインを4年 主な実績など 2009年 ⽇経パソコン 企業サイトランキング2009 ⽇本の主要企業696サイト中、ユーザビリティ／アクセシビリティ分野で第3位 2011年 Webユーザビリティランキング2011 企業サイト編 ⽇本の⼤⼿企業150サイト中、第4位 主な専⾨分野 ユーザーエクスペリエンス、⼈間中⼼設計、情報アーキテクチャ、アクセシビリティ、ライター
4 このセッションのテーマ ユーザー中⼼のものづくり注1 “UXデザイン” や “UXリサーチ” 注1: UXデザイン、UXリサーチ、⼈間中⼼設計（HCD/UCD）、デザイン思考、サービスデザインなどいろんな呼び名がありますが、このセッショ ンの中ではすべて同じものだと考えてください。
5 UXデザインとは ユーザーエクスペリンス（UX）とは UXデザインのフレームワーク ユーザー調査 代表的な⼿法︓ ユーザーインタビュー、現場観察 ユーザビリティテスト 質的分析・モデリング 代表的な⼿法︓ KA法、カスタマージャーニーマップ ペルソナ、エンパシーマップ UXデザインとデザイン思考 プロトタイピング ビジネスモデル検証 代表的な⼿法︓ サービスブループリント、 ビジネスモデルキャンバス
ンとは エクスペリンス（UX）とは ンのフレームワーク ー調査 代表的な⼿法︓ ユーザーインタビュー、現場観察 ユーザビリティテスト 質的分析・モデリング 代表的な⼿法︓ KA法、カスタマージャーニーマップ ペルソナ、エンパシーマップ UXデザインとデ プロ ビジネスモデル検証 代表的な⼿法︓ サービスブループリン ビジネスモデルキャン !! 教 え ね ぇ ー よ
7 45 分 し か な い ん だ ぞ ！ そ ん な 悠 長 な こ と や っ て ら れ る か ！ 45 分 で Ｕ Ｘ デ ザ イ ン を で き る よ う に な ら な い と い け な い ん だ ぞ ！ ﹁ 40 秒 で 支 度 し な ﹂ じ ゃ な い だ け い い じ ゃ な い で す か
8 ま だ あ わ て る よ う な 時 間 じ ゃ な い
9 ユーザーを理解する専⾨技術を “UXデザイン” や “UXリサーチ” といいます。
10 本⽇は “UXデザイン・UXリサーチ” について 厳選に厳選を重ねたエッセンスを 45分に詰め込みます。
11 第1話 医者はどこだ︕
12 お腹が痛いんです ⼤腸がんだと思うんです ⼤腸がんの⼿術をしてください わかりました ⼤腸がんの⼿術ですね この医者をどう思いますか︖
13 ただの⾷あたり だったわ この医者をどう思いますか︖ あ、開腹してみたら ⼤腸がんじゃないわ この患者
14 では、この医者をどう思いますか︖ 当社は勤怠管理に 問題があると思うんです 勤怠管理システムを つくってください わかりました 勤怠管理システムですね
15 “医者” は誰でしょうか︖ お客様︖ それともあなたでしょうか︖
16 なんでそう思うの︖ あなたに何が必要かは 検査して “私” が判断するから 当社は勤怠管理に 問題があると思うんです 勤怠管理システムを つくってください
17 お客様に何が必要かはあなたが判断しましょう。 ただし、正しい診断をくだすためには お客様について、お客様より詳しくならないといけない。
18 お客様への ヒアリングはいつも ちゃんと⾏っている︕ そのヒアリング お客様に『ほしいもの』 を訊いてませんか︖ え︖
19 第2話 要件定義の根本的な課題
要件定義の根本的な課題 20 そもそもユーザーは、なにがほしいのか⾃分でわかっているのか︖
有名な実験 21 ⾷器メーカーです どんな新商品が欲しいか 議論してください
有名な実験 22 ガヤガヤ ワイワイ
有名な実験 23 ⿊くて四⾓いお⽫が スタイリッシュで 欲しいです
有名な実験 24 ありがとうございます お礼に好きなお⽫を お持ち帰りください
有名な実験 25 全員が ⽩くて丸いお⽫を 取った
有名な実験 26 いや・・・ 家にあるのは⽩ばかりだし 四⾓いと収納しづらいし ちょっと待って ⿊くて四⾓いのがいい って⾔ったじゃん
27 ユーザーは ⾃分が 「本当に」 ほしいものを そもそも⾃分でわかっていない
要件定義の根本的な課題 28 そもそも現場の担当者は、⾃分たちが本当に欲しいものを 正確に⾔葉にすることはできるのか︖
ある製造業の事例 29 QC活動として、 この帳票を転記して ミスを減らします
ある製造業の事例 30 なんでわざわざ 転記するのですか︖ 誤読による ミスを防ぐためです （エヘン）
ある製造業の事例 31 システムから印字される 帳票の⽂字が⼩さくて 誤読しやすい
ある製造業の事例 32 システムを改修して ⽂字を⼤きくすれば いいのでは・・・
ある製造業の事例 33 それは 思いつきませんでした
34 ユーザーは ⾃分が想像できる範囲でしか 改善策の発想ができない
要件定義の根本的な課題 35 情報システム室の担当者は、 現場のニーズを、正確に語ることはできるのか︖
現場の声があなたに届くまで 36 帳票が読みづらくて 困っている 現場のエンドユーザー 現場の上⻑ 情報システム室
現場の声があなたに届くまで 37 帳票の読みづらさは ⼤したことじゃない 問題は製造量のミスだ 現場のエンドユーザー 現場の上⻑ 情報システム室
現場の声があなたに届くまで 38 ⽣産管理システム がほしいです 現場のエンドユーザー 現場の上⻑ 情報システム室
39 現場からあなたに届くまでに ユーザーのニーズは歪んでしまう
40 つまりッツ︕ ユーザーは⾃分が 「本当に」 ほしいものを ⾔葉にできない しかもユーザーの声は オレたちのもとまで 正しく届かないッツ︕ それどころか ユーザーは⾃分が 「本当に」 ほしいものを 知らない︕
41 第3話 「もっと速い⾺がほしい」
42 註1: フォードはこの発⾔をしていない、という説もある。 もし私が顧客に何がほしいかを聞いていたら、 彼らは「もっと速い⾺がほしい」と答えただろう。 ヘンリー・フォード（註1） “ ” ユーザーに話を聞いていては ユーザーが本当にほしいモノは わからないってコト︕︖ じゃあなんで ユーザーの声を聞け っていうの︕︖
ユーザーの声を聞かない コンセプトにあう ユーザーの声だけ聞く ユーザーの声を聞いて 本当のニーズは 「A地点からB地点へ 速く移動したい」 のだと掘り下げて ⾃動⾞をつくる 「もっと速い⾺がほしい」と⾔われたらどうするか 43 「ユーザーに⾔われたままやること」と「ユーザーのニーズに応えること」は異なります。 「もっと速い⾺がほしい」と⾔われたとき、最初にすべきは「なぜですか︖」とユーザー に問いかけることです。
「ユーザーはほしいものを⾔語化できない」をかいくぐる 44 ユーザーは「⾺しか知らない」ので、訊いても「⾺」の話しか出てきません。本当の ニーズが「⾃動⾞」にあっても、⾔語化できないのです。会話から本当のニーズを⾒ つけるには、ほしいものを訊くのではなく、⾏動の⽬的を訊きます。 もっと速い⾺ がほしい ⾃動⾞ なぜ ですか︖ ⽬的地にもっと 早く着きたい 限られた時間で ⾏って帰りたい ここで納得しちゃダメ 時間をかけると 貨物が腐る 相⼿に早く 情報を伝えたい 冷蔵庫 電話 なぜ ですか︖
ユーザーニーズの理解レベル 45 レベル1 表⾯的な理解 レベル2 背景の理解 レベル3 真のニーズ理解 ユーザーの発⾔ プロダクトチーム の理解 プロダクトの改善 もっと速い⾺ がほしい ⽬的地にもっと早く 着きたいんだな 農作物が腐る前に 届けたいんだな もっと速い⾺が 欲しいんだな もっと速い⾺ もっと速い移動⼿段 防腐技術 もっと速い⾺ がほしい もっと速い⾺ がほしい
現場の “エンドユーザー” に話を聞いて、観察する 46 現場の “エンドユーザー” に話を聞いて、そして観察するようにしましょう。 現場に「なぜですか」とくりかえし⾏動の⽬的を訊くこと、 そして業務を観察することで、正しく病巣を特定できます。
“UXデザイン” や “UXリサーチ” の位置づけ 47 典型的なウォーターフォールシステム開発のフローを浮かべたとき “UXデザイン” や “UXリサーチ” は要件定義フェーズの「前」にやるのが、もっとも効果が発揮しやす い。外部設計フェーズでやるのは “UXデザイン” ではなく “UIデザイン” です。 要件定義 外部設計 内部設計 製造 テスト リリース “UXデザイン” や “UXリサーチ” ここでやるのは “UIデザイン”
48 第4話 UXデザインの第⼀歩
私 は Ｕ Ｘ デ ザ イ ン が 大 好 き だ 諸 君
な ら ば Ｕ Ｘ デ ザ イ ン だ よ ろ し い Ｕ Ｘ !! Ｕ Ｘ !! Ｕ Ｘ !!
ユーザー調査をする 51 ユーザー調査の代表的な⽅法は 「ユーザーインタビュー」 と 「ユーザビリティテスト」 です。 ユーザーインタビュー ユーザビリティテスト
ユーザーインタビュー 52 資格を取ろうと 思ったきっかけは︖ 会社で 勧められたから 査定が 良くなるから
ユーザーインタビューの会話の全⽂サンプル 53 インプレスさんのメディア Think IT の、⽻⼭の連載 「UXデザインはじめの⼀歩 ー インタビュー技術を磨こう︕」 にて、インタビュー発話録の全⽂サンプルを無料配布 しています。 https://thinkit.co.jp/series/9588
ユーザビリティテスト 54 プロダクトがすでに存在するときに有効です。いまのプロダクトをユーザーにさわっても らいながら、「タスク」をこなしてもらうことで、ユーザーの期待とプロダクトがマッチして いない箇所を⾒つけることができます。 タスク1をやってみてい ただけますか︖ はい・・・ええと・・・ 電源ボタンはどこだ︖
ユーザビリティテストの⾵景 55 マイクは インタビュー対象者と モデレーターの 両⽅の⾳声を 拾えるように（重要） ⼤⼈数で⾒る場合は プロジェクタや ⼤きめのディスプレイ を⽤意する ⾳声をしっかり 聞き取れる スピーカーを ⽤意する カメラの映像とマイクの⾳声を 傍聴する部屋に送る カメラ スピーカー プロジェクタ ⼜は ⼤きめの ディスプレイ パソコン インタビュー 対象者 モデレーター 傍聴者 調査を⾏う部屋 傍聴する部屋 操作画⾯をあとからも⾒返したいときは、 同時に、画⾯の録画もしてください。 マイク パソコン カメラは、以下がしっかり映 るように︓ 1. インタビューの場合、 ユーザーの表情が映 るように。 2. ユーザビリティテストの 場合、ユーザーの操 作画⾯。 スマホのテストのときは、 ⼿元が映せるように。 調査の会場は以下のとおり設営し、あらかじめ動作確認をします。
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
57 第5話 ⾃分の感覚を信じない
認知バイアスを体験してみよう 58 ふつうに会話するだけと思ったらおおまちがい。 ユーザーインタビューは認知バイアスとの戦いです。 とにかく「⾃分の感覚を信じない」ことが⼤切です。 まず体験してみましょう。
59 ご存知の⽅も多いでしょう。有名な錯視図です。 下のほうが⻑く⾒える、というやつですが。
60 じっさいに下のほうが⻑いです。
あなたはなぜ「同じ⻑さ」だと思ったのでしょうか︖ 61 ⼈間の脳には「認知バイアス」という働きがあります。 脳は⼤量の情報処理をしており、その負荷軽減をするためのしくみですが、 これはあなたの情報認識をかんたんに狂わせます。 たとえば、先ほどの図を⾒たとき 「知ってる、同じ⻑さなんだよね」という あなたの先⼊観（確証バイアス）が 測ればすぐわかることの判断を狂わせました。
あなたはずっと認知バイアスに襲われている 62 ユーザーインタビューをしているさなか、 あなたはずっと認知バイアスに襲われ続けています。 ユーザーの発⾔ひとつひとつの真意を取り違えさせます。 会社で 勧められたから 査定が 良くなるから
体験してみましょう 63 認知バイアスにはさまざまな種類がありますが ユーザーインタビューで直⾯しやすいのは「確証バイアス」です。 まず体験してみましょう。
今⽇は教材テーマに「資格取得」を使います 64 資格試験（英検、TOEIC、簿記、情報処理技術者試験・・・）は わりと多くの⼈が経験があるエピソードで、伝わりやすいので、 これをテーマに進めます。
問1. 書き出してみよう 65 資格試験（TOEIC、ITパスポートなど）を取ろう、と思う⼈の⼼理は、 どういうものがあるでしょうか。 思いつくままに書き出しましょう。（60秒）
どんな案が出ましたか︖ 66 どうでしょうか。 いろんな案がでたと思います。
問2. ユーザーインタビューの発話録を読んでみよう 67 じっさいに⽻⼭がユーザーインタビューをした結果の書き起こし（発話録）を 次のスライドに載せました。 これを読んで、あなたの仮説が当たっていたか判断してください。
ユーザーインタビューの発話録 68 「資格をとろうと思ったのは、会社で、査定にプラスになるから。たくさ ん持っていれば、昇格につながるし、履歴書にも書ける。受験料が 5100円もするし、参考書も3000円するけど、昇格のためならね。 ⽇曜⽇が⼀⽇つぶれて、疲れるけど、体系的な知識も⾝につくと思 うし。もともと新しいことを学ぶのは好きなんです。公的資格なら、社 内でも評価されるし、世の中でも評価されると思う。受験料も仕⽅ ないかなと思います」
あなたの仮説はあたっていましたか︖ 69 どうでしょうか。 あなたの仮説はあたっていましたか︖
あなたの仮説はあたっていましたか︖ 70 あなたは今「仮説あたった」と思っていますね︖
あなたの仮説はあたっていましたか︖ 71 じつは今、 この場にいる全員が「仮説あたった」と思っています。
⼈間は先⼊観に合う情報に意識がいってしまう 72 確証バイアスとは 「⼈間は先⼊観に合う情報に意識がいってしまう」 という認知のはたらきです。 あなたには、次の部分がとくに残っているはず。
確証バイアス︓「社内の評価のため」 73 「資格をとろうと思ったのは、会社で、査定にプラスになるから。たくさ ん持っていれば、昇格につながるし、履歴書にも書ける。受験料が 5100円もするし、参考書も3000円するけど、昇格のためならね。 ⽇曜⽇が⼀⽇つぶれて、疲れるけど、体系的な知識も⾝につくと思 うし。もともと新しいことを学ぶのは好きなんです。公的資格なら、社 内でも評価されるし、世の中でも評価されると思う。受験料も仕⽅ ないかなと思います」
あなたの仮説はあたっていましたか︖ 74 「社内の評価のため」と仮説をもっていた⼈は、こう感じているはずです。 仮説 あたった︕
「資格をとろうと思ったのは、会社で、査定にプラスになるから。たくさ ん持っていれば、昇格につながるし、履歴書にも書ける。受験料が 5100円もするし、参考書も3000円するけど、昇格のためならね。 ⽇曜⽇が⼀⽇つぶれて、疲れるけど、体系的な知識も⾝につくと思 うし。もともと新しいことを学ぶのは好きなんです。公的資格なら、社 内でも評価されるし、世の中でも評価されると思う。受験料も仕⽅ ないかなと思います」 確証バイアス︓「コスト（費⽤・時間）を⼼配」 75
あなたの仮説はあたっていましたか︖ 76 「コスト（費⽤・時間）を⼼配」と仮説をもっていた⼈は、こう感じているはずです。 仮説 あたった︕
「資格をとろうと思ったのは、会社で、査定にプラスになるから。たくさ ん持っていれば、昇格につながるし、履歴書にも書ける。受験料が 5100円もするし、参考書も3000円するけど、昇格のためならね。 ⽇曜⽇が⼀⽇つぶれて、疲れるけど、体系的な知識も⾝につくと思 うし。もともと新しいことを学ぶのは好きなんです。公的資格なら、社 内でも評価されるし、世の中でも評価されると思う。受験料も仕⽅ ないかなと思います」 確証バイアス︓「体系的な知識を学びたい」 77
「資格をとろうと思ったのは、会社で、査定にプラスになるから。たくさ ん持っていれば、昇格につながるし、履歴書にも書ける。受験料が 5100円もするし、参考書も3000円するけど、昇格のためならね。 ⽇曜⽇が⼀⽇つぶれて、疲れるけど、体系的な知識も⾝につくと思 うし。もともと新しいことを学ぶのは好きなんです。公的資格なら、社 内でも評価されるし、世の中でも評価されると思う。受験料も仕⽅ ないかなと思います」 確証バイアス︓「望む仕事に就きたい（就職・転職）」 78
「資格をとろうと思ったのは、会社で、査定にプラスになるから。たくさ ん持っていれば、昇格につながるし、履歴書にも書ける。受験料が 5100円もするし、参考書も3000円するけど、昇格のためならね。 ⽇曜⽇が⼀⽇つぶれて、疲れるけど、体系的な知識も⾝につくと思 うし。もともと新しいことを学ぶのは好きなんです。公的資格なら、社 内でも評価されるし、世の中でも評価されると思う。受験料も仕⽅ ないかなと思います」 確証バイアス︓「⼈⽣の教養を深めたい」 79
資格を取るきっかけとなるユーザー⼼理 80 ⽻⼭がユーザー調査をした結果によると、 資格を取るきっかけとなるユーザー⼼理は、⼤きくわけると5種類に収束します。
仮説をもったらサヨウナラ 81 先ほどのサマリーには、5種類の⼼理がすべて含まれていました。 そのため、どんな仮説をもって読んでも「仮説があたった」と思ってしまうのです。 脳にとって「仮説をもつ = 先⼊観をもつ」は同じなので、 仮説をもっていた時点で あなたはもう確証バイアスの餌⾷になるのです。
問3. すべての⼼理をもらさずにいられたか︖ 82 さて、こういう問いはどうでしょう。 「すべての⼼理をもらさずに思い浮かべられましたか︖」
仮説はかならずあたる（確証バイアスにより） 83 確証バイアスのため、仮説はかならず中途半端にあたります。 それゆえに、むしろ他の⼼理を⾒失います。 仮説 あたった︕ 他の⼼理は︖ 仮説 あたった︕
ユーザーは複数の⼼理のあいだを⾏き来している 84 ユーザーのニーズとは単独で存在しているものではなく、 複数の⼼理のかかわりのなかに存在するものです。 そのため、ひとつの⼼理だけ⾒てプロダクトをつくってもうまくいかない。
仮説はインタビューに⼊るときに捨て、出るときに拾う 85 確証バイアスを避けるためには、 「仮説はインタビュールームに⼊るときに捨て、出るときに拾う」 という姿勢が⼤切です。
とにかく判断せずにぜんぶメモしておく 86 確証バイアスを避けるためには、 ユーザーインタビューの途中では何が重要かという判断はせず、 出た話題は、とにかくメモするという姿勢で臨みます。 （何が重要かは、インタビュー後の分析で考える）
き み は イ ン タ ビ ュ ー 中 に 仮 説 を も っ た こ と は な い か ね そ う で す ね え …… ヤ ク ザ の チ ャ ン バ ラ で す な …… え ？ ム ガ ム チ ュ ウ で リ サ ー チ し ま す よ …… と て も そ ん な よ ゆ う な ん か 持 て な い ん で す よ
「我は正しかった」 = 後知恵バイアス 88 ほかにもユーザーインタビューで陥りやすい認知バイアスがいくつかあります。 たとえば「後知恵バイアス」です。 後知恵バイアスとは 「ものごとが起きたあとに、それは予測していたことだと錯覚する」 認知バイアスです。 俺の 予想どおり だった
「だいたい予想通りだった」と⾔う⼈に要注意 89 ユーザーインタビューが終わったあとの、最初のひとことが 「だいたい予想通りだった」 と⾔う⼈は要注意です。たいてい後知恵バイアスの餌⾷になっています。 私は 正しかった
「⾃分は頭が良い」と思っている⼈ほどやられる 90 ⽻⼭の経験だと、 • 「⾃分は頭が良い」と思っている⼈ • 偉い役職にある⼈（とくにおっさん） ほど、後知恵バイアスに喰われる傾向にあるようです。 「⾃分は頭が良い」というプライドが インタビュー中に浮かびあがった ⾃分は間違っているという数々の事実から⽬を背けさせ 「⾃分はすべてを予⾒できていた」と思わせるようです。
ユーザーインタビューは誘導（する誘惑）との戦い 91 認知バイアスはユーザーインタビューのなかで あなたがする質問の仕⽅にも影響を与えます。 それは無意識のうちに、ユーザーに「あなたが期待する答え」を⾔わせるように 誘導してしまうというかたちであらわれます。 （あなたに都合の よい答え）
ユーザーは無意識に「同調」する 92 ⼈間は⾃分に関⼼をもってくれている⼈の期待に応えようとする性質があります。 これを「ホーソン効果」と呼びます。 インタビューの場においてホーソン効果は、ユーザーは無意識のうちに 「あなたにとって都合のよい答え」を⾔おうとするバイアスとなってあらわれます。
ホーソン効果は前提を与えるほど加速する 93 Aという状況 におかれて はい Bという課題 があったら はい Cという製品 便利ですよね はい この訊きかたで「いいえ」と いう⼈はあまりいない。
その前提はあなたの認知バイアスかもしれない 94 えっ︕︖ Aという状況 先⽉に何回ありました︖
前提をおきまくる⼈はたいてい怯えている 95 ⽻⼭の経験だと、 • プロダクトをつくった本⼈ • 「⾃分の仮説は正しい」と思っている⼈ • 偉い役職にある⼈（とくにおっさん） ほど、前提をつけた質問（= 誘導しまくりの質問）をする傾向があるようです。 「⾃分がつくっているものが間違っているかもしれない」ことに 無意識に怯えている⼈ほど、説明や前提をおいてしまうようです。
ユーザーにひたすら説明をする⼈をやめさせる 96 ユーザーインタビューでプロダクトをユーザーに⾒せるとき そのプロダクトや機能がなんであるかをひたすら説明してしまう⼈がいます。 これも前提をおいているのと同じです。 このプロダクトは ・・・というもので この機能は ・・・のために使います
97 UXデザインの世界には という⾔葉があります。 すべてのプロダクトは「セルフサービス商品」である “ ”
すべてのプロダクトは「セルフサービス商品」である 98 ユーザーがじっさいに現場でプロダクトをさわるとき 操作に詳しい⼈がずっと横にいて、操作を教えてくれるなどということはありません。 むしろ、誰の助けもなく、ひとりで使うのがふつうです。 誰も助けてはくれない 詳しい⼈はそばにいない
プロダクトはノーヒントで使ってもらう 99 プロダクトをユーザーに⾒せるときは、できるかぎり説明をしてはいけません。 与えてよいのは、ユーザーが使うときに現実的に得られるレベルの情報のみです。 （そして、ユーザーは想像以上に情報をもっていません。ユーザーはウェブサイトの説明⽂を読まず、マニュアルを読まず、 アプリストアの説明⽂も読まず、あなたのプロダクトにふれるものです）
プロダクトの説明でなくタスクをわたす 100 プロダクトをユーザーに使ってもらうときは、 説明をするのではなく、タスクをわたして、そのあとは黙ってじっと⾒守りましょう。 タスクとは、たとえば次のようなものです。 • 「このアプリを使って、今晩の献⽴を考えてみてください」 • 「このサービスを使って、健康診断を予約してみてください」 • 「このサービスを使って、社員のうちメンタルケアが必要そうな⼈を洗い出してくだ さい」
ユーザーが操作に詰まってあなたに質問したとき 101 ユーザーが操作に詰まって、あなたに質問をしても 「あなたが思うように使ってみてください」としか答えてはいけません。 なぜなら、現実にユーザーがプロダクトを使うとき、あなたはとなりにいないからです。 あなたが思うように 使ってみてください どう使うのよコレ あなたが思うように 使ってみてください
さんざん 開発チーム みんなで 検討した 内容ですし ユーザーも ふつうに 使ってくれると 思いますが わざわざ ユーザビリティ テストをする 必要が あるので しょうか？ ユーザーの行動に 限って 常に 最悪のケースを 想定しろ ユーザーは必ず その少し 斜め上を 行く!! はいっ
≈ ふ ふ ふ ふ ふ ふ は っ は っ は っ は く っ く っ く ど ー だ ね ？ サ ド 隊 員 私 の 言 っ た 通 り だ ろ う ユ ー ザ ー は 常 に オ レ 達 の 想 像 の 斜 め 上 を い く
良いユーザーインタビュー・ユーザビリティテスト 104 ユーザーインタビュー・ユーザビリティテストにのぞむときは 仮説をもたない（いったん捨てる）ようにします。 こちらから、仮定や状況設定を押しつけない。 仮説をもたず、フラットにリサーチができると、 はじめてから3〜5回⽬までは、ユーザー⼼理の世界がどんどん広がっていきます。
105 まとめ
106 To Be Continued 君 が ッ Ｕ Ｘ デ ザ イ ン を 理 解 す る ま で 殴 る の を や め な い ッ
ユーザーを理解するには、ユーザーに会うこと 107 ユーザーを理解するもっとも基本的な⽅法は「ユーザーに会って、話を聞き、⾏動を 観察する」ことです。 まずユーザーに会いにいきましょう。
﹃ ユ ー ザ ー 調 査 は す る ﹄ ﹃ 開 発 も す る ﹄ ﹃ 両 方 ﹄ や ら な く ち ゃ あ な ら な い っ て の が ﹃ Ｓ Ｉ ｅ ｒ ﹄ の つ ら い と こ ろ だ な 覚 悟 は い い か ？ オ レ は で き て る
109 ありがとうございました ⽻⼭ 祥樹 （⽇本ウェブデザイン株式会社） Twitter: @storywriter
⽻⼭のプレゼンのアレ が、 LINEスタンプになりました︕ スタンプ名︓ハーミィ（CSS編） 作者名︓⽻⼭ 祥樹 https://store.line.me/stickershop/product/1228201/ja Web・CSSネタ 全40種類

More Related Content

45分間で「ユーザー中心のものづくり」ができるまで詰め込む