![見出し画像](https://assets.st-note.com/production/uploads/images/163180680/rectangle_large_type_2_f12352df5096a7a915a88d2900964a16.png?width=1200)
エンジニアとデザイナーをつなげる!Figmaでつくる実装しやすいデザインデータ
こんにちは!プロダクトデザイナーの吉林です!
最近、新サービスのデザインシステムを0から立ち上げる機会があったのですが、実装しやすいデザインデータを目指して、自分なりにやってよかったな〜ということを備忘録的にまとめてみました。
Figmaの機能を使った具体的な内容や、初歩的なことも含みますが…少しでも参考になれば幸いです🙇♀️
1. 変数はFigmaのバリアブル機能で管理し、コードと一致させる
これは実装しやすいデザインデータを目指すにあたって、特にやってよかったことの一つです!
カラー、余白、タイポグラフィの値をバリアブル機能で変数として登録し、「Figmaで使用している変数」と「コードで使用している変数」が同じになるように管理していました。
![](https://assets.st-note.com/img/1732522375-6tSLOxQ8Y3q91KbXFU0aBkrf.png?width=1200)
💡参考URL:「Figmaでのバリアブルに関するガイド」
このように一致させることで、Figma上で実際にコードで使用する変数を確認可能になります。CSSを記述する際にカラーコードや数値から逆算して変数を探す手間が減るので、実装時にかなり便利です。
![](https://assets.st-note.com/img/1732228645-jmPC3aSfx87Kk0vdTGolEY4R.png?width=1200)
また、タイポグラフィについてはFigmaのText Styles機能を使い、変数をまとめて管理していました。Text Stylesで変数を一括管理するため運用が楽になるほか、デザイン時も変数を抜け漏れなく設定できます。
![](https://assets.st-note.com/img/1732510007-BofUatk7GgevyTnRquFx2hCJ.png?width=1200)
2. カラーは2種類のトークンで管理する
カラー管理は手探りで迷ったところでしたが、
個人的には Primitive token と Semantic token の2つに分ける方法が運用しやすく、エンジニアさんともコミュニケーションがとりやすかったと思います。
Primitive token はカラーコード(#〜〜)のみを持つデータとして、 Semantic token は Primitive token に文脈や意味を追加したデータと定義します。この構成はAdobe社のデザイントークンを参考にしました🙇♀️
![](https://assets.st-note.com/img/1731646566-WfzHu5LQPhEBUR4cXysDSY1v.png)
![](https://assets.st-note.com/img/1731646594-GLgMAPqf6Z9BSu5TtYxe3hbo.png)
具体的な構成ですが、例えば本文カラーを #30221F とした場合、
primitive token では gray-900として #30221F を呼び出し
semantic tokenでは text-main として gray-900 の色を呼び出します。
![](https://assets.st-note.com/img/1732510904-wneP2yL7Q0JEa4GTYDZmXjl1.png?width=1200)
2つに分けて管理したことで、カラー変更の際もメンテナンスしやすくなり、エンジニアさんとも意思疎通が取りやすくなりました。
3. CSSを意識したデザインデータを作る
これは意識されている方がほとんどかもしれませんが、デザインデータが実際のCSS設計と同じになるように注意していました。
というのもFigmaにはCSSの自動出力の機能があり、CSSを想定した部品の組み方をしている場合、自動出力結果と実際に記述するコードをかなり近づけることができます。
![](https://assets.st-note.com/img/1731647579-mEL14D9PqYIvyoGSkBgRMebW.png?width=1200)
display: flex;を使用する部分には必ずAuto Layoutを使用する、前述のバリアブル(変数)の設定漏れがないようにするなど、使い回しが多い部品などは特に慎重に作成していました。
これにより、自動出力結果とCSSの値をかなり近づけることができました。エンジニアさんからも「自動出力のCSSをコピペしたら、ほとんど実装できた」など嬉しい声もいただけました🎉
4. Figmaのコメント機能を使う
私の場合は、エンジニアさんへデザインデータを共有する時に「何か気になるところがあったらコメントをお願いします!」とお伝えし、いつでも気軽にコメントをいただけるようにお願いしていました。
コメントのスレッドがそのまま議論の履歴としてFigmaに残りますし、実装しながら気になった部分を直接フィードバックいただけるので、かなり便利な機能だと思います。
ちなみに、プラグインを使用すればVS Code上でFigmaファイルにコメントすることも可能です!
エンジニアさんにとっても、チャットツールを開いて連絡する手間などが省けるので、非同期コミュニケーションをする上でかなりおすすめです。
5. ケース漏れが出ないように気をつける
これは当たり前の話ですが、自分への戒めも込めて気をつけたいと思った部分です。
例えばよくある事象だと「この場合のデザインってどうなるの?」などです。ケース漏れがたくさん起こるとエンジニアからデザイナーへ質問するコミュニケーションが頻発してしまうので、特にコンポーネントのstateなどは漏れが出ないように注意していました。
個人的に、優秀なデザイナーさんはこのラリーがかなり少ないような気がします。私も頑張りたい所存です…🍵
6. デザインデータの作成ルールを可視化する
これはチームにデザイナーが複数いる場合に気をつけたい部分かなと思います。「人によってファイルの作成方法が違う」といった事象を避けれるように工夫していました。
私の場合はデザイナーが2名だったこともあり口頭で意思疎通が取れていましたが、今後メンバーが増えたときのために「デザインガイド」を作成し、ファイル作成時の注意点などをまとめていました。
![](https://assets.st-note.com/img/1731650564-xbwom01kTuPXZaQy4vKAtCcl.png?width=1200)
文章にすることで、なんとなく決まっていたルールを可視化できたので、2人チームでも作成してよかったように思えます!
終わりに
わかりやすいデザインデータについてはまだまだ試行錯誤中なので、また良い方法があったら共有できればと思います。
最後まで読んでいただきありがとうございました!