デザイン2026

Foundation Design System

Variables、Styles、Components、運用ルールを一つのSource of Truthとして整理し、FigmaからCSS Variables、Tailwind、実装レビューまで接続するデザイン基盤です。

FigmaVariablesComponentsDesign TokensDesign Ops
CHALLENGE課題

画面ごとに色、余白、文字、コンポーネントを増やすだけでは、Figmaと実装の判断が徐々に分かれます。テーマ変更やレビュー時に「どれを使うべきか」を追えるよう、値だけでなく命名、状態、利用ルールまで共有できる基盤が必要でした。

APPROACHアプローチ

設定JSONを正本に、Primitive → Brand / Primary → Semantic → Component の階層を設計しました。Light / Dark、Comfortable / Compact、390 / 768 / 1280の基準、Typography Variables、Paint / Effect / Grid Styles、コンポーネントの状態とライフサイクルまでFigma上で追えるようにしています。

RESULT成果

DTCG JSON、CSS Variables、Tailwind theme、Figma Plugin設定を同じ定義から生成し、11のJSONファイルと38のコンポーネント基盤を検証しました。Figmaを単発の画面集ではなく、再実行できる実装仕様として運用できる状態にしています。

CASE STUDY詳細

Figmaを、再実行できる設計基盤へ

見た目を揃えるだけでなく、デザイナー、実装者、レビュー担当が同じ名前と判断基準で画面を増やせることを重視しました。設定、Figma、コード、品質確認を一つの流れとして設計しています。

Source of Truth

フォント、Primary、Neutral、モード、密度、生成対象を設定JSONへ集約し、同じ入力からFigmaと実装用データを再生成します。

  • 設定変更を局所的な手作業にしない
  • DTCG JSON、CSS Variables、Tailwind themeへ出力
  • Figma Pluginの生成条件も同じ設定から管理

Token Architecture

値、ブランド、UI上の意味、コンポーネント用途を分け、変更の影響範囲と参照元を追える構造にしています。

  • Primitive → Brand / Primary → Semantic → Component
  • 公開コンポーネントではraw colorを直接使用しない
  • Aliasを通じてLight / Darkの差分を吸収

Modes & Styles

色だけでなく、タイポグラフィ、密度、画面幅、影、フォーカス、グリッドを用途に合うFigma資産として分離しました。

  • Light / DarkとComfortable / Compact
  • Typography 400 / 500 / 600 / 700
  • Paint / Effect / Grid Stylesと390 / 768 / 1280

Components & Quality

コンポーネントを作って終わらせず、状態、命名、公開可否、非推奨化、検証まで運用できる単位として管理します。

  • 38 component foundationsをRegistryで管理
  • Draft → Review → Ready → Deprecated
  • Plugin build、TypeScript、生成物、利用禁止条件を検証