コンポーネント

コンポーネントは、ボタン・入力欄・カードなど、何度も使う部品です。Figma のコンポーネントと、コードのコンポーネント（React・SwiftUI・Jetpack Compose など）が1対1で対応していると、デザインがそのまま実装に移せます。

コードのコンポーネントは props（外から渡す設定）で見た目や動きを変えます。Figma のバリアントやプロパティの名前と値を、props にそろえるのがこつです。

ホバー・押下・フォーカスは、props ではなく操作で自動的に変わる状態です。デザインでは全部の見た目を決めますが、エンジニアに「この状態を渡す」設定はありません。一方、無効・処理中・エラーはコードから渡す状態です。この違いを知っておくと、バリアントの作り方が実装に近づきます。

部品の状態は、全部の見た目をデザインで決めます。そのうえで、どの状態が操作で自動的に変わるもので、どれがコードから渡すものかを知っておくと、バリアントの作り方が実装に近づきます。

「アイコンあり・なし」「ボタン1つ・2つ」「画像あり・なし」……と全部をバリアントにすると、組み合わせの数がすぐに数十になります。代わりに、外側の部品に中身を入れる場所を作り、小さな部品を組み合わせる方法があります。

どこまでを部品が決め、どこからを使う側に任せるかの線引きが大事です。自由にしすぎると画面ごとに見た目がばらばらになり、固めすぎるとバリアントが増えます。よく使う形はバリアントに、まれな形は組み合わせで、が目安です。

Storybook は、コードのコンポーネントを1つずつ、状態ごとに並べて見られる道具です（Web で広く使われています）。「ストーリー」1つが1つの状態にあたります。デザイナーは Storybook を見て、実装された部品がデザインどおりか、全部の状態がそろっているかを確かめられます。新しい部品をデザインするときも、まず Storybook に似た部品がないかを探すと、作らなくてよい部品に気づけます。

公開されているアイコンのセット（Material Symbols など）を使う場合は、ライセンスと、どの太さ・スタイルを使うかをチームで決めます。独自のアイコンと混ぜるときは、線の太さと枠をそろえます。

部品をどの大きさで分けるかの考え方として、Brad Frost が提唱した Atomic Design がよく知られています。小さな部品（原子）を組み合わせて、大きな部品・画面を作るという考え方です。

段階の名前を厳密に守る必要はありません。大事なのは、Figma のライブラリとコードの部品の分け方と名前をそろえることです。デザインでは1つの部品なのに、コードでは3つの部品の組み合わせ、となっていると、受け渡しのたびに読み替えが必要になります。