【実務・中級編】Figmaコンポーネントとバリアントの使い分け!保守性を爆上げする設計ルール – UI/UX・デザインツール活用バイブル

Figmaコンポーネント設計の「聖域」:破綻しないスケーラブルなUIシステム構築術

現場でコードを叩くエンジニアなら一度は経験したはずだ。デザイナーから渡されたFigmaファイルを開いた瞬間、レイヤーパネルが「Frame 1234」の墓場と化し、コンポーネントを一つ変えるたびにデザイン全体が雪崩のように崩壊するあの絶望を。

UI/UXを「描く」のではなく「設計」する。これができなければ、大規模なプロダクトは数ヶ月で技術的負債の塊になる。今日は、Figmaを単なるデザインツールではなく、「コードと同期するUIアーキテクチャ」へと昇華させるための、極限の設計ルールを伝授する。

—

1. 「バリアント」と「インスタンス」の境界線を見極める

初心者は何でもかんでもバリアント(Variant)で解決しようとする。これが間違いの元だ。

Variantを使うべき時

  • 状態の変化(State): ホバー、クリック、非活性、フォーカスなど、純粋なUIの「状態」遷移。
  • 論理的なバリエーション: 成功、エラー、警告といった、システム的に定義されたフラグ。

Component Property (Boolean/Instance Swap) を使うべき時

  • 構成要素の差し替え: アイコンの有無、ラベルの切り替え、右スロットへの別コンポーネントの挿入。

鉄則: 「バリアント」は複雑な分岐を生む。迷ったら「Booleanプロパティ」でレイヤーの表示非表示を制御する方が、エンジニアのコード(`props`)との親和性は圧倒的に高い。

—

2. インスタントスワップ(Instance Swap)の魔法

大規模案件で最も恩恵を受けるのが「Instance Swap Property」だ。これを使えば、ボタンのアイコンを一つ一つ差し替える苦行から解放される。

神テクニック:
1. アイコンコンポーネントを全て「Icon/」という命名規則でまとめる。
2. 親コンポーネントで「Instance Swap」プロパティを設定する際、「Preferred Values(推奨値)」を必ず指定しておく。
3. これで、デザイナーはコンポーネントを選択した瞬間に、関連するアイコンだけをサイドバーから選べるようになる。UIの探索コストがゼロになる瞬間だ。

—

3. 開発スピードを加速させる「指先」の最適化

Figmaの操作が遅いエンジニアは、マウスを使いすぎている。以下のショートカットは呼吸するように叩き込め。

  • `Shift + I`: コンポーネント検索(インスタンススワップ時も有効)
  • `Option + Command + B`: コンポーネント解除(最終手段だが、プロトタイプ作成時の微調整に必須)
  • `Command + /`: プラグイン検索。マウスに触れるのは負けだ。

必須の「神プラグイン」

  • [Props Combo](https://www.figma.com/community/plugin/1234567890): プロパティの組み合わせを全展開する。バリアントの網羅性チェックに必須。
  • [Token Studio for Figma](https://tokens.studio/): デザインシステムをJSONとして管理し、GitHubと同期する。これを通さずデザインシステムを語るな。

—

4. チーム開発を救う「JSON」によるトークン管理

デザインシステムをコードに落とし込む際、FigmaのバリアントとコードのPropsを一致させるための「設定ファイル」を介在させる。

以下は、デザインシステムをReact/TypeScriptへ変換するための、最小構成のトークン定義(JSON形式)だ。

{
“button”: {
“padding”: { “value”: “{space.md}”, “type”: “spacing” },
“variant”: {
“primary”: { “background”: “{color.blue.500}”, “text”: “{color.white}” },
“secondary”: { “background”: “{color.gray.200}”, “text”: “{color.black}” }
},
“borderRadius”: { “value”: “8px”, “type”: “borderRadius” }
}
// FigmaのVariant名と、このキーを一致させることで
// 開発時に自動補完が効くエコシステムを構築する
}

—

5. チーム内での「暗黙の了解」を排除する命名規則

デザイナーが勝手に決めたレイヤー名は、エンジニアにとってはただのノイズだ。以下のルールを強制しろ。

  • `Slot/Base/Component`: 階層構造は3段階まで。
  • `Action/Primary/Default`: 「状態」と「意味」を分離する。
  • `_ (アンダースコア)`: 非公開コンポーネント(ライブラリで公開したくないもの)には必ず付ける。これだけでチームのライブラリパネルが見違えるほどスッキリする。

—

最後に:UIは「対話」である

優れたUI/UXエンジニアは、ツールを「描画ツール」ではなく「コミュニケーションツール」として捉えている。

Figma上でコンポーネントを組む時、「これは将来のエンジニアにどう見えるか?」と自問自答してほしい。あなたが今組んだバリアントのプロパティは、将来のコードの`type`定義と同じはずだ。

デザインシステムは、一度作って終わりではない。日々の開発プロセスの中で育て、コードと対話しながら最適化し続ける「生き物」だ。今日から、その意識でFigmaを触ってみてくれ。君のプロダクトは、もっと洗練されるはずだ。

タイトルとURLをコピーしました