画面には載せられる情報量に限りがある。だから「何を目立たせるか」「何を省くか」を判断しなきゃいけない。この判断をするには、ユーザーが何に困っていて、何があれば解決するのかがわかっていないと、判断ができません。

基準がないまま作ると「なんとなくそれっぽい画面」はできる。けど「なぜこの情報をここに置いたの？」と聞かれたとき、答えられません。

ユーザー理解って聞くと「ユーザーが使いやすく」みたいな”操作性の話”に注目がいきすぎると思っているんですが、ユーザー理解は、UIの体験判断を下すための軸になります。これがないと、デザイナーとして意思決定ができません。

AIがある時代でも必要か

AIがUIを高速に生成できる時代になっても、これは変わりません。
AIに「いい感じのアプリ作って」と言っても、いい感じのものは出てこない。

「誰の・どんな課題を・どう解決するか」が曖昧だと、AIも曖昧なものしか出せずに、悪い意味で普通のものになります。

AIで実行速度が上がった分、ボトルネックは「何を作るか決める力」に移っているので。AI時代こそ、「ユーザー理解」をしてアイデアをユーザーの具体的な体験に向ける価値が上がっています。

デザイナー＝サービス・プロダクトをデザインする人

BONO的にはデザイナー職を目指してもいいのですが、従来の”UIなどをつくるがメインの人”ではなく、IT業界においては『サービス・プロダクトをつくる人』という意味でのデザイナーになった方が良いと考えています。

なぜかというとUIをつくるだけだと、元々やりたかったユーザー価値をデザインすることのごく一部に過ぎないのと、それがAIとデザインシステムで効率的に実現できるようになってきたからです。

逆にめんどくさいことは任せて、本質的な価値のデザインに使う時間と余白が増えています。

そのためこういうユーザー理解・調査もUXデザイナーとかそういう肩書きに閉じるつまらない考えはやめて”価値をデザインするために必要”なものは全部身につけて実行していきましょう💪

ユーザー理解で体験をデザインするためのスキル地図

じゃあ具体的に何を身につければいいのか。
UIの前に必要なスキルは、大きく3つのステップからなります。

『ユーザー理解から体験を棚卸してデザインするステップ』

• ステップ1. ユーザーのゴールを定義する : 具体的なゴール定義をすることで、何を深掘りすべきかが見えてくる。
• ステップ2. 課題を特定する : ユーザーの現状を理解して、ゴールと現実のギャップを明らかにする。そのギャップを生んでいる障壁（課題）を見つけて、障壁の原因を特定する。
• ステップ3. UI体験を設計する : 理想の体験フローを書いて、コア体験からUIを作り、フロー単位で検証する。

上から順にやって終わり、じゃない

この3ステップ、1回ずつやって完了ではないです。サイクルで何度も回すものです。

ゴールを仮で定義して、課題を掘って、UIを作ってみる。作ると「ここが定義できていない」が見える。見えたら戻って定義し直します。考えているだけじゃなく、1度具体化すると分かるものが増えていきます。

作ることは考えること。サイクルの回数がクオリティにつながります。
ここからこの3ステップを、実際のフィードバック事例を使って1つずつ見ていきます。

【ポイント】ユーザーヒアリングで具体化する💭

ゴールも課題も、自分の頭だけで考えても抽象的なまま終わります。AIを使ってもアイデアは出せますが本当にリアルなのか？は、入力するプロンプトで左右されてしまいます。

実際のユーザーに話を聞くことで、ゴールの具体像や現実の行動とその背景の情報が見えてきます。

数字でざっくりした傾向はつかめる。けど1人のユーザーをちゃんと把握することで、数字では見えない具体的な行動や心理が発見できる。これが体験設計の鍵になります。AIでも仮説は持てるけど、具体の確証はつかめません。

つまりヒアリングをはじめとしてUXリサーチは「やると良いこと」じゃなくて、ステップ1・2を実行してユーザー価値を形にするための手段になります。

事例：あるレシピ提案アプリの話

次のセクションで、ステップごとに具体的な説明をする際に、BONOのコミュニティで実際にあったフィードバック事例を使って進めていきます。

