UI/UX 設計スキル

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

スコープ

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

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

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

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

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

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

原則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 を参照する。

アンチパターン

確度の規律

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

references