デザインデータでコーダーが困るポイントとは？

Webサイト制作において、デザイナーとコーダーの連携は欠かせません。しかし、デザインデータを受け取ったときに「これはどういう意図なのか？」と悩むことはありませんか？

例えば、以下のような状況に直面したことはないでしょうか？

• デザインデータを開いたら、フォントが未指定でバラバラになっている
• 余白やマージンのルールが統一されておらず、どこを基準にすればいいかわからない
• スマホ版のデザインがなく、レスポンシブ時のレイアウトが不明
• レイヤーが整理されておらず、どの要素がどこに属しているのか把握しにくい
• 画像の書き出し指示がなく、どのフォーマットを使えばよいかわからない

こうした問題が発生すると、コーダーは 「推測しながらコーディングを進める」 という、非常に非効率な作業を強いられます。デザイナーが意図した通りに実装できないこともあり、結果として デザインの再調整や修正作業が増えてしまう ことも。

本記事ではコーダーがデザインデータを受け取った際に困るポイントをピックアップしていきます。

お互いに気持ちよく作業をするためにも、どのようなデザインデータが理想的なのか理解しておきましょう。

デザインとコーディングの間にあるギャップ

デザイナーとコーダーの間には、思考プロセスの違いから生まれる「ギャップ」があります。

• デザイナーの視点：視覚的な美しさやブランドの表現を重視
• コーダーの視点：実装のしやすさや開発の効率性を重視

この違いがあるため、デザインデータに少しでも曖昧な部分があると、コーダーは「どのようにコーディングすればいいのか？」と迷ってしまいます。たとえば、デザイナーは感覚的に「このくらいの余白がちょうどいい」と調整しているかもしれませんが、コーダーにとっては「具体的なpx単位やルール」がないと統一感を持たせるのが難しくなります。

また、デザイナーが作ったデザインがそのまま実装できるとは限りません。ブラウザの仕様やCSSの制約によって、デザイン通りに再現するのが難しいケースもあります。そのため、 デザインデータをコーダーがスムーズに扱えるようにするための工夫が必要 です。

デザインデータでよくある課題

① フォントが未指定・バラバラ問題

フォントの指定が統一されていないデザインデータは、コーダーにとって大きなストレスになります。例えば、以下のようなケースがよく見られます。

• 使用フォントが統一されていない
  見出し・本文・ボタンなど、要素ごとに異なるフォントが使われているが、明確なルールがない。同じ要素なのに違う場所で文字サイズや行間・文字間が異なる。統一性がないと、どのフォントを基準にすべきか迷う。
• デザインデータにフォントの指定がない
  どのフォントを使用しているかが明記されておらず、コーダーが推測しなければならない。デザインツールの環境によってはフォントが自動的に別のフォントに置き換わることもあり、意図が正しく伝わらない可能性がある。
• ウェブフォント or ローカルフォントの指定が不明
  Google FontsやAdobe Fontsなどのウェブフォントを使用するのか、それともローカルフォントを使うのかの指定がない。ウェブフォントの場合は、読み込み方法や代替フォントの指定も考慮する必要がある。

▼ 解決策

• • フォントはデザインデータ内で統一し、必ず仕様書に明記する。
  • Webフォントを使用する場合は、どのサービスのフォントを使用するのか明確に記載する。

② 余白やマージンのルールが不統一

適切な余白やマージンの設定は、デザインの統一感を生む重要な要素です。しかし、以下のような問題が発生すると、コーダーは「どこを基準にすればいいのか？」と悩むことになります。

• 余白がランダムで統一感がない
  同じ要素でも場所によって余白が異なるため、コーダーが基準を決められず、統一するのが難しい。例えば、見出しと本文の間の余白が 24px の場所もあれば 32px になっていると、どちらを正解とするべきか判断に迷う。
• コンポーネントごとに余白の基準が異なる
  ボタンやカードなどのコンポーネント単位で余白の設定がバラバラになっている。これではコーディング時に統一感を持たせるのが難しく、CSSの設計が煩雑になりがち。
• デバイスごとの余白ルールが不明瞭
  スマホ・タブレット・PCで余白の変更が必要なのに、どこをどのように調整するのかが示されていない。結果として、コーダーが推測で調整するしかなくなり、デザイン意図とズレが生じる。

▼ 解決策

• 余白の基準を明確に決め、デザインのスタイルガイドを用意する。
• コンポーネントごとの余白ルールを統一し、デザインデータ上でも一貫性を持たせる。
• レスポンシブ時の余白変化をルール化し、デザインデータ内で説明を付ける。

③ レスポンシブの指示が不足している

WebサイトはPCだけでなく、スマホやタブレットでも適切に表示される必要があります。しかし、レスポンシブ対応の設計が十分にされていないデザインデータでは、コーダーが推測しながら実装しなければならず、手戻りが増える原因になります。

• モバイル・タブレット・PCのデザインが揃っていない
  PC版のデザインしか用意されておらず、スマホやタブレットでどう表示すればよいのかが不明。ブレイクポイントごとのデザインがないと、コーダーがデザイナーの意図を推測して実装しなければならなくなる。
