協業しやすいデザインデータの作り方#

エンジニアが実装しやすいデザインデータを提供するには、画面間のルール整備が重要です。
ルールを決めると生産性や保守性が向上し、細かいやり取りや修正の手間が減ります。
ぜひお手元で実践してみてください。

対象者#

「エンジニアが実装しやすいデザインデータ」について詳しく知りたい UI デザイナー

1. レイヤーをわかりやすくする#

なぜ？#

エンジニアは Figma などのデザインツールからスタイル情報を取得する際に、Class 名の参考にレイヤー名を考案したり、何のグルーピングなのかを把握する参考として見ている方がいます。そのため、レイヤー名が整理されていないと、意図が伝わらずエンジニアが混乱してしまいます。

実践することで、エンジニアがデザイン構造を把握しやすくなり、作業時の迷いや確認時間が短縮されます。

どうする？#

• 不要になったレイヤーやグループは削除する
• 一定のまとまりでレイヤーに「なんのグループであるか」が把握できる名称をつける
• エンジニアとの共通言語にしやすいため、慣れていれば英語名をつける

2. 余白を統一#

なぜ？#

デザインごとにバラバラなマージンやパディングを設定すると、開発側で都度調整が必要になり、レイアウトの統一感も崩れます。

実践することで、プロダクトデザインのクオリティはもちろん、エンジニアの書くべきコードもスマートになり、プロダクト全体の保守性向上につながります。

どうする？#

• デザインシステムのスペーシングルール（例：8px, 16px, 24px）を守る
• Auto Layout を活用し、マージンやパディングを適切に設定
• 手動で微調整せず、コンポーネント間の余白は規定の値を使用

3. アイコンを統一#

なぜ？#

独自のアイコンを使うと、開発側でアイコンの管理が複雑になり、余計な実装が必要になります。

実践することで、毎回大量のアイコンを Figma から export する...などの手間が減ります。

どうする？#

• 特別な理由がある場合を除き、デザインシステムで用意された MUI アイコンを優先的に使う
• 任意のアイコンを自由に選択することは避ける（「特定のアイコンがない」等）
• サイズと余白を統一し、手調整によりアイコン間のバランスを崩さない

4. コンポーネント化#

なぜ？#

デザインごとに個別のパーツを作ると、開発側で再利用できず、実装コストが増加します。ゼロから実装しなければいけないことに加えて、似たような多くの機能をずっと保守し続けなくてはならず、メンテナンス負荷も上がります。

実践することで、エンジニアは開発するコンポーネント数を減らして、ふるまいの実装やコード品質の担保に時間を使えるようになります。

どうする？#

• できるだけ少なく、シンプルで複雑でないバリエーションに収められるようデザインする
• 新規コンポーネントを作る際は、「なぜ、それが必要なのか？」を合理的に説明できるようにする
• 既存コンポーネントは容易に解除せず、コードと連携されたコンポーネントを活用する

5. デザイントークンを適用#

なぜ？#

エンジニアはデザインの色・フォント・サイズをコード上のデザイントークン（変数）として管理・再利用できるように開発しています。トークンと一致しないデザインを作ることで、パターンがどんどん増えてしまい開発の負担になります。

実践することで、「ここの背景色は primaryMain のスタイルを使えば良い！」といったようにスタイル実装の戸惑いや手間が減ります。

どうする？#

• 色はデザイントークンの定義（例：primaryMain / #005EF3）を適用
• フォントサイズ、行間、文字間隔はデザインシステムの基準に従う
• 原則、独自のカラーコードやフォントサイズを指定せず、システムにあるものを使う

6. テキストの管理#

なぜ？#

エンジニアはコード側でテキストを動的に管理するため、デザイン上のダミーテキストが実際の UI と大きく異なると、実装後に考慮すべき点が発覚することがあります。

実践することで、「改行できるのは3行で、それ以降は省略できるように実装しよう」といったように意思決定がスムーズに行えます。

どうする？#

