《綿貫佳祐のFigma思考ラボ｜Vol.8》Figmaのデータ設計に迷わないための2つの指針──コード構造とFigmaの思想をどう扱うか？

はじめに：Figmaデータの作り方に正解はあるのか

Figmaを使ってデザインデータを作成していると「このコンポーネント、どう作ればいいんだろう？」といった悩みが出ることがあります。

同じ見た目を実現するにしても、やり方は一つではありません。

• バリアントか、コンポーネントプロパティか
• スタイルか、バリアブルか

こうした問いに対して「どちらでも実現できるから、どちらでも良い」と考えてしまうことがあります。 確かに、視覚的な結果だけを見ればそうかもしれません。

ただ私は、Figmaデータの作り方を考えるときに意識している指針が2つあります。

1. 極力コードの構造に合わせる
2. Figmaというプロダクトの思想に沿う

この2つは互いに独立していますが、どちらも「なぜそう作るのか」という根拠を与えてくれます。今回はこの2つの指針について、具体例を交えながら掘り下げてみます。

指針1：極力コードの構造に合わせる

なぜコードを参照するのか

Figmaで作ったデザインは、最終的にコードとして実装されます。 このとき、Figmaデータとコードの構造がかけ離れていると、デザイナーとエンジニアの間に余計な翻訳コストが生まれてしまいます。

逆に言えば、Figmaデータがコードの構造を反映していれば、「この状態はブーリアンで制御されている」「このコンポーネントは中身を差し替えられる」という情報が、Figmaを見ただけでエンジニアに伝わります。 言うなれば、デザインとコードが「同じ言語」で書かれている状態です。

この指針を意識する前は、私も視覚的な観点からFigmaデータを設計していました。見た目が正しければそれで良い、という感覚です。

ただ、その作り方では、仕様変更や機能追加があるたびに、Figmaデータとコードの構造が少しずつ乖離していきました。 そしてある時点で、まとめて整理し直さなければならなくなり、まるで年末の大掃除のような苦労でした。

今の考え方に変わってからは、改善のたびにFigmaデータとコードを同期しやすくなりました。構造が対応していると変更の影響範囲もわかりやすく、小さな修正を日々積み重ねていけるので、データが負債化しづらくなっています。

ブーリアンプロパティ：&& 演算子との対応

特定の条件でだけコンポーネントを表示する際、コードではこんな書き方をすることがあります。

{loggedIn && <UserMenu />}

Figmaでこれを表現するとき、推奨しないのは「ログイン済みバリアントと未ログインバリアントを2種類作る」という方法です。 見た目は同じものを作れますが、コードの構造とは一致していないからです。 コードには「2種類のパターン」があるわけではなく、「UserMenuを表示するかどうかの制御するフラグ」があるだけです。

こういった場合には、コードの&&による表示制御と対応する「ブーリアンプロパティ」を使ったほうが良いでしょう。

ブーリアンプロパティは、レイヤーの表示・非表示を制御するためのプロパティです。 trueのときにレイヤーが表示され、falseのときに非表示になります。

コードに合わせて、FigmaでもloggedInに対応するブーリアンプロパティを定義し、UserMenuレイヤーの表示・非表示を切り替える構成の方が自然です。

イマイチな例	良い例
通常時とログイン時で別のバリアントとして定義	ブーリアンプロパティを使い、 1つのコンポーネントとして定義

インスタンススワッププロパティ・スロットプロパティ：コンポーネントの「交換可能な部分」

コンポーネントにアイコンを渡す際、コードではこんな書き方をすることがあります。

<Button icon={<ArrowRightIcon />} label="次へ" />

アイコンという「枠」は決まっていて、中に入るアイコンコンポーネントは呼び出し元が決める、という設計です。

Figmaでこれを表現するとき、アイコンの種類ごとにボタンコンポーネントを別々に作ってしまうと、それもコードと対応しません。

コードに合わせるなら、アイコン部分をインスタンススワッププロパティで定義し「ここには特定のコンポーネントセットから選んだインスタンスが入る」という構造にするほうが適切です。

さらに、前回の記事で取り上げたスロットプロパティも同様の発想と対応します。 スロットプロパティは、インスタンスをデタッチせずにコンポーネント内へ任意のコンテンツを自由に追加・配置できる領域を定義するものです。 コンポーネントに限らずテキストや画像なども入れられる点が、インスタンススワッププロパティとの大きな違いです。

コードでchildrenとして可変な部分を定義するパターンは、Figmaではスロットプロパティに対応します。 差し込む内容が特定コンポーネントに限定されるなら「インスタンススワッププロパティ」、何でも入れたいなら「スロットプロパティ」という使い分けです。

イマイチな例	良い例
アイコンの種類ごとに別のバリアントとして定義	インスタンススワッププロパティを使い、 1つのコンポーネントとして定義

コンポーネントの「状態」はバリアントで

コードでは、コンポーネントの見た目が状態によって変わることがよくあります。

<Button variant="primary" state="hover" />

こういった「状態の列挙」はバリアントを使います。 stateがdefault/hover/pressed/disabledのように決まったセットから選ぶ値であれば、バリアントプロパティとして定義し、コンポーネントセット内に各状態のデザインを用意するのが自然です。

一方で、「表示する / しない」という2値の制御にバリアントを使ってしまうと、コードとの対応がずれます。 その場合は前述の通りブーリアンプロパティを使用しましょう。

Figmaで再現しなくていいもの

「コードの構造に合わせる」と言っても、コードのすべての表現をFigmaで再現する必要はありません。

