---
name: design-judgment
description: 設計系スキルの入口。「AIっぽい」「テンプレート感」「もっと洗練させたい」「管理画面のレビュー」など画面設計の相談を受けたら、業務構造の診断(ux-design §0-1〜§13-1)と見た目の素材(jp-web-design)のどれをいつ読むかをここで決める。UIの新規設計・リニューアル・レビューの着手時に必ず最初に開く。
---

# Design Judgment — 設計の入口(どのスキルを、いつ読むか)

> AIっぽいUIは、UI部品の平均値を並べた画面。AIっぽくないUIは、業務の構造がそのまま画面の構造になっている。

「AIっぽさ」は色や角丸ではなく、**設計判断(何を主役にし・何を隠し・どの操作を一手で終わらせるか)が見えないこと**の問題。本スキルはその判断を下すための問いを持たず、**設計の実体 Skill `ux-design`** と **見た目の素材 Skill `jp-web-design`** のどこを読むかだけを決める。

## 読む順(常にこの一方向)

**design-judgment(入口) → ux-design(設計の実体: 業務構造の診断・体験の規律・検収) → jp-web-design(日本語UIの素材: 色(平賀カラー既定 / Pop)・タイポ・部品)**。逆方向には戻らない。

| 状況 | 読む場所 |
|---|---|
| 新規画面・リニューアルの着手 | ux-design §0(3点)と §0-1(業務構造の発見)で中心対象・最頻操作を確定 → §2-3(主役と隠すもの)→ jp-web-design 起動プロトコル |
| 「AIっぽい」「テンプレート感」「無機質」と指摘された | ux-design §13-1(装飾除去テスト)で崩れた項目を特定 → §0-1 / §2-3 に戻って構造から直す。色・トークンの調整から入らない |
| 「Appleのように」「触り心地」「洗練」を求められた | ux-design §11-1(触りたさの5要素)と `references/apple-polish.md` |
| 一覧・単票・分析など画面の型で迷う | ux-design `references/structure-diagnosis-by-domain.md` |
| ダッシュボード・管理画面のレビュー | ux-design §9(ホーム)→ §13(検収)→ jp-web-design `references/acceptance-checklist.md` |
| 「見づらい・ダサい」の改善依頼 | jp-web-design `references/information-design.md` §1 で症状特定 → §8 のリライト手順 |
| フォーム・一括操作・エラー回復の実装 | ux-design §4 / §5 / §7 と各 references。見た目の部品は jp-web-design `references/components.md` |

## 進め方の原則

- 問いはユーザーへの質問票ではなく、エージェントが会話・コード・画面・業務語・利用頻度・ログから答えを導く**内部診断**。通常は事前質問ゼロで進める。
- 無難な複数案ではなく、判断根拠が最も強い構造を1つ選び、最初の成果物は完成度の高い代表画面または構造変更の差分にする。ユーザーには空欄を埋めてもらうのではなく、**成果物のどこを変えたいか**だけを判断してもらう。
- 各判断の答えは `ux-design/assets/structure-worksheet.md` を複製して1行ずつ残す。言葉にできない項目は、まだ判断していないという合図。