フロントエンドデザイン
新しいUIの制作または既存UIの再設計で、対象に固有の美的方向性を定めてから実装する。 利用者が指定したブランド、トーン、技術、アクセシビリティの要件を優先する。
対象へ接地する
着手前に次を特定する。
- 何を扱うプロダクトまたは題材か
- 誰が使うか
- この画面が担う一つの役割は何か
- 既存のブランド、デザインシステム、実装上の制約は何か
不明な項目があっても、変更範囲を大きく左右しない場合は、根拠を示した仮定を一つ置いて進める。 対象の道具、素材、言葉、行動、データから形を導き、一般的なSaaSの見た目を出発点にしない。
実装前に方向性を作る
短いデザイン計画に次を含める。
- 配色：役割を持つ4〜6色と値
- 文字：見出し、本文、必要ならデータ表示の書体とスケール
- 構成：情報の順序と、画面幅が変わったときの関係
- 署名要素：この題材を表す、記憶に残る要素を一つ
署名要素以外は抑制する。 番号、ラベル、罫線、動きは、情報の順序や状態を伝える場合だけ使う。
定型化を検査する
実装前に、計画の各判断へ「別の題材でも同じ選択をするか」と問う。 答えが「はい」なら、題材から導ける選択へ置き換える。
特に次を無意識の既定値として使わない。
- 題材と関係のないグラデーションやアクセント色
- 大きな数値、短いラベル、同形カードを並べるだけのヒーロー
- 実際には順序を持たない内容への
01 / 02 / 03 - 画面全体へ散らした小さなアニメーション
- 名前だけ差し替えた汎用的な見出しやCTA
利用者がこれらを明示した場合は、その指定を優先する。
実装する
- 計画で定めた色と文字をtokenにし、場当たり的な値を増やさない。
- 見出し、本文、操作、補助情報の階層を、サイズ、ウェイト、余白で明示する。
- コピーは利用者が認識できる対象と操作の名前で書く。
- ボタンは結果が分かる動詞にし、操作後の通知でも同じ語を使う。
- エラーは発生箇所の近くで、起きたことと修正方法を示す。
- 空状態には次の行動を一つ示す。
- モバイル幅、キーボードフォーカス、
prefers-reduced-motionを実装の基準に含める。
完成後に批評する
可能なら実際の画面を複数幅で撮影し、次を確認する。
- 最初の画面から対象と役割が分かるか。
- 署名要素は題材に由来し、一つに絞られているか。
- 装飾が情報または操作を邪魔していないか。
- 文字、余白、構成が計画と一致しているか。
- 実在する内容で長文、空状態、エラー状態も成立するか。
- 一つ削ることで意図が明確になる要素はないか。
出典
- [anthropics/skills: frontend-design](https://github.com/anthropics/skills/tree/main/skills/frontend-design)
- Apache License 2.0
- 本文は原文を日本語の制作手順へ再構成した派生文書である。