以前、Andreas Kutschmann 氏が書いた「Design Token-Based UI Architecture」を読んだことがあります。
最近ふとその内容を思い出したので、あらためて自分の UI 設計の考え方と重ね合わせて整理してみました。
原著では、UI を次の 3 種類のトークンで構築する考え方が紹介されています。
デザイントークンをベースとして、コンポーネントのPropsもトークンで設計する感じです。 例えば、Buttonだとvariantとして"primary"や"secondary"のようなインターフェースにする感じです。
原著の考え方はとても理解しやすいのですが、実際のプロダクト開発で扱いやすい形に落とし込むと、
私は UI を以下の3層構造で整理するのが現実的だと感じています。
UI の「最小単位の値」を定義する層です。
これらは Figma のバリアブルを Single Source of Truth として扱います。
Tokens Studio を使うと、
というワークフローを組むこともできるはずです。（昔作った記憶あるけど忘れました）
デザイントークンを 唯一直接参照する UI コンポーネント層 です。
例：
使用側は生のトークン値に触れず、抽象化された API で UI を構築します。
// OK（抽象化された API を利用）
<Button size="md" variant="primary" />
<Flex gap="sm" bg="primary" />
// NG（トークンの生値を直接使用している）
<Button padding="16px" bg="#0070f3" />
<Flex gap="4px" bg="#0070f3" />"16px" のような生値ではなく、sm / md / lg のような意味単位で扱える内部はトークン、外部は抽象化された API という設計が理想です。
アトミックコンポーネントを組み合わせて構築する、プロダクト固有の UI 層です。
例：
特徴は デザイントークンに直接アクセスしない という点で、これをルールとして強制します。
3 層に分けることで、UI のトークンのデータフローは一方向になります。
Figma → デザイントークン → アトミックコンポーネント → ドメインコンポーネントこの構造により、
というメリットが得られます。
この記事を書こうと思った理由は、個人開発で tailwind + shadcn を使って UI を作っているうちに、
className で直接ユーティリティを大量に書けてしまう環境 によって、
「どのスタイルを使うべきか」という一貫性が少しずつ失われている気がしたためです。
そこで、上記の考え方を試験的に試してます。
-
タグ「フロントエンド」の記事
最近、ヒューマンインターフェース ガイドライン（HIG）という言葉を知りました。 「ヒューマンインターフェイスガイドライン」には、どのAppleプラットフォームでも優れた体験を設計できるようにするためのガイドとベストプラクティスが含まれてい
2026-01-24
主にWeb関連の個人開発をしている際に心がけていることを書きます。 月末に近づくにつれ、AIの利用上限に達してしまうことがあります。 その状況になった時、以下のいずれかの選択肢が私の中では残っています。 課金して利用上限を増やす 無料モデル
個人サイトをリニューアルをしています。 ノート風のデザインを目指して、スタイルを調整していました。 ノートの見た目は、現実にあるノートを再現しようとCSSを書いていました。 現在、以下の画像のようなノートになっています。 ノート風デザインの
2026-01-20