あるメンバーが、レシピ提案アプリを設計していました。ゴールは「ユーザーが自炊を無理なく続けられるようになる」こと。ユーザーインタビューも実施して、UIも作った。ビジュアルのクオリティもわるくない

けど、フィードバックで複数の根本的な問題を指摘された。
全部に共通していたのは、「UIの前のステップ」が抜けていたということ。

見た目はいい。でも、ユーザーの課題がちゃんと定義されていないまま画面を作っていた。だから「何を置くべきか」の根拠がなかった。

ここからは各ステップで何をしないといけないのかを説明しつつ、この事例も使って補足していきます🙋

🏃‍♀️ステップ1 — ゴールを具体的に定義する

まず最初にやるべきは、ユーザーのゴールを具体的に定義すること。
「具体的に」ってどのぐらいか。基準はシンプルです。

一人のユーザーがその状態を達成できるのがイメージできるぐらい、具体的に定義する。

なぜ具体的じゃないとダメなのかというと、抽象的だと、何をリサーチで得るべきか、何を体験に反映するべきか、また課題とその原因がなんなのか？を具体的に考えることが困難になるからです。

事例で見てみよう

この事例ではゴールが「自炊を無理なく続けられる」だった。

一見ゴールに見える。けど具体化しようとするとこうなる。
「無理なく続けられる」って、具体的に何が起きている状態？

• 毎日？ 週3回？ どのぐらいの頻度で「続いている」と言えるのか？
• 「無理なく」って何？ 時間がかからないこと？ 考えなくていいこと？
• そもそもこの人にとって「続けられている」ってどういう実感？

こうやって具体化しようとすると、わかっていないことがどんどん出てくる。

これがめちゃくちゃ大事です。
これが”良い体験”の条件に繋がるし、”課題の原因”の把握につながります。つまり解像度高く体験をデザインできる情報が手に入るわけです。

逆にゴールが抽象的なままだと「何を調べればいいか」すらわからず、いきなり手段（UIの機能）に飛んでしまいます。

ヒアリングでゴールを具体化する

ゴールの具体像は自分の想像だけでは作れません。ユーザーに聞いて初めてわかるものです。

この事例では「自炊を無理なく続ける」がゴールだったけど、ユーザーにとって「無理なく」が何を指すのかはヒアリングしないとわからない。

聞くべきことは例えばこういうこと。

• 「理想の状態って具体的にどういう感じですか？」
• 「そのとき何をしていますか？」
• 「何が見えていて、何を感じていますか？」

聞いた内容をもとにゴールを具体的に書き直します。まだ曖昧なら追加で聞きましょう。

🏃‍♀️ステップ2 — 課題を特定する

ゴールを定義したら、次はユーザーの課題とそれを引き起こしている原因を特定します。
ちなみに課題定義が様々な方向性を決めるので、UIで体験をデザインする上で最も明確にしたい情報です。

このセクションでは以下の3つを扱います。

1. 課題とは何か — ゴールと現実のギャップ構造
2. ブレイクダウンで課題の原因を見つける — 抽象→具体に分解する
3. 課題を特定できた状態とは — UIで何をすべきかが導けるかどうか

□ 1:課題とは何か — ゴールと現実のギャップ構造

ユーザーには「なりたい状態」（ゴール）がある。そして「今の状態」（現実）がある。この2つの間にギャップがあります。

ゴール達成を邪魔しているもの、それが課題。
その課題がなぜ存在するのか、何が邪魔しているのか、それが課題の原因。

課題の原因を特定することで解決策につながります。

この構造がわかっていないと、「起こっている事実」をそのまま課題と呼んじゃうのが、めちゃくちゃよくあるパターンです。

ヒアリングでギャップを埋める情報を集める

課題と原因を特定するためにまず、ゴールに向けて、今どういう行動をしていて、何が起きているかをヒアリングで聞きます。
ゴール状態になりたいのに、それができない”障壁のギャップ"が見えたら「なぜそうなっているのか」を掘って具体的に把握していきます。ここがヒアリングの核心です。

聞き方で大事なポイントがあるとすれば、「うまくいかなかった話」だけじゃなくて、「うまくいった話」も聞くこと。うまくいったときと、いかなかったときの差に、障壁のヒントがあることがあります。

