Design Polish

既存の画面を、デザイナーがレビューして手を入れたような画面に仕上げるためのスキル。

考え方

対象は「AIが作った画面」ではなく、決断が入っていない画面全般。色も余白も文言も、ライブラリやテンプレートや生成モデルの初期値がそのまま残っていると、どの画面も同じに見える。人が急いで作った画面でも、テンプレートを流用した画面でも、同じことが起きる。「AIっぽい」と言われる画面の正体は紫のグラデーションそのものではなく、誰も決めていないことにある。

だから仕事は装飾の差し替えではなく、決断を入れること。「この製品は誰のためで、画面のどこを最初に見てほしいのか」を決め、その決定から色・文字・余白を導く。紫を青緑に変えるだけ、絵文字をアイコンに変えるだけでは、別の種類の量産品になるだけで何も解決しない。

診断で扱うのは画面に残っている事実だけ。誰が・何が作ったかは推測しないし、診断結果にも書かない(「AIが作ったようだ」ではなく「アクセント色が決まっておらず5色が同じ強さで使われている」と書く)。

守ること

機能を変えない。 見た目と文言だけを触る。ルーティング、データ取得、状態管理、フォームの挙動、id・name・data-testid・イベントハンドラ、リンク先はそのまま残す。スクリプトが参照しているクラス名や要素の親子関係も動作の一部として扱う。見た目の改善で動作が壊れたら、改善ではなく事故になる。境界は次のとおり。
- スクリプトの中にある表示用の文字列(エラー文、完了文など)は文言として直してよい。条件、処理、構造は変えない
- 可視ラベルや aria-*、<label> の追加など、読みやすさと支援技術のための補強はしてよい。既存の属性は消さない
- 入力欄や操作要素の順序は変えない(タブ順や、エラー時にフォーカスが移る先が変わるため)
- 直すのにスクリプトの変更が要る見た目の問題(選択中の行が分からない、など)は直さず、報告に回す
- 既存の不具合がCSSだけで直るなら(開いたメニューを閉じられない、など)直してよい。直したことを報告に書く
- 見た目と関係のない不具合を見つけたら、触らずに報告の「ユーザーの判断が必要なこと」に書く
今の技術のまま直す。 Tailwindならユーティリティと設定ファイルで、CSS Modulesならそのファイルで、素のCSSならそのCSSで。新しいライブラリやフォントファイルの追加は、提案して了承を得てから。外部から何かを読み込む指定(CDN、Webフォント)を新たに足さない。
既存の決定を尊重する。 ブランドカラー、ロゴ、既存のデザイントークンやコンポーネントライブラリがあれば、それが出発点。上書きではなく、一貫して使われるように整える。
必要な分だけ直す。 すでに良い画面は作り直さない。変更量は診断結果で決める(後述)。
外部ツールに頼らない。 画像生成、動画作成、ブラウザ自動操作を、成果物づくりにも検証にも必須にしない。視覚要素はCSS、SVG、文字組みで作る。画面を表示して確かめる手段がすでに手元にある場合は、検証に使ってよい。ない場合はコードを読んで確かめ、表示して確かめられなかった点を報告に書く。同梱のスクリプト(後述)も同じ扱いで、実行できる環境では使い、できない環境では手作業の手順で行う。実写写真が本当に必要な箇所は、サイズと内容を指定した枠を残して報告に書く。
運用中サイトには負荷をかけない。 読み込みは1ページにつき1回にとどめ、取得した内容を手元で読み返す。全ページを巡回しない。

入力に応じた進め方

渡されたもの	やること
コード(ファイル・リポジトリ)	読んで診断し、了承後に直接編集する
スクリーンショットのみ	画像から診断し、方向性と具体的な修正指示(値つき)を出す。コードをもらえれば編集する
URLのみ	ページを取得できる手段があればHTML/CSSを読んで診断する。取得できなければ、スクリーンショットかコードを頼む。運用中サイトは直接編集できないので、上書き用CSSと修正指示として渡す
複数ページ・サイト全体	「複数ページの進め方」に従い、共通層とページ固有層に分けて進める
新規に画面を作る依頼	このスキルの対象外だが、「方向性」と「診断カタログ」は初期値を避ける指針として使える

