novelsavage Mori UI
題材・操作目的・情報構造から、その画面固有の視覚言語を作る。流行の見た目を自動適用せず、ユーザーが嫌う「AIが考えなしに作ったUI」を防ぐ。
このスキルは固定テーマではない。黒地、蛍光色、ドットフォントなど、過去作品の表層を毎回コピーしない。プロジェクトごとの必然性を優先する。
参照する
作業前に次を読む。
references/style-principles.md: Moriらしさを画面へ翻訳する原則references/anti-slop.md: AI既定表現の禁止・例外・コピー規範references/verification.md: 実装後の表示・操作・回帰確認
1. 現状を読む
変更前に、リポジトリ、実行中の画面、既存コンポーネント、ロゴ、フォント、主要フローを確認する。スクリーンショットだけで判断できる場合も、可能なら実装と実画面の両方を見る。
次を一文ずつ答えられる状態にする。
- この画面で利用者が完了したい仕事は何か。
- その仕事の主役となる対象は何か。
- どこで、どの頻度で、どの端末から使うか。
- 残すべき既存の操作・ブランド要素は何か。操作名、配置、確認手順、実行可能条件も記録する。
- 現在のUIで「汎用AIテンプレ」に見える箇所はどこか。
明示された現在の要望を最優先する。既存コードや過去作品は参考資料であり、現在の指示より上位ではない。
2. Design Readを決める
実装前に短い設計判断を置く。
画面の仕事:
主役:
利用状況:
情報密度:
既存データと比較に必要な項目:
固有の視覚モチーフ:
残す操作:
避ける既定表現:
「モダン」「洗練」「未来的」だけでは不十分。たとえば地図なら座標・方位・レイヤー、OCRなら紙・付箋・処理キュー、グラフならノード・接続・ターミナルログのように、題材から部品と関係性を引き出す。
3. 視覚契約を作る
コードを書く前に、最低限のトークンと役割を決める。
- 色: 背景、前景、境界、主アクセント、警告、成功を4〜6色程度で定義する
- 文字: 本文、見出し、数値・識別子の役割を分ける
- 境界: 線、面、余白のどれで区切るか決める
- 角丸: 対象の意味に合わせ、全要素へ同じ大きな半径を配らない
- 輪郭アクセント: 状態や分類を符号化しない限り、角丸カードの一辺だけを着色して飾らない
- 密度: 一覧・操作画面は情報量を保ち、鑑賞画面は主役へ空間を渡す
- 動き: 状態変化や因果を伝える用途に限定する
デザイントークンはCSS変数など一箇所で管理し、場当たり的な色・影・半径を増やさない。
4. 構造から実装する
主役を先に配置し、操作と説明をその周囲へ置く。
- 地図、グラフ、映像、文書などが主役なら、画面の大部分を主役へ渡す
- ナビゲーション、ツール、ステータスは仕事の流れに沿って置く
- 余白、罫線、背景差、見出し階層で区切り、カードを最初の選択肢にしない
- カードは、独立して選択・移動・比較できる対象、意味的に自己完結したフォームや要約、開閉可能な詳細など、境界が理解を助ける単位に使う
- 紙や付箋などのモチーフも、注釈や確認待ちなど意味のある箇所へ限定する
- 操作状態、空状態、読込中、エラー、成功、無効状態を実装する
- 削除などの危険操作は視覚的に分離し、確認と処理中の二重実行防止を保つ
- モバイルでは縮小版にせず、重要度に沿って並びと露出を変える。表を安易にカード化せず、優先列、詳細展開、横スクロールを比較して選ぶ
既存のロゴ、ファビコン、ナビゲーション、主要アクション、キーボード操作を、依頼なく削除しない。
5. コピーを業務言語にする
何ができ、次に何が起き、失敗時にどう戻れるかを直接書く。
- 見出しは画面や処理の名前にする
- ボタンは動詞で書く
- 説明文は条件、入力、出力、制約を伝える
- 状態文は対象、現在地、次の操作を示す
「体験を再定義する」「可能性を解き放つ」など、製品固有の情報を持たない詩的コピーは使わない。実データがないのに、架空のKPI、受賞歴、顧客ロゴ、推薦文を作らない。
見出しの前後に、意味を持たない英語キッカー、連番付きの章ラベル、同内容の副題を装飾目的で足さない。各テキストについて「利用者の判断・操作・現在地の理解に必要か」を問い、見出しを読めば分かる文言は削る。ブランド名、対象の識別子、実際の手順番号、状態、単位など機能を持つ短い表記は残す。
6. Slop監査をかける
実装対象に対して、同梱スクリプトを補助的に使う。
uv run --no-project python <skill-dir>\scripts\audit_ui_slop.py <ui-root>
CIなどで高重大度だけ失敗させる場合:
uv run --no-project python <skill-dir>\scripts\audit_ui_slop.py <ui-root> --fail-on high
機械判定は候補抽出であり、最終判断ではない。題材上の必然性がある表現は残し、理由を説明する。違反を消すためだけに別の装飾へ置換しない。
7. 実画面で検証する
references/verification.md に沿い、可能なら実際の開発サーバーを起動してデスクトップとモバイルを確認する。
最低限、次を行う。
- lint、型検査、ビルド、関連テスト
- 主要画面のスクリーンショット確認
- 主要操作と状態遷移の確認
- キーボードフォーカス、コントラスト、モーション抑制の確認
- 変更前に存在した主要機能の回帰確認
スクリーンショットを見て「この題材を知らないテンプレ生成器でも同じ画面を作れるか」を問う。答えが「はい」なら、装飾を増やすのではなく、主役・構造・用語・操作順を題材へ寄せ直す。
完了条件
- 画面の主役と主操作が一目で分かる
- 視覚表現に題材または操作上の理由がある
- 紫グラデ、巨大角丸、影付きカード、ピル、ガラス表現が惰性で反復されていない
- コピーが具体的で、架空の権威付けを含まない
- 既存の重要な操作を保っている
- デスクトップとモバイルで実画面を確認している
- 機械監査とプロジェクト固有の検証結果を説明できる