また初歩的ですが闇雲にインタビューをするのは失敗確率が高いです。
例えば、課題を見つけるフェーズならどういう話を深掘りをすると聞ける確率が増えるか？を考えてヒアリングの準備をすることもとても大切です。

□ 2 : ブレイクダウンで課題の原因を見つける

ヒアリングで”事実＝ゴールに対して行なっていること”がわかり、課題になりそうなポイントが見つかったらその部分を深掘りしていきましょう。

ブレイクダウンして”理由・なぜ・何がそうさせているか”を深く掘ると原因に辿り着きやすいです。

やることは大きく3つです。

① 事実と原因を区別する

ヒアリングで出てきた情報をそのまま「課題」と呼んでしまうのはよくあるパターンです。まず事実と原因を区別する必要があります。

例えばヒアリングで「家に食材がない」「レパートリーが1種類しかない」「疲れていて準備できない」という話が出てきたとします。

「家に食材がない」「レパートリーが少ない」は起こっている事実であって、課題（原因）じゃない。「疲れている」「めんどくさい」も表層的すぎて、ここからUIで何を作るべきかは判断できません。

事実を集めたら、次に**「なぜそうなっているのか」を掘る**必要があります。

② ゴールから条件をブレイクダウンする

ゴールから「それを達成するには何が必要か」を段階的に分解していきます。

具体的にいけばいくほど対象は狭くなる。けどそれでいい。
まずは一人を深く認識して、救えることが大事です。広げるのは後で簡単にできます。

大事なのはレイヤー5まで降りること。抽象的な層で止まって手段に飛ぶと、何を作ればいいかの根拠がないままUIを作ることになります。

③ 「UIで何をすべきか」が導けるまで原因を掘る

ブレイクダウンでレイヤー5まで降りたら、「なぜそれができていないのか」をさらに具体的にしていく必要があります。

ここで止まりがちなのが「疲れているから」「めんどくさいから」のような表層的な原因。これだとUIで何を作るべきか判断できません。

原因の掘り方は状況によって変わりますが、共通して大事なのは**「なぜ？」で止まらず、具体的に何が・どう邪魔しているのかまで言語化する**ことです。

• 「なぜできないのか」→ 表層的な答え（疲れている、めんどくさい）
• 「じゃあ同じ条件でもできていることはないか？ その差は何か？」→ もう一段具体的な答え
• 「具体的に何が足りなくて、何があれば動けるのか？」→ UIの方向が見える答え

この事例では、ユーザーは疲れていても米を研いで炊飯していた。つまり「疲れている」は本当の原因じゃない。この人が動けるのは「食べたいものが明確」「手順を知っている」「簡単だとわかっている」の3つが揃っているときです。

それならそれをユーザーが得られる体験を提供できれば解決できる確率が上がるかもしれません💡

具体的には、自分の制約条件（簡単・少食材・火なし）と好み（食べたいと思えるか）の両方を満たすメニューが何なのか把握できていない。米は偶然知っていただけで、同じ条件を満たす他のメニューを発見する手段がない。だからレパートリーが増えず、飽きたら自炊が止まります。

ここまで原因が具体的になると、UIの方向も決まります。「条件 × 好み」の掛け合わせで「これなら作りたい」と思えるメニューに出会わせる体験を作ればいいわけです。

□ 3 : 課題を特定できた状態とは

課題の原因をどこまで掘ればいいのか。

その原因から、「このユーザーの具体的な障壁を取り除くUIの体験」が導けるかどうか。 これが判定基準です。

注意してほしいのは、浅い原因からでも浅い解決策は導けてしまうこと。例えば：

• ❌「疲れているから準備できない」→「じゃあ簡単にしよう」— これは導けているように見えるけど、このユーザー固有の障壁が何も特定されていない。「簡単にする」は誰にでも言える。何をどう簡単にすればこの人が動くのかがわかりません
• ❌「作りたいものを見つける手段がない」→「じゃあレシピを出そう」— まだ抽象的。どういうレシピを、どういう条件で出せばこの人に刺さるのかがわかりません
• ✅「制約条件（簡単・少食材・火なし）と好み（食べたいと思えるか）の両方を満たすメニューを把握できていない」→「条件 × 好みの掛け合わせでマッチするメニューに出会わせる」— この人の具体的な障壁に対して、具体的な体験が導ける

