UIデザインの根拠となる2つの原則は、情報の明瞭性と目的ある装飾である。 すべての視覚的要素は、自分が何を伝えているかで存在を正当化しなければならない。

When to Use

• 新しいUIを設計・実装したいとき
• 既存UIを、情報設計から組み直して実装方針まで出したいとき
• 画面構造、状態、優先順位、CTA の順序を整理したいとき
• ただ美しくするのではなく、意味が伝わる見た目にしたいとき
• 実装方針とデザイン根拠を同時に出したいとき
• 余白やコントラストを含めて、なぜその見た目なのかまで説明したいとき

Do Not Use

• 完成UIの総合監査だけが目的のとき。ma-review を使う
• 可読性やアクセシビリティだけを点検したいとき。ma-legibility を使う
• 「この Delete は何を消すのか」など、作用対象の明確化だけが目的のとき。ma-mapping を使う
• 既存スタイルの不整合や token drift だけを点検したいとき。ma-system を使う
• 単純に見た目だけを派手にしたいが、情報設計は触らないと決まっているとき

Design Philosophy

1. UIは人間の認識と操作のために最適化されなければならない。 情報の階層・レイアウト・インタラクションパターンは、人が自然に知覚し行動する方法から 生まれるべきであり、慣習やトレンドからではない。

2. 装飾は情報のために存在する。 色、余白、影、モーション、タイポグラフィ、サイズは 「これは何を伝えているか？」に答えなければならない。 「見た目がいい」は正当な理由ではない。「Xを伝えている」が正当な理由だ。

3. 余白とコントラストは、雰囲気ではなく構造である。 余白はグルーピング、リズム、密度、焦点を伝える。 コントラストは可読性だけでなく情報優先度を伝える。

Workflow

1. エンティティ・状態・関係を整理する
2. ユーザーが認識すべき認知順序を定義する
3. その順序を支える最小の視覚システムを決める
4. コントラストと余白のルールを先に定義する
5. 実装方針を出す
6. 完成物レビューが必要なら ma-review に渡す

詳細ルール:

• references/judgment.md
• references/contrast.md
• references/spacing.md
• references/patterns.md

Data and Judgment

Meaning is designed before it is measured.

• データは作用の証拠にはなるが、意味の源泉にはならない
• 意味、階層、mapping、一貫性をゼロから決めるために metric を使ってはならない
• A/B テストは、すでに意味が成立している案同士の経験的な不確実性を比べるときだけ使う

問いの種類と詳しい運用ルールは references/judgment.md を参照。

Constraints

• 視覚的階層は情報の優先度を直接反映しなければならない
• 次に可能なアクションは説明なしに自明でなければならない
• レイアウトは認知的フローに従わなければならない
• 色の使用には、状態・カテゴリ・優先度・関係性・フィードバックのいずれかの目的が必要
• アニメーションとモーションは状態遷移または因果関係を伝えなければならない
• タイポグラフィの階層はグレースケールでも読めなければならない
• コントラストは閾値を満たすだけでなく、優先度の差を伝えなければならない
• 余白は装飾ではなく構造を伝えるために使うこと
• 局所指標の改善で全体の意味体系を壊してはならない
• 完成物の監査はこのスキルで抱え込まず、ma-review へ渡すこと
• 単一論点の見直しは親スキルで抱え込まず、必要に応じて ma-* サブスキルへ寄せること

High-risk Default Patterns

これらは既定では避けるべき高リスク表現である。禁止のためではなく、 説明責任なしに採用すると意味構造を壊しやすいからである。

• Glassmorphism
• 主テーマとしてのグラデーション
• 装飾的な影
• 雰囲気としての色
• 構造的理由のない丸いカード
• opacity-based text color
• flat contrast scale
• uniform spacing throughout
• spacing as decoration
• Proxy worship
• Pixel-level empiricism
• Local metric optimization
• Measurement before meaning

失敗理由、許容条件、説明義務は references/patterns.md を参照。

Sub-skills

ma は設計・実装のスキルである。審査・改善は専用サブスキルに委ねる。

Output Contract

このスキルの出力は、常に次の骨子で返すこと。

必須セクション

• 画面またはコンポーネントの目的
• 情報構造
• 主要状態と主要な状態遷移
• CTA とその優先順位
• 実装上の構成案
• デザイン根拠

デザイン根拠に含めること

• 何を先に見せるか
• 何を後に見せるか
• なぜその視覚ルールが必要か
• 何を削るべきか
• 例外的に高リスク表現を採用した場合、それが何を伝え、なぜ必要か
• spacing rationale
  • spacing scale
  • grouping logic
  • rhythm logic
  • where negative space is used
• contrast rationale
  • どのコントラスト帯を使うか
  • どの背景に対して検証するか
• metrics や experiments を使うなら、何を意味判断で先に決め、何だけを測ったか
• 必要なら次にどのサブスキルでレビューすべきか

どれか一部だけを返してはならない。 哲学だけで終わらず、必ず実装指向の構成案まで含めること。

Example

入力: 「分析ダッシュボードを設計して。数値だけでなく、何を見るべきかが分かるようにしたい。余白とコントラストの根拠もほしい」

期待: エンティティ、状態、優先順位、主要CTAを整理したうえで、実装方針とデザイン根拠まで返す。

追加例は references/examples.md を参照すること。