目的と制約を先に置く (Goals & Constraints First)

「このUIをもっとおしゃれにしたい」「最新のUIトレンドを取り入れたい」「競合サービスにある機能を追加したい」——これらはすべて、目的ではなく手段の話です。

よくある失敗パターンは「ソリューションから設計を始める」ことです。「カルーセルを使いたい」「タブUIにしたい」「ダッシュボードを作りたい」——UIの形を先に決めてしまうと、ユーザーが本当に達成したいこと（ゴール）と、実際の制約（技術・時間・予算・ユーザーの環境）が後から判明して、設計をやり直すことになります。

目的と制約を後から発見するコストは膨大です。「ユーザーはスマートフォンで使う」という制約を設計後に知ったら、デスクトップ前提のUIを全面的に作り直す必要があります。「ユーザーのゴールは比較ではなく購入決定だ」と設計後に気づいたら、比較表中心のUIを購入フロー中心に再設計する必要があります。

1. 原則の定義

目的と制約を先に置く（Goals & Constraints First）とは、UIの形（コンポーネント・レイアウト・インタラクション）を決める前に、「ユーザーが達成したいこと（ゴール）」と「設計上の制約（技術・環境・時間・ユーザー特性）」を明確に定義し、それを設計判断の起点とする原則。

本質は「UIはゴールと制約の解答である」ということです。ゴールと制約が明確であれば、UIの形は自然に決まります。「ユーザーは5秒以内に商品を見つけたい（ゴール）」「モバイルで片手操作が前提（制約）」→ 大きなタップターゲット・シンプルなナビゲーション・検索ファースト、という設計判断が導き出されます。

2. いつ使うか（適用場面）

特に重要になるケース

• 新機能の設計開始時: 「何を作るか」を決める前に「なぜ作るか（ユーザーのゴール）」と「何ができないか（制約）」を定義する。
• 既存UIの改善時: 「見た目を変えたい」ではなく「ユーザーが達成できていないゴールは何か」から改善を始める。
• 複数案の評価時: 「どちらのUIが好きか」ではなく「どちらがゴールをより効率的に達成できるか」で評価する。
• ステークホルダーとの合意形成: 「このUIにしたい」という主観的な議論を、「このゴールと制約に対して、どちらの設計が適切か」という客観的な議論に変える。

トレードオフが起きる場面

• ゴールの競合: ユーザーのゴールとビジネスのゴールが相反する場合（例：ユーザーは解約したい、ビジネスは引き止めたい）。どちらを優先するかを明示的に決定する。
• 制約の変化: 設計中に制約が変わる場合（例：当初はデスクトップ専用だったが、モバイル対応が必要になった）。制約の変化を設計判断の再評価のトリガーにする。

3. なぜ重要か（設計判断の核）

UIはゴールと制約の「解答」だ。問いを定義せずに解答を書いても、正解にはならない。

設計判断の基準

• 「このUI要素は、ユーザーのどのゴールを達成するために存在するか？」→ 答えられなければ、その要素は不要かもしれない。
• 「この設計判断は、どの制約に対応しているか？」→ 制約なき設計判断は、後から制約が判明したときに崩れる。

優先順位の考え方

• 1. ユーザーのプライマリゴール（最優先）: ユーザーがそのUIを使う最大の理由。これを達成できない設計は、どれだけ美しくても失敗。
• 2. 技術・環境の制約: 実装できない設計・動作環境で機能しない設計は、どれだけ理想的でも意味がない。
• 3. ビジネスゴール: ユーザーのゴールと両立する範囲でビジネスゴールを達成する。

例外条件

• 探索的なプロトタイピング段階では、ゴールと制約を厳密に定義する前に、アイデアを形にすることが有効な場合がある。ただし、プロトタイプを評価する際には必ずゴールと制約を基準にする。

4. 具体の設計ルール（チェックリスト）

最低ライン（Must - これ守らないと危険）

これがないと、設計の方向性がブレ続け、手戻りが発生します。

ユーザーのプライマリゴールが定義されているか: 「このUIを使うユーザーが達成したいこと」が一文で書けるか？（例：「最短時間で目的の商品を見つけて購入する」）
主要な制約が列挙されているか: 技術制約・デバイス制約・ユーザー特性・時間制約など、設計に影響する制約が明示されているか？
設計判断がゴールと制約に紐づいているか: 「なぜこのUIにしたか」を問われたとき、ゴールと制約を根拠に説明できるか？

理想ライン（Better - できると強い/プロの品質）

「作れる」を超えて「正しいものを作っている」状態です。

ゴールの優先順位が決まっているか: 複数のゴールがある場合、どれが最優先かが明示されているか？（例：「購入完了 > 商品発見 > 比較」）
制約がゴールの達成を妨げていないか確認しているか: 制約によってプライマリゴールが達成できなくなっていないか？（例：「モバイル制約があるのに、重要なCTAがスクロール下部にある」）
ゴールと制約をチームで共有しているか: デザイナー・エンジニア・PM全員が同じゴールと制約を理解し、設計判断の根拠として使っているか？

5. UI例

同じ「商品一覧ページ」でも、ゴールと制約を先に定義するかどうかで、設計の方向性は大きく変わります。

改善プロセス

1. ゴールを一文で書く: 「ユーザーが〇〇を達成できる」という形で、プライマリゴールを一文で定義する。曖昧な「使いやすいUIにする」ではなく、測定可能な「3タップ以内に購入を開始できる」のように具体的に。
2. 制約を列挙する: デバイス・通信速度・ユーザー特性・技術制約など、設計に影響する制約をすべて書き出す。
3. 設計判断をゴールと制約に紐づける: 各設計判断に「なぜ」を添える。「検索ファーストにした理由：ゴール（3タップ以内）＋制約（初回ユーザー多数）」のように。

6. 関連リンク

• 関連リファレンス（理論）: メンタルモデル (Mental Model)
• 用語集（定義）: メンタルモデル, 認知負荷
• 関連するUI原則（横）: 主要導線を先に決める (Primary Path), 単純化 (Simplicity), 進行開示 (Progressive Disclosure)

7. まとめ

今日から直せる一手 次に設計を始める前に、付箋に「ユーザーのゴール：〇〇」「主要な制約：〇〇」を書いてモニターに貼ってください。設計中に迷ったとき、この付箋に立ち返ることで、ゴールと制約に基づいた判断ができます。

チームに共有するなら一言 「UIの形を議論する前に、ゴールと制約を議論しよう。問いが正しければ、答えは自然に決まる。」