ポイントは、「誰にでも言える解決策」ではなく「このユーザーの具体的な障壁を取り除く体験」が見えるかどうか。見えないなら、まだ掘りが足りません。

課題の原因が特定できると、ここから先のUI体験設計の判断軸が手に入ります。どの画面に何を置くか、どの情報を優先するか、どんなフローにするか — 全部この原因を「解決できるかどうか」で判断できるようになる。逆に言うと、ここが曖昧なまま次に進むと、UIの判断が全部「なんとなく」になってしまいます。

🏃‍♀️ステップ3 — UI体験を設計する

ゴールを定義して、課題の原因を特定できたら解決策を考えましょう。
いよいよUI体験の設計に入ります。

ここで大事なのは、1画面ではなく解決のフローでUI体験をプロトタイピングすることです。

1画面ではなくフローで考える

UIを作るとき、つい「この画面をどうするか」から考えがちです。けどユーザーの課題は1画面で解決するものではありません。ユーザーがゴールに到達するまでには複数のステップがあります。

そのステップの流れごとに体験設計するのがUIデザインでは大切です。

やることは2つ。

① 課題の原因を解決するフローを設計する

ステップ2で特定した課題の原因を解決するために、ユーザーがどういう順番で何を体験すれば、ゴールに到達できるかを考えます。

各ステップは「ゴールに向かって障壁を1つずつ取り除いていくもの」。フロー全体を通じて、ユーザーが現実からゴールに近づいていく流れを作ります。

② コア体験から固める

フローの中にはユーザーにとって一番価値がある体験（コア）があります。通知画面や設定画面から作り始めるんじゃなくて、コアから先に固める。

通知が来ても、コアがダメなら使わない。周辺はコアが固まった後で詰めていきましょう。

ポイント💡：体験フローの質は課題特定の質で決まる

体験フローには質の差があります。

課題の原因が曖昧なまま書いたフローは「ユーザーがなんとなくハッピーになる」ぐらいの解像度にしかなりません。課題の原因が具体的に特定できていると、「この障壁がこのステップで取り除かれるから、ユーザーはゴールに近づける」と説明できるフローになります。

つまりステップ2の課題特定が甘いと、ここで良い体験フローは書けない。全部つながっています。

体験フローの具体的な書き方・進め方は「シナリオベースドデザイン」のコンテンツで詳しく解説しています → （リンク）

サイクルを回す — 1発で正解は出ない

ここまで読むと「この流れでやれば良いのか」というイメージが湧いてくるかもしれません。
ただ気をつけないといけないのは、この3ステップは1回やって終わりの直線ではないことです。

できるだけ早く最初はステップの全てまで行って「考え↔︎具体」を行き来できるようにすることで、全体の解像度が上がります。
つまりステップですが、サイクルで行ったり来たりしながら全体の解像度を上げていくことが大切です。

プロトタイプを作ると何が見えるか

考えを形にしてみるプロトタイプを作成すると、具体的に自分で体験ができるので様々なことに気づきやすいです。

• いざプロトタイプを作ってみると、”この画面・情報は必要なんだっけ？”に迷いが起こり、定義がまだ曖昧な可能性が見えてくる。
• プロトタイプを見ると、1画面を作り込んでしまい「解決につながるフロー全体が設計が弱い」ことが気づけた
• 整理した「課題の原因」にアプローチしてない無駄な情報や画面があることに気づいてしまう。

これは全部「作ったからこそ見えた問題」です。
頭の中で考えているだけでは気づけなかった。

プロトタイプは完成品じゃない。定義の甘さを可視化して質を高めるプロセスです。
見えた問題を持ってステップ1・2に戻り体験をどんどん詰めていけます。

まとめ

全体像をまとめるとこうなります。

ユーザー理解からの体験設計をサイクルを回せるようになれば、「見た目がいい」だけじゃなくて「ユーザー価値に届くUI」が作れるようになります。

BONOのUXコースで実践しよう

この記事で示した地図を、実際のプロジェクトで歩いてみる場所がBONOのUXコースです。
ゴール定義、課題特定、UI体験設計。このサイクルを実際のお題で回す練習を、フィードバックをもらいながら進めることもできます。

