デザイン室でディレクターをしている田邊です。
先日、UXデザインとUXリサーチをテーマにした下記リンクのオンラインセミナーに参加してきました。
UXデザイン・UXリサーチ、とにかく現場のお悩み解決20連発！～現場で起きていることと、その乗り越え方～
現場の”あるある”を紹介するという趣旨に惹かれたことと、UXデザインやUXリサーチで培われた「チームで良いものを作る技術」が、私のディレクター業務にも活かせるのではないかと思ったことが参加の理由です。
実際は時間の都合上7つに凝縮して紹介されていましたが、非常に濃い内容でしたので共有します。
✅押さえたい2つの考え方
① 「言葉」ではなく「背景」に反応する
たとえば「調査なんていらない」と言われ、その言葉に反論してしまうと衝突するか、聞き流されて終わります。大事なのは「なぜこの人は今そう言わざるを得ないのか」という背景を読むことです。そして全体を通じて「相手は悪役ではなく、それぞれの立場でよかれと思って動いているという前提で考えましょう」と繰り返し語られました。
② UXの仕事は「組織を変える」こと
登壇者曰く、実際にものを形にするのはデザイナーやエンジニア、企画するのはビジネス側であるため、UXデザイナーだけでは不可能です。だから自分自身がユーザーを理解するだけではまだ半分で、その理解をチームに伝えて、人の行動を変えるところまでできて初めて意味があると言ってました。
✅現場のあるある7連発を紹介
あるある1：「ボタンを大きくして」を、そのまま作ってしまう
「このボタン、もっと大きい方がいい」と言われ対応した結果、画面の半分を占める使いにくいボタンが完成するというケースです。
問題は真面目にユーザーの声を受け止めすぎてしまい、発言の裏を検討しなかったことです。
本当は「隣に注意を奪う動画があった」「重要な機能なのに奥まった場所に置いていた」という真因があり、直すのは導線や情報設計かもしれません。
ユーザーの発言の裏を判断できるくらい、自分たちがユーザーに詳しくなることが必要、という話でした。
あるある2：「新しいものだから検証できない」＋ AI時代の落とし穴
「これはこれまでにないものだから、ユーザー調査なんてできない。とにかく作ろう」というパターンです。
でも、価値検証で必要なことはプロダクトを見せることではなく、ユーザーが達成したいゴールを掴むことです。
フォードの言葉として知られる「顧客に聞いたら”もっと速い馬が欲しい”と答えただろう」という話を例にとると、もっと速い馬が欲しいという真意は人によって違います。
- 速く往復したいだけなら自動車
- 生鮮品を腐らせたくなければ冷蔵庫
- 情報を速く届けたいなら電話
このように、ものが完成していなくてもゴールさえ掴めれば価値は判断できるんです。
さらにAIでプロトタイプが一瞬で作れるようになった結果、それっぽい試作を見せる調査が増えています。これ自体は良いのですが、ゴールを掴む前に具体物を見せるとユーザーの意識が引きずられて、本質的なニーズを取りこぼしたまま調査が終わる危険があります。
何を検証するフェーズなのかを意識するというのが大事です。
あるある3：ユーザーに会うことを、チームが無意識に恐れている
「ユーザー調査なんていらない、我々の仮説は正しい」という声が上がってしまうケースです。
背景には「自分の間違いに直面したくない」や「社内を説得するために立てたストーリーが崩れる」という思いがあります。
対処法は状況次第で2つです。
- 余力があって次のサイクルに進めるなら、チームの仮説を尊重しその通りに動かしてみて、早期に市場のフィードバックを得る運用にとどめます。
もし失敗しても、ユーザーを見なかったという反省が生きるからです。 - 次がない場合は力ずくで軌道修正します。
「私の意見」ではなくユーザーの様子を映した動画を根拠に「ユーザーの姿を見てください」という形にすると、誰かを否定せずに事実を示せます。
あるある4：作っているものが欲しいものと思えず、チームが疲れている
「これ、本当にユーザー欲しいのかな…」と思いながら毎日開発を続けて、チームのモチベーションが下がってしまうケースです。
厄介なのは、チームが違和感を持っていても「自分がそう思っているだけかも」と確証がないから作るしかなくなること。これはチームのユーザー理解の解像度が足りないときに起こります。
対処法は、チームメンバーをユーザー調査にリアルタイムで同席させること。さらに集めた声をチーム全員で、ある程度一緒に分析することです。そこまでいくと「これはユーザーの行動がこうだから使われない」と根拠を持って言えるようになります。
あるある5：ビジネス側・クライアントの要求がユーザーとずれているが、説得できない
人は構造的に身内の指摘は受け入れやすくても、外からの指摘は受け入れにくいことがあります。そのため相手自身が「間違ってるかも」と気づくよう誘導するのが大事だそうです。
おすすめは、自分で数人にユーザー調査をして、その様子を10〜15分の動画に編集し、会議で流すことです。「私の意見ではなく、ユーザーの姿です」という形にすると、否定にならず、相手が自分で気づけます（あるある3で触れた点と同様の考え方です）。しかも事前に関係者へ根回ししておくと大炎上を避けられます。これは明日から使えるテクニックだと思いました。
あるある6：数字で測れないものを、チームが考えたがらない
「主観的なものは参考にならないから、定量的に測れるものだけで話そう」と、定性的な調査を軽視するパターンです。
問題は、定性情報が客観的に扱える情報だと認識されていない点にあります。心理学（特に臨床心理学）でも定性的な情報を分析して再現性をもって次に活かしているので、十分価値のある情報です。
これも理屈でなく、一度一緒にユーザーを見てもらうのが効果的だそうです。優秀な人ほど、1〜2回同席するだけで「これは価値がある」と自分で納得してくれるとのことで、ここでも「実感」が鍵でした。
あるある7：デザイン/UXが、上流（要件定義）から呼ばれない
一番価値が出るのは要件定義から関わることなのに、その段階で声がかからないこともしばしば。背景には「デザイナー＝絵を描く人」というイメージがあり、上流に呼ばれにくい、という構造的な問題があります。
対処法は、正論で「上流から呼んで」と訴えるのではなく、小さな成功事例を積み上げる長期戦です。まずは下流の工程でいいので、ユーザーテストで得た気づきを反映して「関わると成果物が良くなる」実例を作ります。それを手に少しずつ上流へアプローチしていきます。これは今、国内の大手やメガベンチャーのデザインチームが共通して取り組んでいる課題でもある、と紹介されていました。
✅おわりに
全体を通して、「表面の言葉ではなく背景を読む」「理解して終わりではなく、人を動かすところまでが仕事」というメッセージが一貫していました。UXの話として聞きましたが、進行管理・折衝の技術としてもかなり実用的で、職種を問わず参考になる内容だったと思います。ぜひ参考になったら嬉しいです。
簡単30秒