SocialDogでデザイナーをしている高橋です。
デザイナーとエンジニアの連携を少しでも効率化するために、Figmaを使う上で工夫しているテクニックを紹介します。
Figmaとコードで使うスタイルを揃える
UIで共通して利用する色やフォントスタイル（タイポグラフィー）は、FigmaのTokens Studioプラグインで一元管理しています。
Tokens Studioで作成した色・フォントスタイル（デザイントークン）は、Figmaのスタイル・バリアブルとして出力したり、JSONファイルとしてGitHubに同期したりできます。
このJSONファイルは開発リポジトリにコミットし、styled-componentsから直接利用できるようにしています。
共通UIコンポーネントは丁寧に作る
エンジニアが共有UIコンポーネントを実装したら、デザイナーもレビューに参加しています。パディングやサイズ感などがFigmaのデザインと合っているかだけでなく、細かい挙動やPropsの定義がデザイナーの想定と揃っているかどうかも確認しています。
共通コンポーネントのパディングとサイズさえあっていれば、そのコンポーネントを使用して実装するUIはデザイナーが確認しなくてもデザイン通りに実装できます。また、Propsの定義もデザイナーが確認しておくことで、デザイナーが考えているコンポーネントの将来的な使用用途に対応できているかも把握できます（色違いはどのように表現される？ボタンのレイアウトはカスタマイズできるのか？など）。
以前は、すべてのPull Requestに対してデザイナーがレビューを行っていました。デザインが正しく実装されているのか逐一確認できるメリットがある一方、Pull Requestのレビュー完了までの時間がかかりすぎていました。
現在、StorybookでUIコンポーネントのストーリーを作成し、デザイナーはそのストーリー上でFigmaと実装を比較します。共通コンポーネント以外の実装については、Pull Request単位では確認していません。これにより、効率性と正確性の両立ができています。
Figmaからコードへの橋渡し
デザインを実装する際、エンジニアにはFigma上で以下のプロパティーを確認するようお願いしています。
- プロパティー（コンポーネントの場合）
- 色の名前
- テキストスタイルの名前
- 余白（パディング、要素間の距離）
- サイズ
一度Figmaの「Dev Mode」を利用することも検討しましたが、エンジニアチームからは特別課題感がないことを共有され見送りました。
今のところ上記のプロパティーを確認してもらうフローだけで、開発面でもデザインの再現性の面でも満足いく仕組みが実現できていると考えています。
まとめ
スタイル定義における自動化や共通UIコンポーネント中心のレビューフローにより、SocialDogではデザインの再現度と品質が底上げされ、作業効率が上がりました。デザイナーとエンジニアの連携は今後も改善していく予定です。
SocialDogではエンジニアを採用中です。
私はもともとエンジニアだったので、デザインの実装についてもとても関心があります。デザインが好きな方、いろいろなチャレンジをしたい方は、ぜひSocialDogでカジュアル面談しましょう！デザインと技術の融合に興味がある方、お待ちしています。
Discussion