見出し画像

エンジニアとデザイナーをつなげる!Figmaでつくる実装しやすいデザインデータ

こんにちは!プロダクトデザイナーの吉林です!

最近、新サービスのデザインシステムを0から立ち上げる機会があったのですが、実装しやすいデザインデータを目指して、自分なりにやってよかったな〜ということを備忘録的にまとめてみました。

Figmaの機能を使った具体的な内容や、初歩的なことも含みますが…少しでも参考になれば幸いです🙇‍♀️


1. 変数はFigmaのバリアブル機能で管理し、コードと一致させる

これは実装しやすいデザインデータを目指すにあたって、特にやってよかったことの一つです!

カラー、余白、タイポグラフィの値をバリアブル機能で変数として登録し、「Figmaで使用している変数」と「コードで使用している変数」が同じになるように管理していました。

実際のカラー変数の管理(一部)

💡参考URL:「Figmaでのバリアブルに関するガイド

このように一致させることで、Figma上で実際にコードで使用する変数を確認可能になります。CSSを記述する際にカラーコードや数値から逆算して変数を探す手間が減るので、実装時にかなり便利です。

Figmaのdevモードで設定した変数を確認できます。

また、タイポグラフィについてはFigmaのText Styles機能を使い、変数をまとめて管理していました。Text Stylesで変数を一括管理するため運用が楽になるほか、デザイン時も変数を抜け漏れなく設定できます。

Text Stylesの管理方法。変数をまとめて管理するのに便利です。


2. カラーは2種類のトークンで管理する

カラー管理は手探りで迷ったところでしたが、
個人的には Primitive tokenSemantic token の2つに分ける方法が運用しやすく、エンジニアさんともコミュニケーションがとりやすかったと思います。

Primitive token はカラーコード(#〜〜)のみを持つデータとして、 Semantic token は Primitive token に文脈や意味を追加したデータと定義します。この構成はAdobe社のデザイントークンを参考にしました🙇‍♀️

Primitive token(カラーコードのみを持つデータ)
Semantic token(Primitive token に文脈や意味を追加したデータ)

具体的な構成ですが、例えば本文カラーを #30221F とした場合、
primitive token では gray-900として #30221F を呼び出し
semantic tokenでは text-main として gray-900 の色を呼び出します。

2つに分けて管理したことで、カラー変更の際もメンテナンスしやすくなり、エンジニアさんとも意思疎通が取りやすくなりました。


3. CSSを意識したデザインデータを作る

これは意識されている方がほとんどかもしれませんが、デザインデータが実際のCSS設計と同じになるように注意していました。

というのもFigmaにはCSSの自動出力の機能があり、CSSを想定した部品の組み方をしている場合、自動出力結果と実際に記述するコードをかなり近づけることができます。

Figmaのdevモードの画面。自動的にCSSを出力する。

display: flex;を使用する部分には必ずAuto Layoutを使用する、前述のバリアブル(変数)の設定漏れがないようにするなど、使い回しが多い部品などは特に慎重に作成していました。

これにより、自動出力結果とCSSの値をかなり近づけることができました。エンジニアさんからも「自動出力のCSSをコピペしたら、ほとんど実装できた」など嬉しい声もいただけました🎉


4. Figmaのコメント機能を使う

私の場合は、エンジニアさんへデザインデータを共有する時に「何か気になるところがあったらコメントをお願いします!」とお伝えし、いつでも気軽にコメントをいただけるようにお願いしていました。

コメントのスレッドがそのまま議論の履歴としてFigmaに残りますし、実装しながら気になった部分を直接フィードバックいただけるので、かなり便利な機能だと思います。

ちなみに、プラグインを使用すればVS Code上でFigmaファイルにコメントすることも可能です!

エンジニアさんにとっても、チャットツールを開いて連絡する手間などが省けるので、非同期コミュニケーションをする上でかなりおすすめです。


5.  ケース漏れが出ないように気をつける

これは当たり前の話ですが、自分への戒めも込めて気をつけたいと思った部分です。

例えばよくある事象だと「この場合のデザインってどうなるの?」などです。ケース漏れがたくさん起こるとエンジニアからデザイナーへ質問するコミュニケーションが頻発してしまうので、特にコンポーネントのstateなどは漏れが出ないように注意していました。

個人的に、優秀なデザイナーさんはこのラリーがかなり少ないような気がします。私も頑張りたい所存です…🍵


6. デザインデータの作成ルールを可視化する

これはチームにデザイナーが複数いる場合に気をつけたい部分かなと思います。「人によってファイルの作成方法が違う」といった事象を避けれるように工夫していました。

私の場合はデザイナーが2名だったこともあり口頭で意思疎通が取れていましたが、今後メンバーが増えたときのために「デザインガイド」を作成し、ファイル作成時の注意点などをまとめていました。

デザインガイドの一部

文章にすることで、なんとなく決まっていたルールを可視化できたので、2人チームでも作成してよかったように思えます!

終わりに

わかりやすいデザインデータについてはまだまだ試行錯誤中なので、また良い方法があったら共有できればと思います。

最後まで読んでいただきありがとうございました!

いいなと思ったら応援しよう!