UIデザインで「ボタンの通常／ホバー／無効／アクティブ」など複数の状態を整然と管理したいとき、Figmaのバリアント機能は非常に強力です。異なる見た目や機能を持つコンポーネントを一つのまとまりとして扱い、コードのプロパティ形式に近づけて整理できるというのが利点です。この記事では、バリアントとは何か、その種類やプロパティとの違い、具体的な使い分け方、命名・階層・プロトタイプへの応用などを通じて、Figmaで状態のUIを効率よく管理する最新情報を詳細に解説します。UIデザイナー、プロダクトデザイナー、フロントエンドエンジニアの方に特に役立つ内容です。
目次
Figma バリアント 使い分け の基本と意義
Figmaバリアントとは、類似するコンポーネントの異なる状態やスタイルを「プロパティ／値」の組み合わせで管理できるコンポーネントセットの形式を指します。たとえば、ボタンコンポーネントにおいて「状態(state): 通常／ホバー／プレスド／無効」「サイズ(size): 小／中／大」「色(color): プライマリ／セカンダリ」などのプロパティと値を設定し、それらの組み合わせでバリアントを作ることで、インスタンスを切り替えるだけで状態を簡単に変更できるようになります。この使い分けを理解することで、設計の一貫性・保守性・拡張性が大きく向上します。
バリアントを使う理由
UIコンポーネントは多くの状態を持ちます。ボタンや入力欄、タブ、モーダルなど、通常・ホバー・クリック・無効などを個別に持っている場合、それぞれを独立したコンポーネントとして管理すると量が膨大になります。バリアントを用いることで、これらを一つのコンポーネントセットにまとめられ、切り替えが簡単です。これにより設計システムが整理され、新しいデザイナーやエンジニアも理解しやすくなります。
プロパティと値の概念
バリアントは「プロパティ(property)」と「値(value)」から構成されます。プロパティとはコンポーネントが持つ可変要素（例：状態、サイズ、色、アイコンの有無など）で、値とはそのプロパティの選択肢（例：ホバー、クリック、無効、デフォルトなど）です。すべてのバリアントは同じプロパティ群を持ち、それぞれ異なる値の組み合わせで作られる必要があります。プロパティと値が揃っていないとユーザーがコンポーネントを切り替える際混乱を招きやすくなります。
バリアントと従来のコンポーネントや状態管理との違い
バリアント以前は、状態ごとに別コンポーネントを作ったり、レイヤーの表示／非表示で状態を管理したりしていましたが、これらにはそれぞれ欠点があります。異なるコンポーネントだと管理が分断され、見つけにくさや更新負荷が増えます。レイヤーの切り替えは設定を理解していないと操作ミスにつながります。バリアントならプロパティを通じて直感的に状態を切り替えられ、かつコードのプロパティ形式にも近いため、開発との連携性も高いという利点があります。
どのようなケースで Figma バリアント を使い分けるべきか
バリアントを使いこなすには「何をバリアントに含め」「何を別に扱うか」の判断が重要です。用途やコンポーネントの規模によって、バリアントを使うべき場面と避けた方がよい場面があります。これを理解することで、複雑になりすぎず、かつ再利用性の高いUI設計が可能になります。
使うべき状況
次のような状況ではバリアントの使用を検討するとよいです。たとえば、同じコンポーネントで複数の「状態(state)」が必要なとき、ボタンの「通常／ホバー／プレスド／無効」や入力欄のフォーカス状態など。サイズの違いがある場合、小・中・大などをプロパティで切り替えるほうが管理がしやすくなります。また、色テーマ（プライマリ／セカンダリなど）がある場合、値として管理するとライブラリが整います。アイコンの有無などオプション要素には Boolean プロパティを使うのが一般的です。
避けるべき状況
バリアントを使うことで逆に管理が複雑になってしまうケースも存在します。たとえば、プロパティの組み合わせパーミュテーションが膨大になると整備やパフォーマンスに負荷がかかります。色テーマと状態とサイズをすべて組み合わせてしまうとバリアントの数が爆発しやすくなります。こうした場合は、入れ子構造のインスタンスを使うか、ベースコンポーネントを別にしてテーマ切り替えを別レイヤーで扱うのがよいです。
インタラクティブコンポーネントとの統合
バリアントは最新機能のインタラクティブコンポーネントと連携できます。プロトタイプモードで「Change to」アクションを使えば、ホバーやクリックなどのトリガーを起点にバリアントを切り替えることができます。こうすることでフレームや画面数を大幅に減らせ、制作効率が高まります。プロトタイプ全体の可視性と流れを整理できるため、ユーザーの操作感のテストや実際の動作確認がしやすくなります。
バリアント、プロパティ、スロットの違いと使い分け
バリアントとプロパティ、スロット（slots）およびインスタンススワップはそれぞれ用途に応じて使い分けが重要です。それぞれの特徴を理解して、最適な設計アプローチを選ぶことで無駄を削減し効率よくデザインを進められます。
バリアントとプロパティの関係
バリアントとは、プロパティと値を組み合わせて状態を管理する方法です。プロパティは可変要素、値はその選択肢という形です。Figmaではプロパティを設定することで、値をサイドバーから切り替えられるようになります。プロパティが複数ある場合はそれらすべて共通で持たせ、各バリアントは一意の値の組み合わせである必要があります。一方で Boolean プロパティ（true／false）で要素の表示／非表示などの切り替えが可能となり、パッケージングが簡便になります。
スロット（Slot）機能との違い
スロット機能は、コンポーネント内に自由に内容を追加・編集・配置可能な領域を設ける機能です。バリアントが「状態やスタイル」の管理に主眼を置くのに対し、スロットは「内容そのものや子要素の差し替え」に柔軟性を持たせたい場合に使います。たとえばモーダル内のテキストやアイコンなどを自由に入れ替えられるようにするとき、スロットを活用します。
インスタンススワップとの使い分け
インスタンススワップは、特定のレイヤーを別のコンポーネントに差し替える機能です。バリアントのプロパティ値としてのスワップや、スロットと併用することで柔軟性を補えます。アイコンの有無や種類を切り替える際はスワップが有効です。バリアントで状態を管理しつつ、内部のアイコンや画像をスワップで差し替えると設計が洗練され、コンポーネントの重複を避けられます。
命名規則と整理のコツ
多くのバリアントを使うとライブラリが複雑になります。名前の付け方や階層構造、コンポーネントセットの整理方法に工夫をしないと、使い手が混乱します。ここでは命名規則や整理構造のベストプラクティスを具体的に解説します。
スラッシュを使った命名構造
Figmaではスラッシュ記法を用いてコンポーネント名をつけることで、プロパティや値を構造的に定義できます。たとえば「Button/Primary/Large/Default」などとすることで、「Button」がコンポーネントセット名、「Primary」「Large」「Default」がそれぞれプロパティ値として扱われます。この方式で命名すると、後からバリアントへ変換する際の自動処理がスムーズになります。
階層とグループ化の整理
ページ／フレーム／レイヤーを用いて、テーマや種類ごとに整理します。コンポーネントセットはページごとにまとめ、「Buttons」「Forms」など用途カテゴリ別に配置すると見つけやすくなります。ライブラリを共有する場合は、命名と階層両方を意識して構造を設計することで、使用者が直感的に目的のバリアントを探し出せるようになります。
各プロパティの説明とドキュメント化
プロパティ名・値には意図を反映したわかりやすい名称を使い、説明を付けることを推奨します。Figmaではバリアントの各値およびコンポーネントセット全体に説明を追加でき、インスペクトパネルで確認可能です。どんな用途か、どの状態で使うものかをドキュメント化することで、チーム内での誤用や混乱を防げます。
プロトタイプでのバリアント活用術
バリアントは静的な状態管理だけでなく、プロトタイピングにおいても非常に役立ちます。「ホバー」「クリック」「トグル」などの操作に応じてバリアントを切り替えることが可能です。これにより画面数や接続数を削減しながらインタラクションのシミュレーションがリアルにすることができます。最新のプロトタイピング機能と組み合わせることで、より効率的な設計プロセスが実現します。
Change to アクションの利用法
プロトタイプモードで「Change to」アクションを使うと、あるバリアントから別のバリアントへトリガーで切り替えできます。たとえば「通常 → ホバー」「ホバー → クリック」など。こうした切り替えを設定することで、各状態を別フレームで用意する必要がなくなり、プロトタイプ制作の非効率が減少します。
状態の記憶と共有
インタラクティブコンポーネントを使うと、ユーザーがある状態のバリアントに操作で切り替えたあと、その状態を別のフレームで再び同じコンポーネントがあれば共有された状態を維持できます。また戻ったときにも最後の状態を記憶させる設定があり、画面遷移を伴うプロトタイプの信頼性を高めることができます。
オーバーライドの扱い方
テキストラベルや色など、バリアント切り替えの際に各インスタンスで異なる内容を持たせたい要素にはオーバーライドが重要です。テキストレイヤーの名前を統一しておくことで、バリアントを切り替えてもテキスト内容が保持されます。これにより、実際のUIテキストを入力し直す手間が省けます。
パフォーマンスとメンテナンスの観点での使い分け
大量のバリアントを持つコンポーネントセットを使っていると、ファイルの読み込み・表示・エクスポートなどが遅くなることがあります。定期的に最適化を行うことで、作業効率を維持できます。また、設計システムが拡大するにつれて、重複や未使用のバリアントが残りやすく、整理しないとスケールしない構造になります。
不要な組み合わせの削除
すべての組み合わせをバリアントで揃える必要はありません。使われない組み合わせはあらかじめ除外しておくことをおすすめします。パーミュテーション数が多くなるほど、管理・ファイルの重量・視認性に悪影響があります。プロパティ値の組み合わせが少ないものから順に整理し、使用頻度が低いものは個別コンポーネントとして扱う選択肢も取れます。
ライブラリ共有時のバージョン管理
共有ライブラリを使っているチームでは、コンポーネントセットやバリアントが変更されたときの影響範囲を把握することが重要です。更新を公開する前に影響ありそうなインスタンスを確認し、テーマやスタイルを壊さないように注意します。スタイルやテーマとバリアントを組み合わせている場合は特に慎重です。
パフォーマンス最適化のポイント
大きなバリアントセットは描画負荷が高くなりがちです。デザイン画面で読み込みが遅くなる，プロトタイプのプレビューに時間がかかるといった問題が発生することがあります。必要のないプロパティを削除したり、使わないバリアントを整理したりして、セットの軽量化を図ることが望ましいです。
実際の活用パターンの例
具体例を通じて、どういう設計構造でどのようにバリアントを使い分けるかを理解すると応用がしやすくなります。以下は典型的なUIコンポーネントのバリアント活用例と設計方法です。
ボタンコンポーネントの構成例
ボタンにはプロパティとして「色(color)」「状態(state)」「サイズ(size)」「アイコンの有無(show icon)」などを設けることができます。色ならプライマリ／セカンダリ、状態ならデフォルト／ホバー／アクティブ／無効など、サイズは小／中／大など。アイコンは Boolean プロパティとして true／false。これらをすべて組み合わせることでボタンコンポーネントのバリアントセットを作りますが、数が多くなり過ぎないように「状態 × 色」「サイズ × アイコン有無」などで整理します。
フォーム入力欄とエラー状態の管理
入力欄では通常／フォーカス／入力済／エラーなどの状態を管理します。プロパティ「状態(state)」を使って切り替えるのが基本です。エラー表示のみ別のプロパティ「has error」を Boolean 値で持たせると、エラーが表示される／消えるを簡単に切り替えられます。これにより見た目の一致と整合性が保てます。
テーマ切り替え（ライトモード／ダークモードなど）
テーマ切り替えを扱う場合、バリアントプロパティに「テーマ(theme)」を設け、「ライト／ダーク」などの値を持たせることができます。ただし、全コンポーネントにテーマプロパティを加えると組み合わせが爆発するため、重要なコンポーネントや見落としの影響が大きいものに限定して適用することが賢明です。必要でなければテーマ別のスタイルを共有ライブラリ側で管理し、それをバリアントに組み込ませる方法もあります。
バリアントの使い分けでよくある失敗とその回避法
バリアントを使いこなす過程で陥りやすい失敗と、それに対する具体的な対処法を知っておくことで、設計が破綻するのを防げます。以下はよくある落とし穴とその回避策です。
プロパティの命名が不統一になる
複数のコンポーネントでプロパティ名や値がばらつくと、インスタンスを切り替えるときに混乱します。たとえば「State」「状態」「ステート」など異なる命名をすると、プロパティが一致せず同じコンポーネントに対しても操作が分かれてしまいます。命名規則を設け、意味のある日本語または英語で統一することが肝要です。
バリアント数が膨らみすぎる
プロパティ値の組み合わせが多くなると、意図しない組み合わせが未使用のまま放置されたり、管理の手間が増えたりします。使用頻度の低い組み合わせを除外する、入れ子のインスタンス構造を活用する、あるいは一部を別コンポーネントとするなど設計を分割することで複雑さを抑制できます。
プロトタイプで挙動が期待通りにならない
「Change to」アクションが期待したトリガーや有効／無効の組み合わせで働かないことがあります。たとえば、ホバーとクリックのトリガーが同じ場合、プロトタイプモードではどちらかが無視されることがあります。異なるトリガーを使い分けたり、プロトタイプに設定されたインタラクションとバリアントのプロパティ値が整合しているか確認することが大切です。
実践のためのワークフロー提案
ここでは、設計プロセスの中でバリアントを取り入れる具体的なワークフローを提案します。目的に応じてフェーズを設けることで、スムーズなUI構築と効率性が得られます。
設計フェーズでの準備
まず、どのコンポーネントにどの状態・スタイルが必要か洗い出します。プロパティ名、値のリストを作成し、組み合わせをスプレッドシートか紙でシミュレーションします。どれだけのバリアントが現実的に必要かを判断し、使用頻度やユーザーインタラクションの観点から絞り込みます。この段階で命名規則や階層構造の方針も決めておくと後が楽になります。
構築フェーズでの実装手順
準備が整ったら、ベースとなるコンポーネントを作成し、その後必要なプロパティを定義します。スラッシュ命名で既存のコンポーネントをバリアント化することも可能です。値の設定とレイアウトを整え、Auto Layout や Boolean プロパティ／インスタンススワップなどを活用して柔軟性を確保します。見た目の微調整とテストもこの段階で行います。
レビューと運用フェーズ
コンポーネントを使うデザイナー・エンジニアが実際に使ってみてフィードバックを集めます。使いにくいプロパティ名や値を修正し、未使用バリアントの削除や重複の統合を行いましょう。バリアントを含むコンポーネントの変更が他インスタンスに及ぼす影響を確認しながら、共有ライブラリを更新します。運用中も定期的な整理を習慣にすると良いです。
まとめ
Figmaバリアントの使い分けは、UIコンポーネントの状態・スタイル・オプションを整理し可視化するための強力な手段です。プロパティと値を適切に設計し、命名規則と階層構造を整えることで保守性と再利用性が飛躍的に向上します。
プロトタイピングとの統合やインタラクティブコンポーネントとの活用により、動的なUI挙動も少数のフレームで表現でき、作業効率が増します。デザインチームや開発チームと連携しながら、設定・レビュー・運用フェーズをしっかり回すことが成功のカギです。
コメント