• フォントサイズや行間がどのサイズでどう変わるか不明
  PCでは 18px なのに、スマホでは 16px にするべきなのか？行間（line-height）も適切に調整する必要があるが、その指示がないと見栄えの良いバランスを探るのに時間がかかる。
• ブレイクポイントの指示がなく、推測するしかない
  どの画面幅でレイアウトを変更するべきか指示がないと、コーダーが「一般的にこのあたりかな？」と判断するしかなくなる。しかし、デザイナーの意図するデザインとずれが生じる可能性が高く、修正の手間が増えてしまう。

▼ 解決策

• PC・タブレット・スマホのデザインを揃えて用意する（Figmaならバリアント機能を活用）。
• フォントサイズ・行間・ブレイクポイントを明確にルール化し、デザインガイドに記載する。
• デザインデータ内に「スマホ時はこのレイアウトになる」などの補足説明を加える

④ レイヤー整理されていないカオスなデザインデータ

デザインデータを開いた瞬間、「レイヤーがぐちゃぐちゃで何がどこにあるのか分からない…」という経験はありませんか？
レイヤー管理が適切にされていないと、コーダーは必要な情報を探すのに時間がかかり、作業効率が大幅に低下します。具体的には以下のような問題が発生します。

• 不要なレイヤーが大量に残っている
  • 使用されていないレイヤーや一時的に作成された要素が削除されずに残っている。
  • どれが必要なデータなのか分かりにくい。
• 名前のないレイヤーが多く、探しにくい
  • 「レイヤー 1」「グループ 2」など、デフォルトのままのレイヤー名が並んでいる。
  • どのレイヤーがどの要素に対応しているのか把握しづらい。
• グループ化されておらず、構造がわかりづらい
  • まとまりのある要素がグループ化されていないため、階層構造が把握しづらい。
  • 一つ一つ確認しながらコーディングする必要があり、作業が非効率になる。

▼ 解決策

• 使用しないレイヤーは削除し、整理整頓を徹底する。
• 適切にグループ化し、セクションごとにフォルダ分け する。

⑤ 単位がpxになっていない

Webデザインでは px（ピクセル）が基本ですが、デザインデータによっては em, %, pt など異なる単位が使われていることがあります。

• em や % で指定されており、計算が面倒
  • px に変換する手間が発生し、数値の誤差が出ることも。
  • 余白などに % が使われていると、実装後のレイアウト調整が大変。
• 設計が pt になっている場合がある
  • 印刷用デザインの単位 pt（ポイント） が使われていることがあり、Web用に換算しなければならない。

▼ 解決策

• Web用デザインでは基本的にpxを使用する。
• どうしてもemや%を使う場合は、その根拠や計算方法を明記する。

⑥ デザインに小数点以下の数値がある

デザインデータを開くと、 12.5px や 17.3px などの 小数点以下の数値 が含まれていることがあります。

• 12.5px など、コーディングでそのまま使えない数値
  • CSSでは整数値で指定するのが一般的なので、小数点をどう処理するか迷う。
• 端数のせいで要素のズレが発生する
  • 0.5px のズレが積み重なると、レイアウトが崩れることがある。

▼ 解決策

• 小数点のない整数値でデザインを作成する（例: 12px, 16px）。
• どうしても小数点が必要な場合は、デザインガイドに「四捨五入」「切り上げ」などのルールを記載する。

⑦ 行頭などの位置が揃っていない

Webデザインでは、テキストやボタンの配置が 1px ズレているだけ で視覚的な違和感が生じます。

• ボタンやテキストの揃え方が微妙にずれている
  • デザインデータ上では大きな違いに見えなくても、実装後に気になることが多い。
• 1px ズレているだけで視覚的に違和感が生じる
  • デザイナーの意図と違う配置になり、修正の手間が増える。

▼ 解決策

• 要素の揃え方はデザインツールの「整列機能」で正確に設定する。
• ガイドラインを設け、余白や配置の基準を統一する。

⑧ 文字数などコンテンツ量が増えたときの見え方が考慮されていない

テキスト量が変動することを考慮せずにデザインされていると、実装後にレイアウト崩れが発生します。

• テキストが増えた際の折り返しルールが不明
  • 文章が長くなったとき、どのように折り返せばよいのか不明。
• 固定幅要素に長文が入るとレイアウト崩れ
  • ボタンや見出しなど、想定以上の文字数が入るとデザインが破綻する。

▼ 解決策

• 「テキストの最大文字数」を設定する。
• 長文が入った場合のデザインも用意しておく。

⑨ ホバー時などのパターンが書かれていない

ボタンやリンクのホバー・アクティブ時のデザインがないと、コーダーは「適当に作る」しかなくなります。

• ボタンやリンクのホバー・アクティブ時の状態が不明
• フォーカス時のデザインが考慮されていない

▼ 解決策

• ホバー・アクティブ時のデザインも作成する。
• アクセシビリティを考慮し、フォーカス状態も設定する。