画面には載せられる情報量に限りがある。だから「何を目立たせるか」「何を省くか」を判断しなきゃいけない。この判断をするには、ユーザーが何に困っていて、何があれば解決するのかがわかっていないと、判断ができません。

基準がないまま作ると「なんとなくそれっぽい画面」はできる。けど「なぜこの情報をここに置いたの？」と聞かれたとき、答えられません。

ユーザー理解って聞くと「ユーザーが使いやすく」みたいな”操作性の話”に注目がいきすぎると思っているんですが、ユーザー理解は、UIの体験判断を下すための軸になります。これがないと、デザイナーとして意思決定ができません。

AIがある時代でも必要か

AIがUIを高速に生成できる時代になっても、これは変わりません。
AIに「いい感じのアプリ作って」と言っても、いい感じのものは出てこない。

「誰の・どんな課題を・どう解決するか」が曖昧だと、AIも曖昧なものしか出せずに、悪い意味で普通のものになります。

AIで実行速度が上がった分、ボトルネックは「何を作るか決める力」に移っているので。AI時代こそ、「ユーザー理解」をしてアイデアをユーザーの具体的な体験に向ける価値が上がっています。

デザイナー＝サービス・プロダクトをデザインする人

BONO的にはデザイナー職を目指してもいいのですが、従来の”UIなどをつくるがメインの人”ではなく、IT業界においては『サービス・プロダクトをつくる人』という意味でのデザイナーになった方が良いと考えています。

なぜかというとUIをつくるだけだと、元々やりたかったユーザー価値をデザインすることのごく一部に過ぎないのと、それがAIとデザインシステムで効率的に実現できるようになってきたからです。

逆にめんどくさいことは任せて、本質的な価値のデザインに使う時間と余白が増えています。

そのためこういうユーザー理解・調査もUXデザイナーとかそういう肩書きに閉じるつまらない考えはやめて”価値をデザインするために必要”なものは全部身につけて実行していきましょう💪

ユーザー理解で体験をデザインするためのスキル地図

じゃあ具体的に何を身につければいいのか。
UIの前に必要なスキルは、大きく3つのステップからなります。

『ユーザー理解から体験を棚卸してデザインするステップ』

• ステップ1. ユーザーのゴールを定義する : 具体的なゴール定義をすることで、何を深掘りすべきかが見えてくる。
• ステップ2. 課題を特定する : ユーザーの現状を理解して、ゴールと現実のギャップを明らかにする。そのギャップを生んでいる障壁（課題）を見つけて、障壁の原因を特定する。
• ステップ3. UI体験を設計する : 理想の体験フローを書いて、コア体験からUIを作り、フロー単位で検証する。

上から順にやって終わり、じゃない

この3ステップ、1回ずつやって完了ではないです。サイクルで何度も回すものです。

ゴールを仮で定義して、課題を掘って、UIを作ってみる。作ると「ここが定義できていない」が見える。見えたら戻って定義し直します。考えているだけじゃなく、1度具体化すると分かるものが増えていきます。

作ることは考えること。サイクルの回数がクオリティにつながります。
ここからこの3ステップを、実際のフィードバック事例を使って1つずつ見ていきます。

【ポイント】ユーザーヒアリングで具体化する💭

ゴールも課題も、自分の頭だけで考えても抽象的なまま終わります。AIを使ってもアイデアは出せますが本当にリアルなのか？は、入力するプロンプトで左右されてしまいます。

実際のユーザーに話を聞くことで、ゴールの具体像や現実の行動とその背景の情報が見えてきます。

数字でざっくりした傾向はつかめる。けど1人のユーザーをちゃんと把握することで、数字では見えない具体的な行動や心理が発見できる。これが体験設計の鍵になります。AIでも仮説は持てるけど、具体の確証はつかめません。

つまりヒアリングをはじめとしてUXリサーチは「やると良いこと」じゃなくて、ステップ1・2を実行してユーザー価値を形にするための手段になります。

事例：あるレシピ提案アプリの話

次のセクションで、ステップごとに具体的な説明をする際に、BONOのコミュニティで実際にあったフィードバック事例を使って進めていきます。