手順

1. 把握する

編集前に次を確認する。コードや文言から読み取れることは質問しない。

何の製品で、誰が、どんな場面で使うか
この画面の役割(申し込ませる、情報を一覧させる、作業させる、など)
技術構成と、スタイルがどこで定義されているか(トークン、テーマ設定、共通コンポーネント)
対象範囲(1画面か、複数ページか)
スクリプトがどの id・クラス・属性に依存しているか(後で壊さないため)

製品が何なのか本当に分からない場合だけ、1つ質問する。

2. 診断する

「診断カタログ」に照らして問題を洗い出す。各項目に場所(ファイルと行、またはどの部分か)と重さをつける。

高:一目で初期値や定型のままだと分かる、または使いにくさに直結する
中:全体の質感を下げている
低:気づく人は少ないが、直せば締まる

読みやすさと操作の基準(手順5・7)を満たしていない箇所は、本文や操作要素なら高、補助文や注記なら中を目安にする。

診断から全体の判定を1つ選ぶ。これが作業量を決める。

判定	目安	対応
調整	高が0〜1件。骨格は良い	該当箇所だけ直す。方向性は変えない
改修	高が複数。構造は使える	方向性を決め、全パスを実施
再構成	階層や構成そのものが崩れている	方向性を決め、レイアウトから組み直す。機能は維持

「調整」と判定したら、それ以上を勧めない。良い画面を壊すのが、このスキルの最悪の失敗になる。すでに決断が入っている画面(色に根拠があり、主役が立っていて、値が体系に乗っている)は、好みが違っても直す対象ではない。値の種類が目安より多くても、役割ごとに一貫して使われていれば体系に乗っていると見なす。

「調整」でも、読みやすさと操作の基準(コントラスト、フォーカス表示、押せる大きさ)に届いていない箇所は直す。ただし、画面の印象が変わらない最小の変更にとどめる。

3. 方向性を決める

「改修」「再構成」の場合に行う。製品から導き、どの製品にも当てはまる方向性は出さない。次の5点を各1〜2行で書く。

人格:この製品が人だったらどんな話し方をするか(例:「几帳面な経理担当。静かで正確」)
主役:画面で最初に目が行くべき1点。それ以外は主役を立てるために引く
色:基調となる色と、アクセント1色。基調は製品と利用場面から選ぶ(白、色味のある白、濃色、色の面のどれもありうる。初期値の白と黒が残っているのと、選んだ結果が白なのは別)。アクセントをどこで使い、どこで使わないか
文字:書体、太さの使い分け、大きさの段階。日本語がある画面は和文書体と行間を先に決める
決め手:この製品らしさを担う具体的な細部を1つ。製品の中にある物(扱う品物、使う道具、業界の帳票や記号、利用者の言葉)から探す。例:見出しを極端に大きく組む、区画を色の面で塗り分ける、製品が扱う物の形を図として1つ置く、数字だけ等幅にする。例は幅を示すためのもので、選択肢ではない

色と決め手は、最初に浮かんだ案で決めない。次の順で選ぶ。

製品の中にある物(扱う品物、道具、場所、帳票、記号)を3つ挙げる
それぞれから、基調・アクセント・決め手の案を1組ずつ作る。3案は、アクセントの色相か、基調の明るさ(白い地、濃い地、色の面)のどちらかが互いに違うようにする。似た案が並んだら、物を選び直す
利用場面(誰が、どこで、どのくらいの時間見るか)に最も合う1案を選ぶ。選ばなかった2案は、理由と一緒に1行ずつ診断に残す

最初の案が「暖色がかった白の地に、朱や赤のアクセント」になったときは、特に疑う。このスキルで直した画面が最も寄りやすい形で、どの製品にもそれらしい理由を後から付けられる。