⑩ 同系統のカラーコードが何種も使われている

デザインデータを開いた際に、ほぼ同じ色なのに微妙に異なるカラーコードが複数使われている ことがあります。例えば、背景色が #F4F4F4 の箇所もあれば、ほぼ同じ #F5F5F5 が別の要素に適用されているケースです。

このような 微妙な色の違いが意図的でない場合、コーディング時にどの色を基準にすればいいのか判断が難しくなります。また、CSS内で不要なカラーバリエーションが増えてしまい、メンテナンス性が低下する という問題も発生します。

よくある問題点

• ほぼ同じ色なのに、複数のカラーコードが使われている
• 影の色やボーダー色が、似たような色で統一されていない
• 明確な意図がないのに、各パーツごとに異なるトーンが設定されている

▼ 解決策

• デザインの意図がない限り、可能な限り色を統一する
• スタイルガイドを用意し、主要カラーを明確に定義する（例: primary-color, secondary-color, border-color など）
• FigmaやXDではカラースタイルを設定し、再利用可能な形にする
• デザイナーとコーダーの間で、色のルールをすり合わせる（「このグレーは #F4F4F4 に統一する」など）

こうしたルールを決めることで、コーダーが色の選択に迷うことがなくなり、CSSの管理がシンプルになる ため、保守性の高いコードが実現できます。

⑪ 同セクション内のアイコンの大きさが統一されていない

デザインデータを見たとき、同じセクション内にあるアイコンのサイズがバラバラ になっていることがあります。例えば、

• あるアイコンは 32px で作られているが、別のアイコンは 28px になっている
• 角丸や線の太さが統一されていない
• アイコンの余白が揃っておらず、バランスが悪く見える

このようにアイコンのサイズやバランスが統一されていないと、サイト全体のデザインにまとまりがなくなり、視覚的な違和感 を生じやすくなります。また、コーダー側では、個別にサイズを調整する手間 が発生し、実装コストが増えてしまいます。

▼ 解決策

• すべてのアイコンを同じ枠（例えば 40×40px のボックス）に収めてデザインする
• 線の太さや角丸のルールを統一し、デザインシステムに組み込む
• 余白の基準を明確にし、アイコンごとに余白のバラつきをなくす
• FigmaやXDのコンポーネント機能を活用し、統一したアイコンセットを作成する

特にアイコンは SVGで書き出してCSSでサイズ調整することが多い ため、デザインデータ上で統一されていないと、コーディング時にサイズ調整が必要になり、意図しない表示崩れ が起こるリスクがあります。そのため、デザインの段階でサイズやスタイルを揃えておくことが重要です。

デザイナーとコーダーのスムーズな連携方法

デザインとコーディングの間にギャップがあることは避けられません。しかし、事前に適切な情報共有を行うことで、スムーズな実装が可能になります。デザイナーとコーダーが 円滑に連携するためのポイント は以下の通りです。

コーダーとデザイナーが事前に確認すべきポイント

デザインデータを受け取る前に、以下の点を確認しておくと、実装時のトラブルを減らせます。

1. 使用するフォント・カラースタイルの統一
   • ウェブフォント or ローカルフォントの指定は明確か？
   • 色のルールは統一されているか？（メインカラー・アクセントカラーなど）
2. 余白やマージンのルールの明確化
   • セクション間・ボタン間の余白の基準は統一されているか？
   • ブレイクポイントごとに余白の変化が考慮されているか？
3. レスポンシブ対応の指示
   • スマホ・タブレット・PCでどのようにレイアウトが変化するか？
   • ブレイクポイントの基準（例: 768px, 1024px など）は決まっているか？
4. レイヤー整理の徹底
   • グループ化されているか？
   • レイヤー名は明確に付けられているか？
5. ホバー・アクティブ時のデザイン
   • ボタン・リンクなどのホバー時の見た目が用意されているか？
   • フォーカス状態のデザインが考慮されているか？
6. コンテンツの可変性を考慮
   • 長文が入った場合のデザインは想定されているか？
   • ダミーテキストではなく、実際のテキスト量を想定しているか？

まとめ

最後に、 コーダーに優しいデザインデータとは？ を簡単にまとめます。

コーダーに優しいデザインデータのポイント

フォント・カラースタイル・画像やアイコンのサイズが統一されている
余白・マージンのルールが明確になっている
PC・タブレット・スマホのデザインが揃っている
レイヤー名が整理されていて、グループ化されている
ホバー時・アクティブ時のパターンがデザインに含まれている
テキストの可変性を考慮し、折り返しや最大文字数が想定されている

デザインとコーディングの間にギャップがあるのは仕方ありません。しかし、 事前の共有とルール化を徹底することで、お互いの作業負担を大幅に軽減 できます。

最後に

Web制作において、デザイナーとコーダーは 「敵」ではなく「チーム」 です。
お互いの視点を理解し、 より分かりやすいデザインデータを作成・共有することが、より良いサイト制作につながります。

この記事を参考に、 「コーダーが困らないデザインデータ」 を意識して制作していきましょう！