あるメンバーが、レシピ提案アプリを設計していました。ゴールは「ユーザーが自炊を無理なく続けられるようになる」こと。ユーザーインタビューも実施して、UIも作った。ビジュアルのクオリティもわるくない

けど、フィードバックで複数の根本的な問題を指摘された。
全部に共通していたのは、「UIの前のステップ」が抜けていたということ。

見た目はいい。でも、ユーザーの課題がちゃんと定義されていないまま画面を作っていた。だから「何を置くべきか」の根拠がなかった。

ここからは各ステップで何をしないといけないのかを説明しつつ、この事例も使って補足していきます🙋

🏃‍♀️ステップ1 — ゴールを具体的に定義する

まず最初にやるべきは、ユーザーのゴールを具体的に定義すること。
「具体的に」ってどのぐらいか。基準はシンプルです。

一人のユーザーがその状態を達成できるのがイメージできるぐらい、具体的に定義する。

なぜ具体的じゃないとダメなのかというと、抽象的だと、何をリサーチで得るべきか、何を体験に反映するべきか、また課題とその原因がなんなのか？を具体的に考えることが困難になるからです。

事例で見てみよう

この事例ではゴールが「自炊を無理なく続けられる」だった。

一見ゴールに見える。けど具体化しようとするとこうなる。
「無理なく続けられる」って、具体的に何が起きている状態？

• 毎日？ 週3回？ どのぐらいの頻度で「続いている」と言えるのか？
• 「無理なく」って何？ 時間がかからないこと？ 考えなくていいこと？
• そもそもこの人にとって「続けられている」ってどういう実感？

こうやって具体化しようとすると、わかっていないことがどんどん出てくる。

これがめちゃくちゃ大事です。
これが”良い体験”の条件に繋がるし、”課題の原因”の把握につながります。つまり解像度高く体験をデザインできる情報が手に入るわけです。

逆にゴールが抽象的なままだと「何を調べればいいか」すらわからず、いきなり手段（UIの機能）に飛んでしまいます。

ヒアリングでゴールを具体化する

ゴールの具体像は自分の想像だけでは作れません。ユーザーに聞いて初めてわかるものです。

この事例では「自炊を無理なく続ける」がゴールだったけど、ユーザーにとって「無理なく」が何を指すのかはヒアリングしないとわからない。

聞くべきことは例えばこういうこと。

• 「理想の状態って具体的にどういう感じですか？」
• 「そのとき何をしていますか？」
• 「何が見えていて、何を感じていますか？」

聞いた内容をもとにゴールを具体的に書き直します。まだ曖昧なら追加で聞きましょう。

🏃‍♀️ステップ2 — 課題を特定する

ゴールを定義したら、次はユーザーの課題とそれを引き起こしている原因を特定します。
ちなみに課題定義が様々な方向性を決めるので、UIで体験をデザインする上で最も明確にしたい情報です。

このセクションでは以下の3つを扱います。

1. 課題とは何か — ゴールと現実のギャップ構造
2. ブレイクダウンで課題の原因を見つける — 抽象→具体に分解する
3. 課題を特定できた状態とは — UIで何をすべきかが導けるかどうか

□ 1:課題とは何か — ゴールと現実のギャップ構造

ユーザーには「なりたい状態」（ゴール）がある。そして「今の状態」（現実）がある。この2つの間にギャップがあります。

ゴール達成を邪魔しているもの、それが課題。
その課題がなぜ存在するのか、何が邪魔しているのか、それが課題の原因。

課題の原因を特定することで解決策につながります。

この構造がわかっていないと、「起こっている事実」をそのまま課題と呼んじゃうのが、めちゃくちゃよくあるパターンです。

ヒアリングでギャップを埋める情報を集める

課題と原因を特定するためにまず、ゴールに向けて、今どういう行動をしていて、何が起きているかをヒアリングで聞きます。
ゴール状態になりたいのに、それができない”障壁のギャップ"が見えたら「なぜそうなっているのか」を掘って具体的に把握していきます。ここがヒアリングの核心です。

聞き方で大事なポイントがあるとすれば、「うまくいかなかった話」だけじゃなくて、「うまくいった話」も聞くこと。うまくいったときと、いかなかったときの差に、障壁のヒントがあることがあります。

