はじめに

最近、会社のデザイナーが作ったデザインのUIを作る際に、デザインから開発への連携がスムーズにできなかったことを反省しました。
Figmaでのデザインはこうした方がエンジニアとしては開発しやすい！という所感を紹介させていただこうと思います。

エンジニアだけでなくデザイナーの方にも見ていただけると幸いです。

背景

今回のプロジェクトでは、自分でプロジェクトの進行をしながらフロントエンドの開発の一部を行うというポジションにいました。
プロジェクトの中では元々ベテランのデザイナーさんがデザインを作ってくださっていたのですが、諸事情でそのデザイナーの方が外れて別のデザイナーの方がジョインされて、また外れて違う方がジョインするということを繰り返していました。
自分は見習いフロントエンジニアなので正しいデザインの進め方が分かっていなかったため、デザイナーさんたちのいつも通りの進め方で問題ないだろうと思っていたのですが、色々な壁にぶち当たりました。

Tailwindとプロパティの設定

今回のプロジェクトでは技術選定を始める前からデザインを始めていました。デザインはFigma上で行われており、Figmaの中ではpaddingの大きさをあらかじめ設定しており、原則この中からサイズを指定して作るというルールのもとで進められていました。

デザインが仕上がってきて、エンジニアに共有しながら設計や技術選定を行い、フロントエンドのCSSフレームワークはTailwindを使用することになりました。
いざ、開発を進めているとある課題に気付かされました！

「この変数、Tailwindに存在しないぞ、、、、」

上記の画像内の120pxや150pxなどの値はTailwindにはデフォルトとして存在しない値です。(Tainwind Cheat Sheeet)
それがデザインの中で使用されている箇所がちょこちょこ存在していて、これはデザイナーがあえてこだわりを持ってそう設定しているのか、なんとなくで設定しているのかどっちなんだ？という疑問に陥りました。
こだわりがある数字であるとしたらカスタムのクラスを作るなど対応はできますが、コードを書く上ではできるだけ異分子というか特殊な記載はしたくないというのがエンジニアとしての本音です。

これはいったいどういう意図なのか？Tailwindに存在するものの中で近い値に変更できないか？という会話をするために、すでに別の案件にアサインされているデザイナーを呼び戻してコミュニケーションを取り直すということが発生し、お互いのもったいない時間を取られることになってしまいました。。。。

最初から変数がTailwindに近い形で設定されているのであれば、この会話は発生せずお互いデザイン/開発に費やす時間が増えたのに、なんとも無駄な時間を使ってしまったなと後悔しました。。。。

こういったデザインのインフラというか、デザインを作るための環境を整備するポジションの方がいると効率的な開発が実現できそうです。ただ、このポジションはデザイナーでありながらフロントエンド開発にもある程度精通している必要があるのと、変更の影響範囲をきちんと把握する必要のある難しいポジションになると思います。

まとめ：
デザインを始める前にデザインを作る環境（インフラ）やルール整備をすることで、余計なコミュニケーションを省くことが出来そう！
ただし、そこを整備するためにはデザイン・エンジニア両方にある程度精通している必要がある。

デザインシステム

今回のプロジェクトではデザインシステムを作成しました。共通で利用するスタイルやコンポーネントは原則デザインシステムから使うことで進めていました。

ここでもいざ開発してみると、これどうしようかな？と思う箇所が多々あったのでご紹介させてください！

1.変数が多い

１つのボタンのコンポーネントに対してvariablesが複数設定されていました。サイズはまだしも色などが２、３種類の変数で制御されているので、コード上でスタイルを当てるのが複雑になりました。。。。
Figma上ではさまざまな形でvariablesを設定できますが、コード上ではFigmaほど自由が効かないこともあるので、ここもどうしようかという無駄なコミュニケーションを生じました。。。

2.コンポーネント名がよくわからん！

上記の画像のようにTablesと書いてあるのにパッと見でTableに使用されるコンポーネントなのか？と思ってしまいました。。。エンジニアとしてわかりやすいコンポーネント名に変更して保守性を高めたい！とは思うもののコード上だけ変えてしまうと、後々Figmaとコードでコンポーネント名が一致しないことで、「これはあれに対応するよ」という無駄なコミュニケーションを生じてしまうので、これもデザイナーとコミュニケーションをとる必要がありそうです。

あらかじめエンジニアとデザイナーで共通の変数の命名規則を作った方が良さそうだなと感じました。

3.影響範囲がわからない

Figmaではデザインシステム上のメインコンポーネントを使ってデザインを作成していきます。Figmaの仕様上、コピーされたコンポーネントからメインコンポーネントに戻ることは可能ですが、メインコンポーネントからこれがどこで使用されているかを確認する術はありません。
そのため、デザインシステム上での変更が大きな影響を及ぼすことがあります。

今回のプロジェクトでも大惨事がおきました。。。

上段でFigmaのプロパティがTailwindにあっていないということに開発着手してから気づきました。
それをデザイナーに伝えたところ、デザイナーの方が理解をしてくださり気遣いから、デザインシステムの色をはじめとしたスタイルの設定を全て整理して変数名を全て変更してしまいました。

デザイナーの方は親切で行ってくださりましたが、すでに開発を進める中で突然カラーの名前が変わったのでエンジニアは混乱しました。すでにTailwindのConfigにカラーの定義をしていたのに、そこに存在しないカラーが登場したので、どれを使えばいいかわからなくなりました。

結局、整理されたスタイルを使用するということになり、Configを再度書き直し、使用していたclassNameは全て変更せざるを得ず、無駄な時間がかかることになりました。。。

まとめ：
・デザインシステムを作る上で、コンポーネントのvariantの作り方・変数の命名規則はデザイナーとエンジニアで共通の認識を持つ必要がある。
・Figmaのデザインシステムではコンポーネントがどこで使用されているか把握できないため、影響範囲がわかりづらい。

まとめ

今回、自分の担当したプロジェクトにおけるデザイナーとエンジニアの連携においての失敗談を紹介させていただきました。

これ以外にもデザイン➡︎開発の進め方で改善していくことで生産性を上げたものづくりができると思うので、デザイナーとエンジニアが仲良く暮らせる世界を作れたらと思います。