デザインカンプからのコーディングでよくあるトラブルと解決策5選

デザインカンプからのコーディングで起きる文字はみ出し・余白・レスポンシブ崩れなどのトラブルと解決策

「カンプ通りに作ったのに、なぜか崩れる」というご相談、本当に多いんです。

そうなんです。デザインはきれいなのに、文字を入れ替えたら一気に崩れてしまって。

それ、ほとんどが「決まったパターン」で起きています。原因さえ分かれば、ほぼ防げますよ。

それは心強いです。具体的にどんなトラブルが多いのか、教えていただけますか?

この記事の結論

カンプからのコーディングで起きる崩れの多くは「文字量が変わると崩れる」「余白がずれる」「レスポンシブで崩壊する」の3つに集約されます。原因は固定値での実装で、余白は8の倍数で統一し、最初からFlexbox・Grid前提で可変に組めば大半は防げます。

読みたい場所にジャンプ

はじめに

デザインカンプ(完成イメージの設計図)を受け取り、いざコーディングを始めると「カンプ通りに作ったはずなのに崩れる」「余白がどうしてもずれる」という壁にぶつかる方はとても多いです。これは経験の浅い方だけの問題ではなく、ベテランでも進め方を誤れば起きるトラブルです。

なぜ崩れるのか。一番の理由は、カンプが「止まっている1枚の絵」なのに対し、Webサイトは「文字量も画面サイズも変わり続ける動くもの」だからです。家でたとえるなら、完成予想図(パース)はきれいでも、実際に住む人の荷物の量や家族構成に合わせて間取りを調整しないと暮らしにくい、というのに似ています。

私たちが実務で受け取るカンプでも、崩れの原因は毎回ほぼ同じ型に収まります。逆に言えば、その型さえ押さえておけば後戻りはほとんど起きません。

この記事では起きやすいトラブルを5つに絞り、それぞれ「どんな現象か」「なぜ起きるか」「実装でどう解決するか」をセットで解説します。最後に、そもそもトラブルを起こさない着手前の進め方までお伝えします。

トラブル1:コンテンツ量が変わるとデザインが崩れる

コンテンツ量の変化でデザインが崩れる原因とmin-heightや可変レイアウトによるコーディング対策

最も頻繁に、そして事前に防げるのにやってしまいがちなのがこのトラブルです。カンプ上では見出しもボタンの文字もちょうど良い長さで収まっていますが、実際の運用では文字量はいくらでも変わります。

理由は、カンプが「ある1つの文字量」を前提に描かれているからです。たとえば3枚並んだカードのうち1枚だけ説明文が長いと、高さが揃わずガタガタになります。家づくりでいえば、本棚の高さを今ある本にぴったり合わせて作ってしまい、新しい本が増えたら入らなくなるようなものです。

具体的には、次のように「可変前提」の組み方へ切り替えます。

  • 高さはheightの固定値ではなくmin-heightで指定する
  • 横並びのカードはalign-items: stretchで高さを揃える
  • ボタンは文字数が増えても折り返せるよう余白で調整する

カンプの文字はあくまでサンプルだと考え、長くても短くても破綻しないかを必ず確認することが、崩れを防ぐ第一歩です。実務では「想定の倍の文字量を入れても崩れないか」を1度試すだけで、公開後の崩れ報告が大きく減ります。

トラブル2:余白や行間がカンプと微妙にずれる

デザインカンプと実装で余白や行間がずれる原因をline-heightとmarginで比較する図解

「数pxだけど、なんとなくカンプと違う」というずれも定番です。原因の多くは、テキスト周りの余白の捉え方にあります。

デザインツール上では、文字の上下の空きは「1つの余白」に見えます。しかしコーディングでは、文字自体が持つline-height(行の高さ)と、要素の外側のmarginに分かれています。ここを区別せずmarginだけで合わせようとすると、行間ぶんの空きが足されて必ずずれます。

たとえばフォントサイズ16px・line-height: 1.5の見出しは、文字の上下に約4pxずつの余白が内側に生まれています。カンプの計測値が「見出しの上に24px空き」だった場合、その4pxを差し引いてmargin-topは約20pxにする、という考え方です。Photoshopなどの計測値をそのままmarginに入れるのが、典型的なずれの原因です。

解決策は2つあります。1つは、余白の数値を8の倍数(8px・16px・24px…)に統一しておくこと。これだけで設計に一貫性が生まれ、計測ミスも激減します。もう1つは、PerfectPixelなどのツールでカンプを実装画面に重ねて目視確認すること。なお、ブラウザはデザインツールと描画の仕組みが違うため、コンマ数pxのずれは「正常な誤差」です。1px単位の完全一致を狙いすぎず、見た目の整合を優先しましょう。

トラブル3:レスポンシブで一気にレイアウトが崩壊する

レスポンシブでレイアウトが崩れる原因とFlexbox・Gridで可変に組む解決策