アクセントと主ボタンの関係も、ここで決めて書く。主役が操作でないとき(指標、見出しなど)は、主ボタンにアクセントを使うのか、別の強い色(濃い無彩色など)にするのかを方向性の「色」に書く。状態を表す印にアクセントを兼用するかどうかも同じく書く。

方向性に迷ったら、製品の利用場面に戻る。業務で毎日8時間見る管理画面と、一度だけ訪れる告知ページでは、正解が違う。

主役の決め方:その画面を開いた人が最初に知りたいこと、または最初にすることを主役にする。作業画面なら「今すぐ対応が要るもの」(件数、期限)、フォームなら入力の列そのもの(送信ボタンは列の終点として立てる)。条件が揃うまで押せないボタンは、押せるようになってから主役になればよい
アクセント1色の数え方:同じ色相の濃淡(ホバー用の濃い色、選択中を示す淡い色)は1色に数える。明るいアクセント(黄など)は文字や境界に使えないので、濃い派生色を用意する
状態を表す色(成功、危険、警告、進行中など)はアクセントとは別の役割として持ってよい。ただし彩度を抑え、面を塗るより小さな印や文字で示す。色だけに頼らず、形や文言でも区別する
書体:フォントを追加できないときは、端末に入っている書体で組む(例:"Hiragino Sans", "Yu Gothic UI", "Noto Sans JP", system-ui, sans-serif)。数字を揃えたいときは font-variant-numeric: tabular-nums か、端末の等幅書体(ui-monospace, Menlo, Consolas, monospace)を数字にだけ使う

4. 見せて、確認を取る

編集の前に、診断・判定・方向性をまとめて見せ、「この方向で進めてよいか」を聞く。ここで軌道修正できることが、やり直しの手間を一番減らす。

次の場合は確認を省いてそのまま進める。

ユーザーが「任せる」「そのまま直して」と言っている
判定が「調整」で、変更が小さい
ユーザーが不在の実行(その場合は選んだ方向性を報告の冒頭に書く)

5. 基盤を先に整える

個別の要素を触る前に、値の体系を1か所に定義する。その場しのぎの値を1つずつ直しても、また崩れるため。

余白:4か8を基準にした段階(例:4, 8, 12, 16, 24, 32, 48, 64, 96)
文字:大きさ5〜7段階と、対応する行間。太さは2〜3種類まで
色:役割で名付ける(背景、面、罫線、本文、補助文、アクセント、危険、成功)。色名で名付けない
角丸・影・罫線:それぞれ1〜3種類

定義場所は既存の仕組みに従う(Tailwindの設定、CSSカスタムプロパティ、テーマファイル)。既存のトークンがあれば、それを直して使う。

色を決めたら、その場でコントラスト比を計算して確かめる(scripts/contrast.py を実行できるなら、それで計算する)。本文と背景は4.5:1以上、補助文(薄い灰色の注記、プレースホルダ以外の説明文)も4.5:1以上、大きな文字と操作部品の境界は3:1以上。アクセント色の上に白文字を置くボタンも対象になる。見た目の印象で決めず、数値で決める。

3:1が要る境界は、枠線だけがその部品の手がかりになっているもの(入力欄、枠線だけのボタン)。区切りの罫線やカードの縁は装飾なので対象外
無効状態の部品は基準の対象外。ただし、何が書いてあるかは読める濃さにする
プレースホルダ(入力例)も、読ませたい内容なら4.5:1以上にする

6. パスごとに直す

次の順で、1パスずつ進める。順番には理由がある。構造が決まらないうちに細部を磨くと、やり直しになる。

構成と階層:情報の順序、まとまり、主役の確立。不要な要素を削る
余白:基盤の段階に乗せる。関係の近いものは近く、遠いものは遠く
文字:大きさ・太さ・行間・行長。見出しと本文の差をはっきりさせる
色:役割どおりに割り当てる。アクセントは、方向性で使うと決めた場所にだけ
部品:ボタン、入力欄、カード、表、ナビの形と一貫性
文言:見出し、ボタン、説明、空状態、エラー文
状態:ホバー、フォーカス、無効、読み込み中、空、エラー
細部と動き:アイコン、罫線、影、遷移。動きは意味のある箇所に短く