• 実際のテキストに近い内容を使用し、「長さ」「改行位置」「可読性」を確認
• 長い文章が入る可能性がある場合は、改行や折り返しのルールを明記

7. UI Stack 洗い出し#

なぜ？#

UI はさまざまな状態を持っています。ログイン時、エラー時、コンテンツが空の時、コンテンツが充足した時...。それぞれのパターンの洗い出しが漏れていると、エンジニアと追加でコミュニケーションが発生するケースが増えます。

実践することで、「この状態はどうなりますか？」のような細かい会話が減り、エンジニアが実装に集中できます。

どうする？#

• UI Stack を参考に、最低限「理想の状態」「空の状態」「エラー状態」「わずかなコンテンツ」「読み込み中」を洗い出す
• コンポーネントの細部にこだわる前に、エンジニアと連携しパターンの抜けもれを早めに気付けるようにする

8. レスポンシブ対応#

なぜ？#

UI はさまざまなサイズの端末でレンダリングされます。特定の画面サイズのデザインだけでは、開発側でスマホ対応の細かな仕様を補う必要があり、実装以外の工数が増えます。

実践することで、「この UI の変化は何をきっかけに起こしたらいいんだろう...」といったように、実装を始めてから検討事項が増えることを減らせます。

どうする？#

• 少なくともデザインシステムで規定された break-point のデザインフレームを展開し、振る舞いを確認する
• デザインの変化がどの画面幅で起こるのか、break-point で明確に指示する（例：gridSystem の md 以降はこちらでお願いします！）
• Figma プラグイン『Responsive Designer』を活用して Turtle の break-point を効率的に展開できます。
• 画像なども画面幅が広がった時の振る舞いを明示する（例：アスペクト比を 3:4 に固定したまま拡大する。画像のアスペクト比が異なる場合は、余白が見えないように拡大してほしいです）

9. 設計意図を明記する#

なぜ？#

仕様は議論していく中で変化していきますが、エンジニアは最新の仕様を知ることができず混乱することがあります。

実践することで、実装する時に最新のデザインに迷わずたどり着くことができます。

どうする？#

• 確定した仕様はコメントの中ではなく、アノテーション機能で残すなどして区別し、最新仕様がわかる工夫をする
• コンポーネントの解除やスタイルをカスタマイズする際は、意図を明示して、余分なコミュニケーションを減らせるようにする
• 実装しない画面や検討中のものは別のページにはける...など、エンジニアが実装時に迷わない工夫をする

10. 実装可能か確認する#

なぜ？#

UI の見た目は美しくても、実装の仕組みを知らずにデザインすることで、エンジニアにとって中長期の保守がしにくくなってしまうことがあります。実装可能かわからない状態で、審美性を突き詰めてもかけた時間が無駄になってしまいます。

どうする？#

• 画面に必要な機能が揃った段階で「審美性」だけではなく、「実現性」をレビューしてもらう
• 実現性のレビューが完了した後に、デザインのブラッシュアップをする
• 実装に自信がないデザイナーほど、デザイン作業中からこまめにエンジニアとコミュニケーションをとるようにする

まとめ#

項目	理由
レイヤーをわかりやすくする	デザインから負担なく情報を取得するため
余白を統一	一貫性とスタイルの調整コストを増やさないため
アイコンを統一	開発側のアイコン管理をシンプルにする
コンポーネント化	再利用性を高め、実装工数を削減
デザイントークンを適用	デザインとコードの一貫性を維持
テキストの管理	文章の長さや改行位置における戸惑いを減らす
UI Stack 洗い出し	UI のさまざまな状態の実装における戸惑いを減らす
レスポンシブ対応	マルチデバイスの対応で戸惑いを減らす
設計意図を明記する	カスタマイズの仕様意図を明確にする
実装可能か確認する	成果物を確実に実現するため

これらのルールを守ることで、エンジニアとスムーズに協業し、開発負担を最小限に抑えながら、ユーザーにとって学習コストの少ないデザインを提供することができます。