PC版は完璧なのに、画面を狭めた途端に総崩れになる。これはカンプの作られ方とコーディングの両方に原因があります。

根本原因は、Webの構造を無視した配置です。要素を座標で「ここに置く」発想で組むと、画面幅が変わった瞬間に居場所を失って崩壊します。たとえるなら、床に直接家具を置いただけの部屋を傾けると全部すべり落ちますが、棚や仕切りで固定してあれば崩れない、という違いです。

解決策は、最初からFlexboxGridといった「要素同士の関係で並べる仕組み」を前提に組むことです。「この2つは横並びで、狭くなったら縦に積む」というルールで配置すれば、画面幅が変わっても自動で整います。あわせて、PC・タブレット・スマホの主要な幅で実際に確認すること。カンプがPC1枚しかない場合は、各幅でどう変化させたいかを着手前に必ずすり合わせておくと、後戻りを防げます。

トラブル4:フォント・色・画像が思った通りに再現できない

フォント・色・画像がデザインカンプ通りに再現できない原因とWebフォントや画像書き出しの確認方法

文字の見た目が違う、色がくすむ、画像がぼやける。細部に見えて、サイトの印象を大きく左右するトラブルです。

フォントが違って見えるのは、そのフォントがWebフォントとして読み込まれていない場合に起きます。閲覧者の端末に入っていないフォントは代替フォントに置き換わるため、Google FontsやAdobe Fontsなどで明示的に読み込む必要があります。色のずれは、カンプ側のカラー設定(CMYKなど印刷向け)をそのまま使うと起きるので、Web用のRGB・カラーコードで指定し直します。

画像のぼやけは、書き出しサイズが原因です。表示領域に対して小さい画像を引き伸ばすとぼやけ、高精細なディスプレイ(Retina等)では特に目立ちます。実寸の2倍程度で書き出したうえで、用途に応じて形式を使い分けます。

  • 写真:JPG
  • ロゴ・アイコン:SVGまたはPNG
  • 容量を抑えたい場合:WebPに変換(表示速度も保てる)

トラブルを未然に防ぐ着手前の確認と進め方

コーディング着手前に可変ルール・8px単位・素材データ・共通パーツを確認するチェックリスト

ここまでのトラブルは、実は着手前のひと手間でほとんど防げます。コーディングを始めてから直すより、始める前に確認するほうが何倍も早く、安く済みます。

確認すべきは主に3点です。1つ目は可変のルール。「文字量が増えたらどう表示したいか」「画面幅が変わったら要素をどう並べ替えるか」を、デザイナーや発注者と事前にすり合わせます。2つ目は単位の統一で、余白が8の倍数で組まれているか、色や文字サイズに一貫性があるかを着手前に点検します。3つ目は素材の受け取りで、Webフォントの指定、画像の書き出しデータ、カラーコードが揃っているかを確認します。

そして、いきなり全ページを組まず、共通パーツ(ボタンや見出し、カード)を先に1つ作って確認する「小さく検証する」進め方が有効です。最初の1パーツで認識のズレを潰しておけば、同じ部品を使う後続ページの事故が連鎖的に防げます。家を建てる前に間取りと素材を施主とすり合わせるのと同じで、最初の合意が仕上がりの質を決めます。

よくある質問

デザインカンプと実装は何pxまでのずれなら許容範囲ですか?

ブラウザとデザインツールは描画の仕組みが違うため、コンマ数px〜1px程度の誤差は正常です。完全一致を狙うより、余白を8の倍数で統一して全体の整合を取るほうが実用的です。明らかに数px以上ずれる場合は、line-heightとmarginの分離を見直してください。

カンプがPC版しかない場合、スマホ表示はどう作ればいいですか?

自己判断で進めず、着手前に「各要素を狭い画面でどう並べ替えたいか」をデザイナーや発注者に確認するのが基本です。確認が取れない場合でも、Flexboxで横並びを縦積みに切り替える前提で組んでおけば、後からの調整が最小限で済みます。

ピクセルパーフェクトは必ず目指すべきですか?

印象を左右する見出しやファーストビューは精度を高めるべきですが、すべてを1px単位で合わせる必要はありません。可変するコンテンツやレスポンシブを考えると、厳密な固定より「どの画面でも破綻しない」ことのほうが重要です。

デザイナーとの連携でトラブルを減らすコツはありますか?

最も効くのは、共通パーツを1つ先に作って早めに認識を合わせることです。あわせて、可変時の挙動・余白の単位・素材の受け渡し方法を着手前に決めておくと、後戻りが大幅に減ります。

崩れの原因は、ほぼ「固定で作っているか」「可変前提で作っているか」の差です。 

なるほど、最初から動くことを前提に組めばいいんですね。

その通りです。着手前に可変ルールと余白の単位だけ揃えておけば、大半は防げます。 

それなら安心して任せられそうです。さっそく相談してみますね。

各種SNSのシェアはこちらから
  • URLをコピーしました!
  • URLをコピーしました!
読みたい場所にジャンプ