判定が「調整」なら、該当するパスだけ行う。各パスの終わりに、何を変えたかを1〜2行で残す。

構成を組み替えるとき(パス1)は、要素を消したり入れ子を変えたりする前に、その要素をスクリプトが参照していないかを確かめる。操作できる要素(リンク、ボタン、入力欄、タブ、開閉する部品)は数を減らさない。削るのは装飾と、根拠のない文言だけ。

7. 検証する

直した後、次を確かめる。実際に表示できる環境があれば見て確認し、なければコードを読んで確認する。

薄目で見る:細部をぼかして眺めたとき、主役が最初に目に入るか
幅:スマホ幅(約375px)と広い画面の両方で崩れないか。横スクロールが出ないか
読みやすさ:手順5で計算したコントラスト比が、実際に使われている組み合わせすべてで保たれているか
操作:キーボードのフォーカスが見えるか。押せる要素は44px四方程度あるか(指で操作する画面の目安。マウスで使う密な作業画面では32px以上を下限にし、タッチ端末でだけ44pxに広げてもよい)
動き:prefers-reduced-motion で動きを止められるか
ダークモード:もともとあれば、そちらも直っているか
機能:触っていないはずの動作が変わっていないか。修正前後で id・name・リンク先・スクリプトが同じかを突き合わせる(scripts/check_parity.py)。ビルドやテストがあれば実行する
外部の読み込み:CDNやWebフォントなどの指定を新たに足していないか(scripts/check_external.py)
動的な表示:モーダル、タブ、ホバー、エラー表示など、開いた直後には見えない状態(「動的な表示の確認」を参照)
新たな量産品になっていないか:「置き換えの罠」を見直す

8. 報告して、見せる

短くまとめる。

判定と、選んだ方向性(1〜2行)
変えたこと(パス単位で要点のみ)
あえて変えなかったことと理由
ユーザーの判断が必要なこと(実写写真の枠、根拠を確認できなかった数字や実績、フォント追加の提案、見た目と関係のない不具合など)
検証の結果(コントラスト比は計算した値を書く)と、確認できなかったこと(表示して確かめられなかった状態や幅など)。スクリプトで確かめたのか、読んで確かめたのかも書く

あわせて、前後を見比べる手段を渡す(「結果の見せ方」を参照)。単体のHTMLにできる画面なら前後比較ページ、ビルドが必要な構成なら差分と見比べる手順になる。

複数ページの進め方

対象が複数ページのときは、1ページずつ磨かない。ページごとに直すと、ページの数だけ別々の体系ができる。詳しい手順と出力例は references/multi-page.md にある。対象が2ページ以上なら、作業前に読む。

要点は次のとおり。

修正を2層に分ける。
- サイト共通層:色・文字・余白の体系と、部品(ボタン、入力欄、カード、表、ナビ)の見た目。全ページに一度に効く
- ページ固有層:そのページの構成、主役、文言
代表ページを3〜5枚選んで読む。 型の違うもの(一覧、詳細、フォーム、トップなど)を選ぶ。同じ型のページを何枚読んでも得るものは少ない。全ページを巡回しない
棚卸しをする。 描画後のDOMやCSSから、次の2つを数える
- 値の棚卸し:使われている色、文字サイズ、余白、角丸、影の種類と出現数(CSSが手元にあれば scripts/inventory.py で数えられる)
- 部品の棚卸し:複数ページに繰り返し現れる部品と、その見た目のばらつき
対応表を作る。 古い値を新しい体系のどれに寄せるか(例:13px, 14px, 15px → 14px)。これが共通層の中身になる
棚卸しの結果は診断の根拠として示す。 「色が多い」ではなく「灰色が11種類、うち7種類は1〜2か所でしか使われていない」と書く
判定は層ごとに出す。 共通層は「改修」でも、ページ固有層は「調整」ということがある

出力を分ける