また初歩的ですが闇雲にインタビューをするのは失敗確率が高いです。
例えば、課題を見つけるフェーズならどういう話を深掘りをすると聞ける確率が増えるか？を考えてヒアリングの準備をすることもとても大切です。

□ 2 : ブレイクダウンで課題の原因を見つける

ヒアリングで”事実＝ゴールに対して行なっていること”がわかり、課題になりそうなポイントが見つかったらその部分を深掘りしていきましょう。

ブレイクダウンして”理由・なぜ・何がそうさせているか”を深く掘ると原因に辿り着きやすいです。

やることは大きく3つです。

① 事実と原因を区別する

ヒアリングで出てきた情報をそのまま「課題」と呼んでしまうのはよくあるパターンです。まず事実と原因を区別する必要があります。

例えばヒアリングで「家に食材がない」「レパートリーが1種類しかない」「疲れていて準備できない」という話が出てきたとします。

「家に食材がない」「レパートリーが少ない」は起こっている事実であって、課題（原因）じゃない。「疲れている」「めんどくさい」も表層的すぎて、ここからUIで何を作るべきかは判断できません。

事実を集めたら、次に**「なぜそうなっているのか」を掘る**必要があります。

② ゴールから条件をブレイクダウンする

ゴールから「それを達成するには何が必要か」を段階的に分解していきます。

具体的にいけばいくほど対象は狭くなる。けどそれでいい。
まずは一人を深く認識して、救えることが大事です。広げるのは後で簡単にできます。

大事なのはレイヤー5まで降りること。抽象的な層で止まって手段に飛ぶと、何を作ればいいかの根拠がないままUIを作ることになります。

③ 「UIで何をすべきか」が導けるまで原因を掘る

ブレイクダウンでレイヤー5まで降りたら、「なぜそれができていないのか」をさらに具体的にしていく必要があります。

ここで止まりがちなのが「疲れているから」「めんどくさいから」のような表層的な原因。これだとUIで何を作るべきか判断できません。

原因の掘り方は状況によって変わりますが、共通して大事なのは**「なぜ？」で止まらず、具体的に何が・どう邪魔しているのかまで言語化する**ことです。

• 「なぜできないのか」→ 表層的な答え（疲れている、めんどくさい）
• 「じゃあ同じ条件でもできていることはないか？ その差は何か？」→ もう一段具体的な答え
• 「具体的に何が足りなくて、何があれば動けるのか？」→ UIの方向が見える答え

この事例では、ユーザーは疲れていても米を研いで炊飯していた。つまり「疲れている」は本当の原因じゃない。この人が動けるのは「食べたいものが明確」「手順を知っている」「簡単だとわかっている」の3つが揃っているときです。

それならそれをユーザーが得られる体験を提供できれば解決できる確率が上がるかもしれません💡

具体的には、自分の制約条件（簡単・少食材・火なし）と好み（食べたいと思えるか）の両方を満たすメニューが何なのか把握できていない。米は偶然知っていただけで、同じ条件を満たす他のメニューを発見する手段がない。だからレパートリーが増えず、飽きたら自炊が止まります。

ここまで原因が具体的になると、UIの方向も決まります。「条件 × 好み」の掛け合わせで「これなら作りたい」と思えるメニューに出会わせる体験を作ればいいわけです。

□ 3 : 課題を特定できた状態とは

課題の原因をどこまで掘ればいいのか。

その原因から、「このユーザーの具体的な障壁を取り除くUIの体験」が導けるかどうか。 これが判定基準です。

注意してほしいのは、浅い原因からでも浅い解決策は導けてしまうこと。例えば：

• ❌「疲れているから準備できない」→「じゃあ簡単にしよう」— これは導けているように見えるけど、このユーザー固有の障壁が何も特定されていない。「簡単にする」は誰にでも言える。何をどう簡単にすればこの人が動くのかがわかりません
• ❌「作りたいものを見つける手段がない」→「じゃあレシピを出そう」— まだ抽象的。どういうレシピを、どういう条件で出せばこの人に刺さるのかがわかりません
• ✅「制約条件（簡単・少食材・火なし）と好み（食べたいと思えるか）の両方を満たすメニューを把握できていない」→「条件 × 好みの掛け合わせでマッチするメニューに出会わせる」— この人の具体的な障壁に対して、具体的な体験が導ける

