Skip to main content
UXデザイン・UXリサーチ
現場のお悩み解決20連発!?
〜現場で起きていること、その乗り越え⽅〜
1
CREATIVE VILLAGE SEMINAR 2026年 7⽉23⽇(⽊)
代表取締役CEO / HCD-Net認定 ⼈間中⼼設計専⾨家
⽻⼭ 祥樹 @storywriter
配信のチャットで
いっしょに
盛りあがってね
と に か く
UXデザイン・UXリサーチ
現場のお悩み解決20連発!?
〜現場で起きていること、その乗り越え⽅〜
2
CREATIVE VILLAGE SEMINAR 2026年 7⽉23⽇(⽊)
代表取締役CEO / HCD-Net認定 ⼈間中⼼設計専⾨家
⽻⼭ 祥樹 @storywriter
配信のチャットで
いっしょに
盛りあがってね
と に か く
9連発
書きはじめたら
ひとつひとつがとても深く
話しきれないので
分量を調整しました。。。
【訂正】
「チャット」で盛りあがろう︕
3
チャット
チャットへ
どんどん書いてね︕
(Twitter感覚で)
「全員」
で送信︕
Q&Aに
投稿したものは
質疑応答で
答えます
Q&A
「チャット」で盛りあがろう︕
4
さいしょに「チャットに投稿する練習」をしています︕
今回はどうしようかなと思いまして・・・
VTuber の “儒烏⾵亭らでん” が好きです。メンシも⼊ってる。
引⽤: https://youtu.be/hymOcFUkCHU?si=Ll75LRsyhynPqdo1 #らでん似絵
「全員」で送信
「チャット」で盛りあがろう︕
6
ぐるぐるぐるぐる
ぐるぐるぐるぐる
ぐるぐる
練習
・・・と投稿してみよう!!
「ぐる」の数は
⼼意気だよ︕
⽻⼭ 祥樹 @storywriter
7
⽇本ウェブデザイン株式会社 代表取締役CEO
使いやすいプロダクトをつくる専⾨家
HCD-Net認定 ⼈間中⼼設計専⾨家
Web業界に25年、AIシステムのプロダクトマネージャーとUXデザインを9年
主な実績など
2009年 ⽇経パソコン 企業サイトランキング2009
⽇本の主要企業696サイト中、ユーザビリティ/アクセシビリティ分野で第3位
2011年 Webユーザビリティランキング2011 企業サイト編
⽇本の⼤⼿企業150サイト中、第4位
主な専⾨分野
ユーザーエクスペリエンス、⼈間中⼼設計、情報アーキテクチャ、アクセシビリティ、ライター
8⽉27⽇(⽊)
UXデザイナー・UXリサーチャー
もうユーザー理解できるだけじゃ
役に⽴たない
〜求められる役割・スキルとキャリアの考え⽅〜
3回の連続セミナーです︕
8
UXデザイナー・UXリサーチャーになりたい⽅や初学者むけテーマの3回の連続セミ
ナーです。各回単体でも内容は理解できますが、3回とも参加いただくと、より理解
が深まるようになっています。
6⽉25⽇(⽊)
UXデザイナー・UXリサーチャー
そもそもどんな業務をしているの︖
〜仕事のリアルと全体像〜
1⽇⽬
3回とも参加で
より理解が深まる
7⽉23⽇(⽊)
UXデザイン・UXリサーチ
とにかく現場のお悩み解決
20連発︕
〜現場で起きていることと、その乗り越え⽅〜
2⽇⽬ 3⽇⽬
本スライドのあつかいについて
9
本スライドは全⽂公開します。
あとでお読みいただいてテキストとして使えるよう、かなり詳細に記載しています。
ただ、セッションは時間に限りがあるため、要点となるスライドのみを解説いたします。
取り上げなかったスライドは、ぜひ後ほどご⾃⾝でご覧ください。
スライドは
全⽂公開
このテキストの教材は「資格取得」 「推し活」を⽤います
10
わりと多くの⼈が経験があるエピソードで、伝わりやすいので、
このテキストの教材テーマに以下を⽤いています。
• 資格試験(英検、TOEIC、簿記、情報処理技術者試験・・・)
• 推し活(好きなものに熱狂していくプロセス)
備考: ⽤語の表記
11
• つど “UXデザイナー・UXリサーチャー” と書いていると読みづらいため、本資
料では “UXデザイナー” という表記に統⼀します。
• 本資料上は “UXリサーチャー” も “UXデザイナー” に含めます。
• 同様に “UXリサーチ” も “UXデザイン” に含めます。
12
UXデザイナー・UXリサーチャー
そもそも毎⽇どのような業務をしているの︖
13
UXデザイン・UXリサーチが広まり
その技法はネットや書籍で集めやすくなりました
14
しかし業界志望者にとって、そもそも
「UXデザイナー・UXリサーチャー職が
毎⽇どのような業務をしているのか」
がリアルに伝わってくる情報は
思いのほか少ないようです
そういえば、ぼくも
話してこなかった
15
ある会社員の1⽇・1週間
⽉ ⽕ ⽔ ⽊ ⾦ ⼟ ⽇
仕事 仕事 仕事 仕事 仕事
睡眠 睡眠 睡眠 睡眠 睡眠 睡眠 睡眠
趣味 趣味
よくあるやつ︕
やってみよう
16
あるUXデザイナー/経営者(46)の1⽇・1週間
⽉ ⽕ ⽔ ⽊ ⾦ ⼟ ⽇
仕事 仕事 仕事 仕事 仕事 仕事 仕事
かぁ〜っ︕
終
制作・著作
ご
存
知
で
し
た
?
経
営
者
は
労
働
基
準
法
に
守
ら
れ
な
い
20
業界歴25年のUXデザイナーである
講師の実体験にもとづいて
「UXデザイン・UXリサーチ現場のお悩みあるある」
紹介します
⽻⼭がずっと働いているのは
⽻⼭だからです
UXデザイナー関係ない
21
チームが無意識にユーザーに会うことを恐れている
⾃分が間違っていることを直視することを恐れている
UXデザイン・UXリサーチ現場のお悩み あるある 1
22
ユーザー調査︖
そんなもの必要ない
さあ
どんどんプロダクトを
つくろう
われわれの仮説は
正しい
正しくないと困る
UXデザイン・UXリサーチ現場のお悩み あるある
23
【あるある】
チームが無意識にユーザーに会うことを恐れている。
⾃分が間違っていることを直視することを恐れている。
【なぜ起きるのか︖ 解説】
理由はいろいろパターンがある。年配男性に多いのは 「⾃分が間違ってい
ることに直⾯したくない」、社内政治で 「そのストーリーが社内説得に必要」
「衝突したくない」、チームが 「ユーザー調査に慣れてなくて怖い」、など。
24
【重要】
彼らは 彼らの⽴場から⾒て
「良かれ」 と思ってやっている
けして悪意ではない
25
処⽅箋
一
体
い
つ
か
ら
ユ
ー
ザ
ー
を
理
解
で
き
て
い
る
と
錯
覚
し
て
い
た
?
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
スタートアップが失敗する理由トップ20、第1位は、、、
27
引⽤:
https://www.idaten.vc/post/%E3%82%B9%E3%82%BF%E3%83%BC%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E3%81%8
C%E5%A4%B1%E6%95%97%E3%81%99%E3%82%8B%E7%90%86%E7%94%B1%E3%83%88%E3%83%83%E3%83%9720
あなたが
思ってるニーズは
存在しなかった
42%
第1位
処⽅箋
28
UXデザイナー・UXリサーチャーから⾒ると、プロダクトをつくってから “ユー
ザーからすると使い物にならない” ことが判明するほうが被害が甚⼤。
問題を先送りして、傷⼝を広げている。対処は:
• そのままチームを失敗させて、その失敗をふまえて次のサイクルでユー
ザーを⾒させる。受託ならこの対処が第1選択。
• ⼒づくで軌道修正する。「失敗したら次がない」 ときの対処。⾃分が
POなど責任を負う⽴場で、かつチームを育成する余裕がないとき。
“組織の⼒学” に配慮する
29
“⼒づくで軌道修正する” 対処は多かれ少なかれ、誰かしらを否定すること
になるので、組織内のハレーションを⽣む。
多くのばあい、あなたがいくら正しさを主張しても、黙殺される。
あなたの意⾒を出すのではなく、⾃⾝でユーザー調査をして、ユーザーの声
(⽂字ではなく、できれば動画)を場に出す。
組織の⼒学に配慮して、えらい⼈と利害関係者には、あらかじめ根回しを
しておく。
30
ユーザーの表⾯的な発話と本質的なニーズの区別が
つかずチームが⾔われたままに開発する
UXデザイン・UXリサーチ現場のお悩み あるある 2
31
このボタンが
もっと⼤きいと
いいと思います
ボタンを
⼤きく︕
ユーザーがそう⾔った︕
ボタンを⼤きくするぞ︕
UXデザイン・UXリサーチ現場のお悩み あるある
32
【あるある】
ユーザーの表⾯的な発話と本質的なニーズの区別がつかず、チームが⾔わ
れたままに開発する。
【なぜ起きるのか︖ 解説】
“ユーザーで価値検証” と⾔われすぎて、「ユーザーが正解を知っている」 と
チームが勘違いしている。チームが “表⾯的な発話と本質的なニーズの区
別をつける” とは何をすることか、具体的に知らない。
33
【重要】
彼らは 彼らの⽴場から⾒て
「良かれ」 と思ってやっている
けして悪意ではない
34
処⽅箋
ほ
ん
と
だ
も
ん
ウ
ソ
じ
ゃ
な
い
も
ん
本
当
に
ユ
ー
ザ
ー
が
ほ
し
い
っ
て
言
っ
た
ん
だ
も
ん
!!
!!
処⽅箋
36
ユーザーは⾃分に⾒える範囲の意⾒しか⾔えない。表⾯的な発話と本質
的なニーズは、観察者(=チーム)が区別する。
たとえば 「ボタンが⼤きいほうがいい」 と⾔ったのはなぜか︖ 周囲に⽬を奪
うものがあって “相対的に” ⽬⽴たなかったのなら、ボタンを⼤きくするより、
周囲のジャマなものを消すほうがいいかもしれない。あるいは、ユーザーの
ゴールにつながるものがそのボタンしかなかったなら、そもそもユーザーニーズ
をチームがうまく把握できていないのかもしれない。
37
お腹が痛いんです
⼤腸がんだと思うんです
⼤腸がんの⼿術をしてください
わかりました
⼤腸がんの⼿術ですね
この医者をどう思いますか︖
38
ただの⾷あたり
だったわ
この医者をどう思いますか︖
あ、開腹してみたら
⼤腸がんじゃないわ
この患者
39
では、この医者をどう思いますか︖
ボタンに
気がつきませんでした
ボタンがもっと⼤きいと
いいと思うます
わかりました
ボタンを⼤きくですね
40
“医者” は誰でしょうか︖
ユーザー︖ それともあなたでしょうか︖
41
お腹が痛いのは
ほんとうにそれが理由なの︖
あなたに何が必要かは検査して
“私” が判断するから
お腹が痛いんです
⼤腸がんだと思うんです
⼤腸がんの⼿術をしてください
ボタンに気がつかないのは
ほんとうにそれが理由なの︖
あなたに何が必要かは調査して
“私” が判断するから
42
ボタンに
気がつきませんでした
ボタンがもっと⼤きいと
いいと思うます
43
いいから
射たれろ
注射いやー︕
注射こわいー︕
“医者” は患者が怖がっても注射しました
“医者” は患者の何に対してコミットしているから
注射したのでしょうか︖
オマエに
必要なのは
コレだ
44
患者本⼈ではないのに
“医者” はどうして患者本⼈より
正しい診断ができたのでしょうか︖
オマエに
必要なのは
コレだ
45
ユーザーに何が必要かはあなたが判断しましょう
ただし、正しい診断をくだすためには
ユーザーについてユーザーより詳しくならないといけない
46
まったく新しいものをつくっているのだから
ユーザー価値の検証はできないと思っている
UXデザイン・UXリサーチ現場のお悩み あるある 3
47
これまでにない
イノベーティブなものを
つくるんだ
どんどんプロダクトを
つくろう
これまでにないものだから
ユーザー調査など
できるわけがない
UXデザイン・UXリサーチ現場のお悩み あるある
48
【あるある】
まったく新しいものをつくっているのだから、ユーザー価値の検証はできないと
思っている。
【なぜ起きるのか︖ 解説】
そもそも “ユーザー価値の検証” は何をすることか、チームが具体的に理解
できていない。ユーザーにプロダクトを⾒せないと価値の検証ができないと
思っている。ディスカバーとデリバリーの区別がついていない。
49
【重要】
彼らは 彼らの⽴場から⾒て
「良かれ」 と思ってやっている
けして悪意ではない
50
処⽅箋
もうユーザー調査するしかなくなっちゃったよ
処⽅箋
52
“ユーザー価値の検証” は、ユーザーにプロダクトを⾒せることではない。
ユーザーがいるコンテキストのなかで、プロダクトが提供しようとしている
価値が “プロダクトが存在しないとき” に、どのように解決しようとしてい
るかを⾒つけること。とくに “うまく解決されるパターン” の再現性を特定
すること。
たとえば、⾃動⾞の発明前に 「⾺を急かせて、⽬的地と⽇々往復する」
⾏動をしているユーザーは、⾃動⾞というプロダクトのユーザーになりうる。
53
註: フォードはこの発⾔をしていない、という説もある。
もし私が顧客に何がほしいかを聞いていたら、
彼らは「もっと速い⾺がほしい」と答えただろう。
ヘンリー・フォード(註)
“
”
ユーザーに話を聞いていては
ユーザーが本当にほしいモノは
わからないってコト︕︖
じゃあなんで
ユーザーの声を聞け
っていうの︕︖
ユーザーの声を聞かない コンセプトにあう
ユーザーの声だけ聞く
ユーザーの声を聞いて
本当のニーズは
「A地点からB地点へ
速く移動したい」
のだと掘り下げて
⾃動⾞をつくる
「もっと速い⾺がほしい」と⾔われたらどうするか
54
「ユーザーに⾔われたままやること」と「ユーザーのニーズに応えること」は異なります。
「もっと速い⾺がほしい」と⾔われたとき、最初にすべきは「なぜですか︖」とユーザー
に問いかけることです。
「ユーザーはほしいものを⾔語化できない」をかいくぐる
55
ユーザーは「⾺しか知らない」ので、訊いても「⾺」の話しか出てきません。本当の
ニーズが「⾃動⾞」にあっても、⾔語化できないのです。会話から本当のニーズを⾒
つけるには、ほしいものを訊くのではなく、⾏動の⽬的を訊きます。
もっと速い⾺
がほしい
⾃動⾞
なぜ
ですか︖
⽬的地にもっと
早く着きたい
限られた時間で
⾏って帰りたい
ここで納得しちゃダメ
時間をかけると
貨物が腐る
相⼿に早く
情報を伝えたい
冷蔵庫
電話
なぜ
ですか︖
ユーザーニーズの理解レベル
56
レベル1
表⾯的な理解
レベル2
背景の理解
レベル3
真のニーズ理解
ユーザーの発⾔
プロダクトチーム
の理解
プロダクトの改善
もっと速い⾺
がほしい
⽬的地にもっと早く
着きたいんだな
農作物が腐る前に
届けたいんだな
もっと速い⾺が
欲しいんだな
もっと速い⾺ もっと速い移動⼿段 防腐技術
もっと速い⾺
がほしい
もっと速い⾺
がほしい
ダブルダイヤモンドと検証⽅法
57
第1ダイヤモンド(ディスカバー・ディファイン)フェーズは “ユーザーのコンテ
キストの特定” が⽬的。プロダクトを⾒せることは必須ではない。またユー
ザーにプロダクトを⾒せたとしても、あくまで会話の刺激物としてであり、プロ
ダクトの評価にはならない。
引⽤: https://www.designcouncil.org.uk/our-resources/the-double-diamond/
このフェーズの⽬的
“ユーザーのコンテキストの特定” には
プロダクトを⾒せることは
必須ではない
AIによるプロトタイプ濫⽤のデメリット
58
AIによりプロトタイプが量産しやすくなり、つい “プロトタイプをつくってはユー
ザーにすぐ⾒せる” ことをしがち。しかしプロトタイプ中⼼の調査はプロトタイ
プ周辺のニーズしかユーザーから発話されづらい。
引⽤: https://www.designcouncil.org.uk/our-resources/the-double-diamond/
第1ダイヤモンドのフェーズでプロト
タイプを誤⽤すると、かえってユー
ザーのコンテキストを⾒落としやす
くなる。
プロトタイプを⾒せるのは第2ダイヤモンド
59
プロトタイプをユーザーに⾒せて ”プロダクトが使われるか” の検証になるの
は第2ダイヤモンド(ディベロップ・デリバリー)フェーズ。第1ダイヤモンドで特
定したコンテキストに、プロダクトが意図どおりマッチするかを確認する。
引⽤: https://www.designcouncil.org.uk/our-resources/the-double-diamond/
第1ダイヤモンドでユーザーのコン
テキストを特定せずに、いきなり
第2ダイヤモンドからはじめると失
敗しやすい。
60
つくっているものが “ユーザーが欲しいもの” だと
思えなくてチームが病んでいる
UXデザイン・UXリサーチ現場のお悩み あるある 4
61
この機能
ほんとうにユーザーが
ほしいのかな
⼀⽣懸命
つくっているけど
とても使われるように
思えない
モチベ
しんどい
UXデザイン・UXリサーチ現場のお悩み あるある
62
【あるある】
つくっているものが “ユーザーが欲しいもの” だと思えなくて、チームが病んで
いる。
【なぜ起きるのか︖ 解説】
チームのユーザーへの解像度が低い。企画がそもそも的外れなのか、あるい
はチームが 「⾃分なら使わない」 と思っているだけなのか、いずれの判断も
できていない。企画に違和感があっても、そのままやるしかない。
63
【重要】
彼らは 彼らの⽴場から⾒て
「良かれ」 と思ってやっている
けして悪意ではない
64
処⽅箋
事件は会議室で起きてるんじゃない!
現場で起きてるんだ!
処⽅箋
66
チームがユーザーにリアリティをもてていないのが最⼤要因。ユーザーの “⼿
ざわり” をチームにもたらす。対処は:
• ユーザーインタビューやユーザビリティテストなど、直接にユーザーに会う調
査をして、その場にチームメンバーが同席する。
• “そこに⽣⾝のユーザーがいる実感” が⼤切。リアルタイムで同席する。
• 同席者はローテーションでもよいが、チーム全員が1回は同席すること。
• 分析(親和図法など)までチーム全員でできると効果⼤。
67
ビジネスサイド(やクライアント)から求められるものが
ユーザーとズレているがうまく説得できない
UXデザイン・UXリサーチ現場のお悩み あるある 4
68
えっ・・・
あの・・・
いい企画だろう︖
つくってくれ
はい・・・
この企画で
つくってくれ
UXデザイン・UXリサーチ現場のお悩み あるある
69
【あるある】
ビジネスサイド(やクライアント)から求められるものがユーザーとズレている
が、うまく説得できない。
【なぜ起きるのか︖ 解説】
ビジネスサイド(やクライアント)のユーザーへの解像度が低い。さらに説得
を受けつけない何らかの理由を抱えている。
70
【重要】
彼らは 彼らの⽴場から⾒て
「良かれ」 と思ってやっている
けして悪意ではない
71
処⽅箋
これは詳細を省くが
結論だけ言うと ユーザー調査しないと お前は死ぬ
処⽅箋
73
ビジネスサイド(やクライアント)がユーザーにリアリティをもてていない。ユー
ザーの “⼿ざわり” をもたらせばよいが、外部からの意⾒を受け⼊れづらい。
対処は:
• ビジネスサイド(やクライアント)が⾃⾝で 「⾃分はユーザーのことをわ
かっていない」 と気がつくようにする。
どうやって⽬を覚まさせるか︖
74
どうやって、ビジネスサイド(やクライアント)が⾃⾝で 「⾃分はユーザーのこ
とをわかっていない」 と⽬を覚まさせるか。
どうやって⽬を覚まさせるか︖
75
多くのばあい、ビジネスサイド(やクライアント)はユーザーをわかっていると
思っている。正⾯から否定しても関係が悪くなるだけ。
あなたは、彼らが⾃⾝で 「⾃分はユーザーをわかっていない」 と気づくように
誘導しなければならない。
あれひょっとして
俺まちがってる︖
ゴムのユーザー
76
無意識のうちにステークホルダーに都合のよいユーザー像に寄ってしまう。
これを 「ゴムのユーザー」 と呼びます。
ステークホルダーの妄想とご都合を詰め込んだ 「実在しないユーザー」 です。
77
それでは
「客観的な材料」とはなんでしょうか︖
78
「客観的な材料」とは
すなわち実在するユーザーの声そのものです
実在するユーザーの声をいかにして会議の場に届けるか
例: ユーザーインタビューをした動画を会議で流す
79
現場に訪問して、じっさいのユーザーに
ユーザーインタビューやユーザビリティテストをして
その動画を 「勉強会」 などの名⽬で
プロジェクトの主要な参加者の⽬前で上映します。
求めているのは
この機能そのもの
じゃなくて
この機能によって
○○○が判断できる
ことなんです
80
実在のユーザーの声ほど
お客様に強く響くものはありません
客観的な根拠として強いものもありません
81
チームが “数字で計測できないもの” について
考えたがらない
UXデザイン・UXリサーチ現場のお悩み あるある 6
82
定量的に
測れるもので
話をしてくれ
ユーザー調査︖
そんな主観的なもの
参考にならない
UXデザイン・UXリサーチ現場のお悩み あるある
83
【あるある】
チームが “数字で計測できないもの” について考えたがらない。
【なぜ起きるのか︖ 解説】
“数字で計測できないもの” について考えたがらない、というより、ユーザーイ
ンタビューのような “⼈間の主観” が混ざりそうな情報にもとづいて⾏動して
はいけない、と思っている。
84
【重要】
彼らは 彼らの⽴場から⾒て
「良かれ」 と思ってやっている
けして悪意ではない
85
処⽅箋
処⽅箋
87
“主観” が混ざりそうな情報にもとづいて⾏動してはいけない、という思考そ
のものは悪くない。対処として:
• ユーザーインタビューのような定性情報を “客観” 的にあつかう⼿法があ
ることを⽰す。(ただし、うまく価値観を変えられる成功率はやや低い)
• その⽅とユーザー調査をいっしょに取り組んで “そこに⽣⾝のユーザーが
いる実感” をしっかり味わってもらう。アタマではなく体感を得てもらう。
数字にしづらい要素こそ競争優位性
88
インターネット時代になり “プロダクト全体のユーザー体験” や “使いやす
さ” がそのままプロダクトの売上に直結するようになった。
GAFAMほか主要プレイヤーも使いやすいプロダクトをつくることで市場を占
有するようになっている。
89
プロジェクトマネージャーが
“⾮機能要件” はオマケだと思っている
UXデザイン・UXリサーチ現場のお悩み あるある 7
90
使いやすさ︖
ユーザー体験︖
そんな感覚的なものを
“要件” にされても
検収できない
なあなあで
着地させるべき
ものだよ
UXデザイン・UXリサーチ現場のお悩み あるある
91
【あるある】
プロジェクトマネージャーが “⾮機能要件” はオマケだと思っている。
【なぜ起きるのか︖ 解説】
がっつり⼤規模な業務システム開発のプロジェクトマネージャーをしてきた⽅
に⾒られる。“⾮機能要件” のなかでも、とくにクライアントの主観的判断に
左右されやすい項⽬は炎上の種になりやすいので、客観的に Yes/No が
判断できる項⽬にできるだけ議論を集中させようとしている。
92
【重要】
彼らは 彼らの⽴場から⾒て
「良かれ」 と思ってやっている
けして悪意ではない
93
処⽅箋
お
前
の
為
に
プ
ロ
ダ
ク
ト
が
あ
る
ん
じ
ゃ
ね
ぇ
ユ
ー
ザ
ー
の
為
に
プ
ロ
ダ
ク
ト
が
あ
る
ん
だ
!!
お
前
な
ぁ
ん
か
勘
ち
が
い
し
と
り
ゃ
せ
ん
か
?
処⽅箋
95
相⼿の⼼配は 「クライアントが主観で判断するため、いつまで取り組んでも
永遠に Yes と⾔ってもらえず、納期遅延や炎上につながる」 こと。かといっ
て “ユーザー体験” や “ユーザビリティ” を数値基準化にするのは、できなく
はないが⼤変。対処として:
• クライアントのRFP(提案依頼書)の段階で、”ユーザー調査の実施”
を検収要件に⼊れてもらっておく。数値⽬標ではなく ”ユーザー調査の
実施” とすることがポイント。
東京都 「テストしないものはリリースしない」
96
2021年より、東京都の公共調達では
「ユーザビリティテストを実施していないも
のはリリースしない」 というトップダウンの
⽅針が出されました。
プロジェクト内でユーザビリティテストをし
なければ、そもそも公共事業の⼊札に参
加できない。
引⽤: https://note.com/kouzoukaikaku/n/nad5524ea0504
UXを数値として計測する
97
”ユーザー体験” や “ユーザビリティ” を数値として計測する研究も存在す
る。ただビジネス実務では、わざわざ定量化するより、定性的な調査結果
をそのまま施策につなげてしまうほうが、コスパがいいことが多い。
98
ユーザビリティテストの結果が散々のとき
「あのユーザーはターゲットじゃなかった」 と⾔われる
UXデザイン・UXリサーチ現場のお悩み あるある 8
99
プロダクトを
ぜんぜん使えて
いないけれど
この結果は
気にしない
あのユーザーは
ターゲットじゃないね
UXデザイン・UXリサーチ現場のお悩み あるある
100
【あるある】
ユーザビリティテストの結果が散々のとき、「あのユーザーはターゲットじゃな
かった」 と⾔われる。
【なぜ起きるのか︖ 解説】
プロダクトをいざユーザーに触ってもらったら、まったく使ってもらえないとき、防
衛的に出る思考。被験者と “デモグラフィック属性の” ターゲットユーザー像
に差があるとき、調査結果すべてを棄却しようとする。