複数ページの成果物は、次の2つを分けて出す。混ぜると、どれが全体に効く変更でどれが1ページだけの変更かが分からなくなる。

共通層のCSS:1ファイル。トークン(カスタムプロパティ)と部品の見た目。これだけで全ページの質感が揃う
ページ固有の変更一覧:ページごとに、構成・主役・文言の変更を列挙する。マークアップの変更を伴うものはここに入る

コードを持っている場合の注意

上書きCSS(後から読み込んで既存の見た目を打ち消すCSS)は、確認用であって本番の修正ではない。方向性の確認と前後比較には便利だが、そのまま本番に入れると、元の定義と打ち消しが二重に残る。

本番の修正は、値が定義されている場所に入れる:Tailwindの設定、テーマファイル、トークンのCSS、共通コンポーネント
Tailwindのユーティリティクラスや、CSS Modules・CSS-in-JSが自動生成するクラス名(.css-1x2y3z、.Button_root__a1B2c など)は、外からセレクタで狙うと壊れやすい。ビルドのたびに名前が変わるうえ、同じユーティリティが別の意味で使われている箇所まで巻き込む
上書きCSSを書くときは、要素名、role や aria-* などの属性、意味のあるクラス名を手がかりにする。それで狙えない部品は、上書きで無理をせず「コンポーネント側で直す項目」として一覧に回す

コードがない場合(URLのみ)は上書きCSSが成果物になる。その場合も、壊れやすいセレクタに頼った箇所は報告に書く。

動的な表示の確認

モーダル、タブ、ドロップダウン、ホバー、入力エラーなどは、ページを開いただけでは見えない。前後を別々のページとして開いて比べると、こうした状態を再現し直す必要があり、見落としが出る。次の2つの方法を使う。手順の詳細は references/verify-and-show.md にある。

同じ画面の上でCSSだけを入れ替える。 assets/toggle-snippet.js は、共通層のCSSをその場でオン・オフするボタンを画面に足す。モーダルを開いたまま、タブを切り替えたまま、入力エラーを出したまま前後を比べられる。開発環境にはスクリプトとして貼り、手を入れられないサイトでは assets/bookmarklet-builder.html でブックマークレットにして使う。入れ替えられるのはCSSで表現できる変更(主に共通層)だけで、マークアップの変更は対象外
状態一覧ページを作る。 assets/state-gallery-template.html をもとに、部品を全状態(通常、ホバー、フォーカス、無効、読み込み中、空、エラー)で1ページに並べる。操作して状態を作らなくても、抜けている状態と揃っていない状態が一目で分かる。共通層のCSSを直したら、まずこのページで確かめる

どちらも、ユーザーが自分のブラウザで開いて使うためのもの。スキルの実行にブラウザ自動操作は要らない。1画面だけを直すときは、状態一覧ページを作らなくてよい(実際の画面で状態を出して確かめれば足りる)。

結果の見せ方

修正が終わったら、単体のHTMLにできる画面は前後を切り替えられる1ファイル完結のページで見せる。差分の説明を読むより、同じ位置で入れ替わるのを見るほうが早い。

assets/compare-template.html に修正前と修正後のHTMLを埋め込んで作る。外部の読み込みがないので、会話内の表示でも、保存してローカルで開いても同じように動く。scripts/build_compare.py を実行できるなら、それで組み立てる。手で埋め込む方法は、ファイル冒頭のコメントと references/verify-and-show.md にある
埋め込むHTMLは、CSSとスクリプトをインラインにした単体で開ける形にする
ビルドが必要な構成(React、Vue、Svelte など)で単体のHTMLにできない場合は、比較ページを必須にしない。次のように見せる
- 成果物は実際の差分と、開発サーバーで前後を見比べる手順にする。修正前は git の直前の状態で表示できる(コミット前なら変更を一時的に退避する。別の作業ツリーに修正前を出せば、前後を並べて開ける)
- 切り替えスニペットを使えるのは、修正が1枚のCSS(トークンや共通のスタイルシート)で表せる場合だけ。コンポーネントの中のクラスやマークアップを書き換えた修正は切り替えられない
- 比較ページのために、画面を静的なHTMLとして手で書き起こさない。実際の描画と一致する保証がなく、見せたものと直したものが別物になる。描画後のHTMLとCSSを保存できる手段があるときだけ、それを埋め込む
- どの方法で見せたか、表示して確かめられなかった点は何かを報告に書く
複数ページの場合は、切り替えスニペットを入れた状態で代表ページを見てもらう。比較ページを作るなら代表1〜2ページに絞る
修正前の状態は、編集を始める前に控えておく(後から比較ページを作れるように)

