# UI UX Design

> UI・画面・導線の設計判断を行うスキル。新規画面や機能追加時のUI設計・アクション配置、既存UIの整理・シンプル化、要件段階の画面遷移・情報設計、UI設計レビューで、「UIを設計して」と明示されなくても使う。検討手順（オブジェクト→構造→フロー→データ状態→UI）と、入口統合・段階的開示・配置の判断基準を提供する。色・タイポグラフィ等ビジュアル表現の作り込みは対象外。コードの境界設計は module-boundary-design、API 設計は restful-api-design を使う。

- Skill: `efoo-team/ui-ux-design` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add efoo-team/ui-ux-design`
- Raw SKILL.md: https://api.skillmd.com/api/skills/efoo-team/ui-ux-design/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: efoo-team (https://skillmd.com/u/efoo-team)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/efoo-team/ui-ux-design

---


# UI/UX 設計スキル

UI の設計判断（何を・どこに・どの深さで・どんな器で置き、どう気づかせるか）を行うための思考手順と判断基準。確立されたデザイン理論は再解説せず、各場面で「どのレンズに則って検討するか」を指名する（レンズ＝学習済みの知識を呼び出す名前）。

---

## スコープ

- **使う**: 新規画面・機能の UI 設計、アクション・ボタンの配置判断、既存 UI の整理・統合・シンプル化、画面遷移・情報構造の設計、UI 設計・仕様のレビュー。
- **使わない**: 色・タイポグラフィ・装飾などビジュアル表現の作り込み、コンポーネントの実装詳細、コードのモジュール分割（module-boundary-design）、API 設計（restful-api-design）。
- **軽量パス**: 既存パターンの内側で完結する軽微な変更（文言修正・既存一覧への項目追加など）は、手順全体を課さず「決定領域マップ」の該当行と境界条件だけを参照する。新しい入口・画面・フローを作る判断が入った時点で通常パスに切り替える。

---

## 前提原則（すべての判断に先立つ3つ）

### 原則0: 変更コストの高い側から確定する

AI 駆動開発でも変更コストは「データモデル・構造 ＞ フロー ＞ UI 表層」の勾配を持つ。高コスト側から順に確定し、安価になった UI 表層は一発勝負ではなく反復検証の道具として使う。使い捨てプロトタイプを中間物として挟む方法論は採用しない。構造仮説の検証は「実 UI ＋ モックデータ（50行程度）」で行い、当たりが付いてから高コストなデータモデルを本実装する。人間の知覚・認知・行動に関する法則は人間側の定数であり、開発コスト構造がどう変わっても不変で適用する。

### 原則1: 動機の確定度で名詞と動詞を棲み分ける

| 面 | ユーザーの状態 | 設計様式 |
|---|---|---|
| ナビゲーション面（サイドバー・ダッシュボード・一覧起点） | 動機が未確定 | オブジェクト指向: 名詞で全体像を提示し、対象→行動の順に選ばせる（OOUI） |
| 動線上（作業中画面のアクション） | 動機が確定 | タスク指向: 動詞の単一入口→段階的開示（Progressive Disclosure） |

両方式は対立ではなく入れ子である（名詞の世界の中に動詞の入口が埋め込まれる）。同一プロダクト内に両方が共存するのが正しく、使い分けは画面の性質で決まる。

### 原則2: シンプルさは4戦略から選ぶ。「隠す」と「消す」を区別する

画面はシンプルに保つ。ただし複雑さは消えず移動するだけ（Tesler's Law）なので、手段は Colborne の4戦略（Remove / Organize / Hide / Displace）から明示的に選ぶ。Hide を選んだら再発見経路（動線上の配置・情報の匂い）を必ず維持する。「どこへ移すか」を決めずに隠さない。

---

## 設計手順（順序を守る）

いきなり UI から始めない。以下を応答にコピーして進捗を追跡する:

```
- [ ] 0. 前提確認: 誰が使うか（ロール・利用頻度・デバイス）・どの面か（ナビ面/動線上）
- [ ] 1. オブジェクト識別: この UI が扱う名詞と関係の抽出（OOUI のオブジェクト抽出）
- [ ] 2. 全体構造: 各オブジェクトのビュー（コレクション/シングル）・配置面・ナビ上の位置づけ（JJG の Structure 段階）
- [ ] 3. 行動フロー: 動機の発生地点→入口→段階開示→完了を「場所・操作可能要素・接続」で描く（Breadboarding / Wireflows）
- [ ] 4. データ状態の網羅: references/data-states.md のチェックリストを全状態について埋める
- [ ] 5. UI 具体化: 器の選択→コンポーネント→視覚階層→実データ相当で検証（lorem ipsum 禁止）
```

- 手順1と手順4は意図的に分割されている。属性・データ状態の詳細化はフロー確定後に行う（早期の属性詳細化は枝葉の議論で全体構造の合意を遅らせる）。
- 手順1〜2の厳密さには最も高い投資対効果がある。この段階のミスはそのまま高コストなデータモデル変更に直結する。
- 手順3↔5の往復は安価であり、フローと UI の間で迷ったら作って検証してよい。ただし手順0〜2を飛ばす理由にはならない（上流の質が UI 生成の品質上限を決める）。

**red flags（手順スキップの兆候）**: 「画面イメージが先に固まっている」「とりあえずモーダルを足す」「単純な画面だから手順は不要」。単純に見える画面ほど手順0〜2は数分で終わる。省略するのではなく高速に通過する。

---

## 配置と動線の中核基準

各基準は「原則文 → 判断基準 → 歯止め」の形を持つ。

### 動機起点の配置

機能は、データモデルや管理メニューの論理ではなく、その機能を使いたい動機が発生する画面に置く。

- 判断基準: 「ユーザーはこの機能を使いたいと思うとき、どの画面を見ているか」に答え、その画面へ置く。
- 判断基準: 設定の帰属先（組織/拠点/個人などの階層）と配置場所を混同しない。帰属先はデータモデル上の区分であって動機の区分ではないため、配置を帰属先で割らず、帰属先の選択は入口通過後の開示層で行わせる。
- 歯止め: 動機発生点が複数ある場合は主要動線の1箇所に正を置き、他の画面には案内リンクを残す。

### 入口の統合と段階的開示

同じ動機で始まるアクション群は単一の入口に統合し、種別の選択は入口を通った後に行わせる。第一画面には「それができる」ことだけを、ユーザーの動機と同じ粒度の言葉で示す（動機が「何かを申請したい」なら入口は「申請」であり、種別の列挙ではない）。

- 判断基準（統合するか）: ユーザーの最初の一言が同じか（「申請したい」「作成したい」）。同じなら統合し、異なるなら分離する。
- 判断基準（深さ）: 最初に選ぶ操作＝一次（常時表示）、入口を通った後に選ぶ操作＝二次（開示層）。
- 歯止め: 開示は2段階以内。1つのメニュー・開示層に置くアクションは2〜6個。各段階のラベルが次の内容を予測させる（情報の匂いが立つ）ことが、深さを増やす正当化条件。
- 歯止め: 頻用者にはデフォルトタブ・前回選択の記憶・ショートカットで効率を担保する。
- 歯止め: 不可逆・破壊的操作の帰結は開示層に隠さない。

### 動線内完結と投資

作業の途中で必要になる副次機能は、画面遷移させずその場で完結させる。将来を楽にする投資行動（テンプレート化・お気に入り登録など）ほど遷移コストに弱いため、動線内完結を最優先する。

- 判断基準: 「この機能を使う動機は、別のどの作業の最中に発生するか」に答え、その作業の動線内に置く。
- 判断基準: 気づかせ方は pull 型にする（ユーザーが必要とする瞬間に視界へ入る位置に置く）。押し付け型の告知・プロモーションは Nagging（ダークパターン）になる。
- 歯止め: 動線に詰め込みすぎて主タスクの完了を妨げない。

### 配置＝機能可用性の宣言（レビュー観点）

配置はグルーピングと適用範囲の宣言として読まれる。レビュー時は次を確認する:

- 1箇所にしか置かないことで「その画面の単位でしかできない」という誤解を生まないか。
- 分散配置が「別々の機能」という誤解を生まないか。
- 同じ配置パターンを他ロールの同種画面にも一貫して適用しているか。

---

## 決定領域マップ

該当する領域のレンズに則って検討する。レンズの正確な名称・拡張境界条件・確度は references/lens-catalog.md を参照する。

| # | 決定領域 | 指名するレンズ | 最重要の境界条件 |
|---|---|---|---|
| 1 | 入口と開示 | Progressive Disclosure、Hick's Law、Krug の第二法則 | 開示2段階以内・メニュー2〜6項目・ラベルの情報の匂いが深さの正当化条件 |
| 2 | ナビゲーションとIA | OOUI、Information Foraging、flat vs deep、ファセット分類 | ナビラベルに汎用動詞禁止・パンくずは深い階層のみ・ダッシュボードは運用系と分析系を混在させない |
| 3 | 知覚と配置 | ゲシュタルト原則、視覚階層、前注意的属性 | 強調は単一属性かつ希少に・余白で足りる所に罫線を足さない・配置＝グルーピングの宣言 |
| 4 | 操作の物理 | Fitts's Law、ターゲットサイズ標準、サムゾーン、KLM-GOMS | タッチ最低24px（推奨44pt/48dp）・hover 依存禁止・破壊的操作はあえて届きにくく |
| 5 | 器の選択 | モーダル適用基準、ウィザード適用条件、Tabs Used Right、通知階層 | モーダルは短時間自己完結か重大確認のみ・タブは比較不要の同列内容のみ・エラーにトースト禁止 |
| 6 | フォーム | Luke Wroblewski のフォーム設計、reward early punish late、選択式優先 | 未エラーの欄を入力中に叱らない・プレースホルダをラベルにしない・2〜3択はラジオ（ドロップダウン禁止） |
| 7 | エラーと安全 | スリップ/ミステイクの区別、ポカヨケ、Undo 優先、意図的摩擦 | 確認ダイアログの乱用禁止（形骸化する）・type-to-confirm は不可逆操作のみ |
| 8 | フィードバックと時間 | システム状態の可視性、0.1/1/10秒、Doherty threshold、楽観的UI、empty states | 10秒超はバックグラウンド化・自動保存でもドラフト明示と明示的な確定操作を残す |
| 9 | 動線内の発見と投資 | Fogg Behavior Model（B=MAP）、Hooked の Investment、pull revelation | pull 型でなければ逆効果・投資の押し付けは Nagging 化する |
| 10 | B2B・業務システム | UI 密度、一括操作、Hide vs Disable、永遠の中級者 | 高密度は熟練×高頻度画面のみ・権限上不可は hide / 条件待ちは disabled＋理由表示・既定 UI は中級者に最適化 |
| 11 | 言葉 | 動詞＋目的語のボタンラベル、front-loading、ユーザーの言語 | ナビは名詞・ボタンは動詞の分業・表記は用語集で固定 |
| 12 | デフォルトと倫理 | デフォルト効果、ダークパターン類型、sludge | デフォルトは利用者利益基準・解約は契約と同等の手数・偽の緊急性/事前選択済み同意の禁止 |

---

## アンチパターン

| アンチパターン | 症状 |
|---|---|
| 分散配置 | 同じ動機の機能を帰属先・種別ごとに別画面へばらまく |
| 隠しすぎ | 開示段階を増やしすぎて機能が発見されない |
| 統合しすぎ | 動機が異なるアクションまで1つの入口に押し込む |
| 遷移要求 | 作業中に必要になる機能のために別画面へ遷移させる |
| 全部見せ | 今できるアクションを一次層に全部並べる |

---

## 確度の規律

設計判断の根拠として理論・実験を引用するときは references/lens-catalog.md の確度管理表に従う。特に: 「Nine States of Design」は引用禁止（empty states と stress cases で語る）、Fogg モデルの閾値は「action line」ではなく behavior activation threshold と呼ぶ、ジャム実験（選択過多）と Zeigarnik 記憶効果は根拠に使わない。

---

## references

| いつ | 読むファイル |
|---|---|
| 手順4（データ状態の網羅）に到達したら | references/data-states.md |
| 決定領域の拡張境界条件・レンズの正確な名称・引用の確度を確認するとき | references/lens-catalog.md |
| 入口統合・動線内投資・帰属選択の判断に迷ったとき（worked example） | references/case-studies.md |