例えば、コードでは「trueならAを、falseならBを表示する」という制御がよくあります。 しかしFigmaのブーリアンプロパティではこれは実現できません。 このような表示の出し分けの場合、バリアントで対応するほうが自然です。

プロトタイプについても、スクロール連動や要素の固定表示のような挙動は、コードでは標準的でもFigmaで再現しようとすると難しい部分があります。 そういった部分まで無理に合わせようとする必要はありません。

「構造の考え方を参考にする」という意識で、Figmaの機能として対応できる部分を選んで活用するのがちょうど良いと思います。

指針2：Figmaというプロダクトの思想に沿う

「できること」と「好ましいこと」は違う

Figmaには、似たような目的に使える機能が複数あります。 フレームとグループ、バリアブルとスタイル、バリアントとコンポーネントプロパティなど、どちらを使っても見た目の結果が変わらないケースは少なくありません。

「どれを使っても同じなら、どれでも良い」という考え方もできますが、私はFigmaが公式に示している思想を優先することにしています。

理由は単純で、Figmaの今後の方向性はFigma自身が一番よく知っているからです。 公式の思想に沿って作っておけば、将来的な機能追加や変更に対応しやすくなります。

基本の選択：フレームとグループ

Figmaには要素をまとめる手段として、フレームとグループの2つがあります。 どちらでもまとめられるため、グループを使っている方も少なくありません。

ただ、Figmaの設計を見ると、制約、オートレイアウト、コンポーネントはいずれもフレームを前提として動作します。 つまり、複数の要素をまとめる基本単位として「フレーム」を選んでいることは、機能の構成からも読み取れます。

グループを使ったからといって即座に問題が生じる場面は少ないですが、基本的にはフレームを使う前提で考えておくのが、Figmaの思想に沿った選択です。

値の管理：バリアブルとスタイル

Figmaの公式ドキュメントでは、バリアブルとスタイルの使い分けについて以下のように整理されています。

Figma Learn - ヘルプセンター

バリアブルとスタイルの違い Figmaでは、バリアブルにより機能セットを拡張しました。次のような疑問をお持ちの方もおられるでしょう: 「バリアブルとスタイルの違いは?」「この2つの使い分けは?」「ス...

簡単にまとめると、

• バリアブル: 単一の値を格納するもの（色のHEX値、余白の数値、テキストのフォントサイズなど）
• スタイル: 複数のプロパティをまとめたもの（テキストスタイルはフォントファミリー・サイズ・行間などのセット、エフェクトスタイルは複数の影の設定のセットなど）

という整理です。「単一の値か、複数のプロパティのまとめか」が基準になっています。

内容	適切な方法	理由
ブランドカラーのHEX値	バリアブル	単一の値
フォントサイズの数値	バリアブル	単一の値
余白・角丸の数値	バリアブル	単一の値
テキストのフォントファミリー・サイズ・行間のセット	スタイル	複数プロパティのまとめ
ドロップシャドウの設定セット	スタイル	複数プロパティのまとめ

よくある「色にはスタイルを使うかバリアブルを使うか」という問いに対しては、単色の値であればバリアブルが適切、という答えになります。

コンポーネント設計：プロパティの選び方

コンポーネントプロパティにも同様の考え方が当てはまります。

例えば、ボタンのラベルテキストをバリアントで分けてしまうと、ラベルの種類が増えるたびにバリアントが増殖します。 Figmaがテキストプロパティを用意しているのは、「テキストの内容はプロパティとして切り出すべき」というメッセージでもあります。

「Figmaが何のためにこの機能を用意したのか」を出発点に考えると、こうした判断に迷う場面が減ります。

公式ドキュメントを読む習慣

Figmaの機能の使い分けに悩んだとき、私はまず公式のドキュメントやSNSでの発信内容を確認するようにしています。

Figmaは機能を追加するだけでなく、その背景にある設計思想を積極的に発信しています。 「なぜこの機能を追加したのか」「どういった場面で使うべきか」が丁寧に説明されています。

Figma

Figma Blog | Shortcut Welcome to Shortcut, Figma’s blog for telling stories about people, and the priorities, plans, and pivots they discover along the path of bringing new ideas to ...

機能の使い方だけでなく、「なぜそう使うのか」を公式から学ぶことで、個別の判断に迷う場面が減ります。

2つの指針を組み合わせる

「コードの構造に合わせる」と「Figmaの思想に沿う」は、それぞれ独立しているように見えるかもしれませんが、実際はセットです。

例えば、コンポーネントの状態管理を考えるとき、以下のように思考します。

• コードでbooleanとして要素の表示・非表示を制御 → Figmaデータでもバリエーションではなく表示・非表示の制御（コードの構造に合わせる）
• レイヤーの表示・非表示のために設計されているもの → ブーリアンプロパティ（Figmaの思想に沿う）

仮に一致しない場合でも、これだけのことが考えられている場合、適切なドキュメントなども残せるでしょうから、ちょっとやそっとでは負債化しません。

まとめ

Figmaデータの作り方に「これが唯一の正解」というものはありません。 ただ、判断の根拠となる指針を持っておくことで、迷う場面が減り、より一貫したデザインデータを作ることができます。

今回取り上げた2つの指針は、どちらも「なぜそう作るのか」を詳細に言語化できる作り方です。

Figmaデータは、最終的にエンジニアが参照し、コードとして実装されます。 設計の意図が伝わりやすいデータを作ることが、デザイナーとエンジニアの協業をスムーズにする第一歩です。

著者プロフィール

文：綿貫佳祐