見本を求められたら(「どんなふうに変わるのか見たい」など)、同梱の assets/example-compare.html を表示する。告知ページを題材にした実際の修正例で、比較ページと同じ形式になっている。

同梱のスクリプト

数える、計算する、突き合わせるといった作業は、scripts/ のスクリプトに任せられる。判断(診断、判定、方向性、文言)は任せない。

スクリプト	すること	使う場面
`contrast.py`	文字色と背景色のコントラスト比を計算する	手順5で色を決めたとき、手順7
`check_parity.py`	修正前後のHTMLを突き合わせ、`id`・`name`・リンク先・操作要素の数と順序・スクリプトの差分を調べる	手順7の「機能」
`check_external.py`	外部からの読み込みがないかを調べる	手順7、比較ページを作る前
`inventory.py`	CSSに書かれた色・文字サイズ・余白・角丸・影の種類を数える	複数ページの棚卸し。1画面でも診断の根拠になる
`build_compare.py`	修正前後のHTMLを埋め込んだ前後比較ページを作る	手順8

python3 scripts/contrast.py "#565e59:#f4f5f2" "#ffffff:#b8321a"
python3 scripts/contrast.py --large "#857d6d:#ffffff"
python3 scripts/check_parity.py before.html after.html
python3 scripts/check_external.py after.html
python3 scripts/inventory.py site.css page.html
python3 scripts/build_compare.py --before before.html --after after.html -o compare.html --title "画面の名前" --verdict 改修

contrast.py は既定で 4.5:1 を基準に判定する。3:1 でよいもの(大きな文字、枠線だけが手がかりの部品の境界)は --large を付けて別に実行する
Python 3.8 以降の標準ライブラリだけで動く。インストールするものはなく、通信もしない。使い方は各ファイルの冒頭と --help にある
実行できる環境では使う。実行できない環境では、各手順に書いてある手作業の方法で行う。 スクリプトがなくても、このスキルの手順はすべて行える。実行環境がないことを理由に検証を省かない
スクリプトが調べるのはソースに書かれた内容で、描画後の実際の見た目ではない。check_parity.py が通っても動作の保証にはならず、inventory.py の数は継承や上書きの結果を反映しない。表示しての確認、または読んでの確認を置き換えるものではない
check_parity.py の「NG」は、消えた id、入れ替わった操作要素の順序、処理に及ぶスクリプトの変更など。スクリプトの文字列でも、セレクタ、イベント名、URL、比較している値、${} の中身が変わればNGになる。意図した変更でなければ直し、意図した変更なら報告に書く。「確認」は、増えたラベルや表示用の文字列だけのスクリプト変更など、見て判断するもの。対象はHTMLなので、コンポーネントのファイル(.tsx、.vue など)は差分を読んで同じ点を突き合わせる
修正前のファイルが要る(check_parity.py、build_compare.py)。編集を始める前に、修正前の状態を控えておく

診断カタログ

兆候そのものより、原因を直す。兆候だけ消しても原因が残れば、別の形で再発する。

色と光

