白紙から始めると時間がかかります。だから、できあいのスタイルファイルをプロジェクトに放り込んで、AI エージェントに任せたくなります。実際、作業はすぐに進み出します。ただ、自分のプロダクトに何が必要かを決める前に、別のプロダクトの前提までこっそりコードに入り込んでしまいます。
awesome-design-md は、白紙の状態から抜け出すのに役立ちます。よく知られたプロダクトやブランドをもとにした DESIGN.md を集めたもので、どれも視覚テーマ、色の役割、タイポグラフィ、コンポーネント、レイアウト、奥行き、レスポンシブな挙動、ガードレールをまとめています。
リポジトリでは、ファイルをプロジェクトにコピーしてエージェントに組ませる使い方が紹介されています。私はその一歩手前で止めます。コピーしたファイルは調査資料として扱い、それをもとにプロジェクト用の新しいデザインシステムを書いてから、エージェントに実装を頼みます。
そのまま使うと何が起きるか
参考の DESIGN.md は、よその会社、よその読者、よそのプロダクトとコンテンツのために書かれています。フォントはライセンスが必要かもしれません。開発者ツールに合うダークなインターフェースも、読み物のアプリに持ってくると違和感が出ます。専門家向けダッシュボードの詰まったコントロールは、シンプルなオンボーディングには役に立ちません。
ファイルをそのままエージェントに渡せば、そうした前提も丸ごと渡すことになります。仕上がりはきれいに一貫していても、プロダクトには合っていない。たいていは、見慣れたブランドに別の文言を貼りつけたような見た目になります。
このコレクションが役立つ場面
「ミニマルにして」より、ずっと具体的な言葉が手に入ります。Linear、Vercel、Notion、Stripe がどうやって階層をつくっているかを見て、その個性が本当はどこから来ているのかを考えられます。書体なのか、間隔なのか、色なのか、罫線なのか、画像なのか、インタラクションなのか。
ひとつの参考を丸ごと使うことは、まずありません。ある参考は記事のリズムに、別の参考は密度の高いコントロールに役立ち、モーションはまた別のところに探しにいくかもしれません。どの参考にも、そこにある理由が必要です。理由もなく見た目をいくつか混ぜても、ぼやけた見た目がひとつできるだけです。
この段階で欲しいのは、試してみる価値のある判断の短いリストです。真似するブランドを探しているわけではありません。
プロダクトから考える
DESIGN.md に手をつける前に、デザインが仕えるべきことを書き出します。
- 誰が使うのか。
- 何を終えようとしているのか。
- マーケティングページ、アプリケーション、ドキュメント、視覚体験のどれなのか。
- 実在し、すでに使えるコンテンツは何か。
- 端末、アクセシビリティ、技術面で考慮すべき制約は何か。
- どんなインターフェースにはしたくないか。
こうしておくと、参考資料がいつの間にかプロダクト戦略にすり替わるのを防げます。美しいダッシュボードを見ても、自分のプロダクトにそもそもダッシュボードが要るのかは分かりません。
見た目より、判断を借りる
コレクションの DESIGN.md は、どれも使いやすい構成になっています。読むときに探しているのは、別のプロジェクトにも持っていける判断です。
- 視覚的なテーマと、目指している雰囲気。
- 16 進数の羅列ではなく、意味を持つ色の役割。
- タイポグラフィの階層と行の長さ。
- 間隔、グリッド、密度、余白。
- 通常、ホバー、フォーカス、無効、読み込み中、エラー時のコンポーネントの挙動。
- デスクトップ版を縮めるのではなく、画面サイズごとにレイアウトが実際にどう変わるか。
- すること、しないことの明確なルール。
そのまま使える値もいくつかはありますが、大半は置き換えが必要です。「紫を使う」はシステムの説明になっていません。「アクセントカラーは主要な操作だけに使い、飾りには使わない」なら説明になっています。
プロジェクト用の DESIGN.md を書く
借りてきたファイルは、実際のプロジェクトのために書いたものに置き換えます。私が使っている骨組みはこれです。
# Design System: [Project]
## Product context
- Primary users
- Main task
- Platform and usage environment
- Content and technical constraints
## Creative north star
A short description of the visual idea and why it fits the product.
## Foundations
### Color
- Semantic roles and accessible values
### Typography
- Families, weights, hierarchy, line height, and reading measure
### Layout and spacing
- Grid, containers, spacing scale, density, and breakpoints
## Components
- Structure, variants, states, and interaction rules
## Motion
- Purpose, duration, easing, interruption, and reduced-motion behavior
## Responsive behavior
- What reflows, collapses, scrolls, or disappears
## Accessibility
- Focus, contrast, keyboard order, touch targets, and semantics
## Code mapping
- CSS variables, framework tokens, and shared component locations
## Do and don't
- Decisions the agent must preserve
- Common patterns that do not belong in this project
ファイルには、プロジェクトで実際に使っているフォント、トークン、ブレークポイント、コンポーネント、コードの慣習を書きます。コードベースにすでにトークンの層があるなら、DESIGN.md からはそこを指すようにします。正解の置き場所を二つにしてはいけません。
V2SPACE では「ミニマルなポートフォリオを真似する」とは書きませんでした。白い地に文字が主役のページ、16px の IBM Plex Sans、構造を示すレール、狭めの本文カラム、二つのウェイト、控えめなホバー。そう具体的に決めています。カード、グラデーション、影、飾りの数字は使わないとも書きました。どれもサイトの目的と中身から出てきたもので、特定の参考から持ってきたものではありません。
まず一つの画面で試す
新しい DESIGN.md は、まず代表的な画面ひとつで試します。弱いルールをあぶり出せるだけの実際のコンテンツが必要です。長いタイトル、補足の文章、操作、いくつか繰り返す項目、インタラクションの状態、それに狭い画面幅。
そのうえで、実際に表示されたものを見ます。目を細めて細部をぼかし、階層がまだ読み取れるかを確かめます。関連する要素が自然にまとまっているか、長いラベルが折り返すか、キーボードのフォーカスが見えるか、タッチ領域が十分な大きさかも確認します。モバイルでは、ただ縮小されるのではなく、レイアウトがきちんと組み替わってほしいところです。
その画面が持ちこたえられなければ、ほかをつくる前にシステムを直します。そうしないと、同じ悪いルールが十ページに広がって、十回直すはめになります。
エージェントの作業範囲を明確にする
エージェントに実装を頼むのは、ここまで済んでからです。依頼には、対象の画面、実際のコンテンツ、既存のコンポーネント、扱うべき状態、結果の確かめ方を書きます。
DESIGN.md は見た目についての約束です。AGENTS.md はリポジトリでの作業の仕方を説明します。プロダクト要件は、何がなければならないかを決めます。それぞれ、ほかの二つが扱わないことを受け持っています。
この境界が決まっていれば、エージェントは画面ごとに新しい視覚言語を発明することなく、細かい判断を自分でできます。流行っているけれどプロダクトに合わないパターンを断れるだけの文脈も持てます。
使い続けられる文書にする
プロジェクトのデザイン上の判断が変われば、DESIGN.md も変えるべきです。スクリーンショットを撮るたびに作り直すことはしませんし、凍結したムードボードとして扱うこともしません。
実装をきちんと縛れるだけの具体性は必要ですが、人が最後まで読める短さも保ちたいところです。あるルールがなぜあるのか、プロジェクトの誰も説明できないなら、エージェントに理解できるとも思えません。
それでも awesome-design-md は使い続けています。白紙の状態から抜け出させてくれるからです。ただ、選んだファイルを実装の指示書としては扱いません。そのプロジェクトに最初からあるべきだったデザインシステムを書くための材料にしています。