ポイントは、「誰にでも言える解決策」ではなく「このユーザーの具体的な障壁を取り除く体験」が見えるかどうか。見えないなら、まだ掘りが足りません。

課題の原因が特定できると、ここから先のUI体験設計の判断軸が手に入ります。どの画面に何を置くか、どの情報を優先するか、どんなフローにするか — 全部この原因を「解決できるかどうか」で判断できるようになる。逆に言うと、ここが曖昧なまま次に進むと、UIの判断が全部「なんとなく」になってしまいます。

🏃‍♀️ステップ3 — UI体験を設計する

ゴールを定義して、課題の原因を特定できたら解決策を考えましょう。
いよいよUI体験の設計に入ります。

ここで大事なのは、1画面ではなく解決のフローでUI体験をプロトタイピングすることです。

1画面ではなくフローで考える

UIを作るとき、つい「この画面をどうするか」から考えがちです。けどユーザーの課題は1画面で解決するものではありません。ユーザーがゴールに到達するまでには複数のステップがあります。

そのステップの流れごとに体験設計するのがUIデザインでは大切です。

やることは2つ。

① 課題の原因を解決するフローを設計する

ステップ2で特定した課題の原因を解決するために、ユーザーがどういう順番で何を体験すれば、ゴールに到達できるかを考えます。

各ステップは「ゴールに向かって障壁を1つずつ取り除いていくもの」。フロー全体を通じて、ユーザーが現実からゴールに近づいていく流れを作ります。

② コア体験から固める

フローの中にはユーザーにとって一番価値がある体験（コア）があります。通知画面や設定画面から作り始めるんじゃなくて、コアから先に固める。

通知が来ても、コアがダメなら使わない。周辺はコアが固まった後で詰めていきましょう。

ポイント💡：体験フローの質は課題特定の質で決まる

体験フローには質の差があります。

課題の原因が曖昧なまま書いたフローは「ユーザーがなんとなくハッピーになる」ぐらいの解像度にしかなりません。課題の原因が具体的に特定できていると、「この障壁がこのステップで取り除かれるから、ユーザーはゴールに近づける」と説明できるフローになります。

つまりステップ2の課題特定が甘いと、ここで良い体験フローは書けない。全部つながっています。

体験フローの具体的な書き方・進め方は「シナリオベースドデザイン」のコンテンツで詳しく解説しています → （リンク）

サイクルを回す — 1発で正解は出ない

ここまで読むと「この流れでやれば良いのか」というイメージが湧いてくるかもしれません。
ただ気をつけないといけないのは、この3ステップは1回やって終わりの直線ではないことです。

できるだけ早く最初はステップの全てまで行って「考え↔︎具体」を行き来できるようにすることで、全体の解像度が上がります。
つまりステップですが、サイクルで行ったり来たりしながら全体の解像度を上げていくことが大切です。

プロトタイプを作ると何が見えるか

考えを形にしてみるプロトタイプを作成すると、具体的に自分で体験ができるので様々なことに気づきやすいです。

• いざプロトタイプを作ってみると、”この画面・情報は必要なんだっけ？”に迷いが起こり、定義がまだ曖昧な可能性が見えてくる。
• プロトタイプを見ると、1画面を作り込んでしまい「解決につながるフロー全体が設計が弱い」ことが気づけた
• 整理した「課題の原因」にアプローチしてない無駄な情報や画面があることに気づいてしまう。

これは全部「作ったからこそ見えた問題」です。
頭の中で考えているだけでは気づけなかった。

プロトタイプは完成品じゃない。定義の甘さを可視化して質を高めるプロセスです。
見えた問題を持ってステップ1・2に戻り体験をどんどん詰めていけます。

まとめ

全体像をまとめるとこうなります。

ユーザー理解からの体験設計をサイクルを回せるようになれば、「見た目がいい」だけじゃなくて「ユーザー価値に届くUI」が作れるようになります。

BONOのUXコースで実践しよう

この記事で示した地図を、実際のプロジェクトで歩いてみる場所がBONOのUXコースです。
ゴール定義、課題特定、UI体験設計。このサイクルを実際のお題で回す練習を、フィードバックをもらいながら進めることもできます。