兆候	原因	直し方
紫〜青のグラデーション背景や文字	色を選んでいない	製品に根拠のあるアクセント1色に絞り、面は無彩色にする
光るぼかし、ネオンの影、色つきの発光	装飾で質感を補っている	取り除く。奥行きは余白と罫線、控えめな影で出す
すりガラス風のカードの多用	流行の初期値	背景に意味のある場面だけに残す
色が5色以上あり、どれも同じ強さ	役割が決まっていない	役割ごとに割り当て、アクセントは方向性で決めた場所だけに
純白の背景に純黒の文字、または灰色の薄すぎる文字	初期値のまま	背景と文字の色を方向性から選び直し、コントラストを確保する。選んだ結果が白でも構わない

構成と階層

兆候	原因	直し方
すべてがカードに入っている	まとまりを枠でしか表現していない	余白と罫線で区切り、枠は本当に独立した物だけに
中央寄せの見出し+3列の特徴カード+CTAの繰り返し	定型の流用	内容に合わせて構成を変える。左寄せ、非対称、表、一覧なども使う
すべての要素が同じ大きさ・強さ	主役が決まっていない	主役を1つ決め、他を引く
意味のない数値や実績の帯(「10K+ ユーザー」など)	定型の穴埋め	根拠がなければ削除を提案する。勝手に数字を作らない。管理画面などに出ている指標は実データとして扱い、消さない
画面内に同格の主ボタンが複数	優先順位が決まっていない	主ボタンは1つ、他は副次的な見た目にする

余白

兆候	原因	直し方
13px、22px、37pxなど不揃いな値	体系がない	基盤の段階に乗せる
どこも同じ余白	関係性を表現していない	近いものは詰め、区切りは大きく空ける
端が揃っていない	基準線がない	揃える線を決めて、すべてそこに合わせる
詰め込みすぎ、または間延び	密度を決めていない	利用場面に合わせて密度を選ぶ(作業画面は密、告知は疎)

文字

兆候	原因	直し方
見出しと本文の差が小さい	段階がない	大きさと太さの差をはっきりつける
太字だらけ	強調の乱用	強調は1画面で数か所に絞る
1行が長すぎる	行長を考えていない	欧文は60〜75字、和文は35〜40字程度に収める
和文の行間が狭い、字間が初期値のまま	欧文前提の設定	和文本文の行間は1.7〜1.9程度。見出しは詰める
全部大文字で字間を広げた小ラベルの多用	定型の流用	必要な箇所だけに残す

部品と細部

兆候	原因	直し方
絵文字をアイコンや見出しの飾りに使用	アイコンを選んでいない	既存のアイコンセットに統一するか、なくす。アイコンは線の太さと大きさを揃える
角丸がすべて大きい、または箇所ごとに違う	体系がない	1〜3種類に絞る
すべてに影がついている	奥行きの意味がない	浮いている物(メニュー、ダイアログ)だけに
「New」「AI」などのバッジや丸いラベルの多用	装飾の穴埋め	情報として必要なものだけ残す
ホバーやフォーカスの見た目がない	状態を作っていない	すべての操作要素に状態を定義する
入力欄の名前がプレースホルダにしか書かれていない	見た目の簡潔さを優先している	入力欄の外に、常に見えるラベルを置く。入力例や条件は補足文として添える
すべての要素がふわっと現れる、ホバーで拡大する	動きの乱用	意味のある箇所だけ、150〜250msで短く

文言

兆候	原因	直し方
「革新的な」「次世代の」「シームレスに」「〜を再定義」「Supercharge」「Unlock」	何も言っていない	製品が実際に何をするかを具体的に書く
感嘆符、煽り、過剰な絵文字	熱量で中身を補っている	落ち着いた平叙文にする
「始める」「詳しく見る」ばかりのボタン	行動が具体的でない	押すと何が起きるかを書く(「見積もりを作る」など)。何が起きるかをコードから読み取れないボタンは、名前を変えない
空状態やエラーが定型文のまま	場面を考えていない	何が起きたか、次に何をすればよいかを書く
架空の推薦文、根拠のない数字	穴埋め	作らない。報告で指摘し、ユーザーに実物を求める

文言は方向性の「人格」に合わせる。事実関係(機能、価格、実績)は変えない。変えるのは言い方だけ。画面に書かれていない事実を足さない。画面の別の場所やコードから読み取れる事実(入力の条件、よくある質問に書かれた料金など)を、必要な場所に書き直すのは構わない。

根拠を確かめられない内容(実績の数字、推薦文、「いちばん選ばれています」のような主張、機能の裏づけがない売り文句)は、確認を取れるならユーザーに聞く。確認を省いて進める場合は次のようにし、どちらも報告に書く。

数字の帯、星の評価、飾りのバッジなど、消しても画面の構成と操作が変わらないものは外す
推薦文のように、消すとナビのリンク先や区画がなくなるものは残し、装飾だけを落とす

サイト全体(複数ページのとき)

兆候	原因	直し方
同じ役割のボタンがページごとに違う見た目	部品が共有されていない、または都度上書きされている	共通層で1つに定義し、ページ側の上書きを外す
ほぼ同じ色・文字サイズが何種類もある	体系がなく、その場で値を書いている	棚卸しして対応表を作り、段階に寄せる
ページごとに見出しの大きさや余白の取り方が違う	ページ単位で作られている	見出しの段階とページの枠組みを共通層で決める

置き換えの罠

定型を消そうとして、別の量産品にしてしまう失敗がある。次の形になっていたら、方向性に立ち返る。

クリーム色の背景に明朝・セリフ体の見出し、黒い角丸ボタン、という「上品な定番」
何でも白黒にして罫線だけ、という「無難なミニマル」
太い黒枠と原色、という「わざとらしい個性」
紫を別の一色のグラデーションに替えただけ
色味のある白の背景に、アクセント1色、等幅の数字、細い罫線、小さな角丸、という「このスキルの定番」。この文書の例をそのまま組み合わせるとこうなる。直した画面がこの形になっていたら、製品から導いたのか、例を写したのかを確かめる

確かめ方は、自問だけにしない。決め手を取り除いた残り(地の色、アクセントの色相、角丸、罫線、数字の組み方)を書き出し、上の定番の5点と照らす。4点以上が重なり、決め手だけが製品固有なら、骨格は定番のままと判断する。その場合は手順3に戻り、選ばなかった案のどれかで地かアクセントを組み直す。

どれも、製品から導かれていれば正解になりうる。問題は見た目ではなく、その製品である理由がないこと。「この見た目を別の製品にそのまま使えるか」と自問し、使えるなら決め手が足りない。

診断の出力形式

手順4で見せるときは、この形にまとめる。長くしない。作り手についての推測は書かない。

## 診断
判定:改修

高
- ヒーロー背景が紫〜青のグラデーション(Hero.tsx 12行目)
- 主ボタンが同格で3つ並んでいる(Hero.tsx 30〜41行目)
中
- 余白が不揃い(14px、22px、36pxが混在)
- 特徴カードの見出しがすべて絵文字つき
低
- フォーカス表示がない

## 方向性
人格:町の自転車屋の店主。気さくで、要点から話す
主役:修理の予約ボタンと、今日の空き時間
色:白を基調に、濃い紺の面をヘッダーと予約欄に大きく使う。アクセントは反射材の黄1色。予約ボタンと空き枠の印だけに使う
文字:端末のゴシック体。見出しは800で大きく、本文400
決め手:空き時間を、整備票の升目のような表で見せる
選ばなかった案:タイヤのゴムの黒を地にする案(屋外の明るい場所でスマホから見るには暗い)/工具箱の赤をアクセントにする案(「受付終了」の表示と紛れる)

この方向で進めてよいですか?

この例は書き方の見本で、選ぶ内容の見本ではない。色や決め手を例から借りない。

確認を省いて進める場合(ユーザー不在、任された場合)は、末尾の質問を書かない。判定が「調整」のときは、方向性の欄に「変更しない」と書き、画面から読み取った既存の決定を5点で記す(何を保ったかの記録になる)。

複数ページのときは、冒頭に棚卸しの結果を置き、判定を層ごとに書く。形式は references/multi-page.md にある。

design-polish

Was ist design-polish?

In Ihrer bevorzugten KI fragen

Dokumentation