「これって実装できるのかな…」「どこまで作り込んだ方がいいんだろう？」と手が止まってしまうこと、ありませんか？
とくにLPを中心に制作していると、サイト特有の“共通部分”や“フッターの扱い”が急に出てきて不安になる方はとても多いです。
この記事では、実装がデザイナーさんでもどこまでデザインすれば安心なのかが自然とわかるように、具体的な判断ポイントをやさしく整理してお伝えします。
1. なぜ「実装を想定したデザイン」が必要なのか
（１）LPとサイトでは“前提”が違う
LP制作をメインにされていると、「ページ全体を一つのキャンバス」として自由にデザインすることに慣れていますよね？
でも、サイト制作になると前提がガラッと変わります。
☘️ LPの前提：
1枚の大きな画像のように、自由度が高い。
☘️ サイトの前提：
複数ページに共通するパーツ（ヘッダー、フッター、ナビゲーション）が存在し、構造が固定されている部分が多い。
この前提の違いを知らないと、サイト案件で「ここだけ変えたい」と思った部分が、実はシステム上の共通パーツだった、という最初のつまずきポイントに遭遇してしまいます。
（２）「共通パーツ」への無意識の変更がズレを生む
デザイナーさんは「ヘッダーは今回だけ特別にこのデザインで…」と思っていても、コーダーから見ると「それは共通パーツだから大きく変えると他のページに影響が出る」というケースがあります。
🟧 デザイナーの視点：
（このページだけの特別な要素）
🟦 コーダーの視点：
（システム全体に関わる共通テンプレート）
このズレが、デザイン修正の無限ループにつながることが多いんです。
（３）コーダー視点とデザイナー視点のズレをなくす
現場では、こんな会話がよくあります。「知らなかっただけで迷惑をかけるつもりはない」という状況がほとんどです。
🟧 デザイナー：
このページだけヘッダーを細くしたいんですけど、大丈夫ですか？
🟦 コーダー（心の中）：
共通ヘッダーのCSSを上書きするのは、バグの元になるから避けたほうがいいと思うんですけど…
🟧 デザイナー：
え、そこ固定なんですか？知らなかった…。
この「知らなかった」という情報不足を解消するために、最初から「ここは共通パーツですか？」と確認するクセをつけることが重要です。
（４）実装を想定するとデザインの自由度が下がる？
多くのデザイナーさんが「実装を意識すると、表現が制限されてしまいそう…」と不安を感じます。
でも実際は逆です。
コーディングの「地雷」、つまり「触ってはいけない共通パーツ」さえ知っておけば、安心して自由にデザインできる範囲が広がるんです。
無駄な修正も減るので、より創造的な部分に時間を割けるようになります。
（５）“実装を想定する”とは、専門知識を覚えることではない
ここで強調したいのは、HTMLやCSSのコードを深く理解する必要はまったくないということです。
どこが共通パーツなのか→ ヘッダー、フッター、ナビゲーションなど。
どこを変えると負担が大きいのか→ フォント、全体幅、基本的なカラースキーム。
必要なのは「判断の軸（基準）」を持つことです。
この“判断の軸”さえ持てれば、コーダーと自然にやり取りできるようになり、デザインとコーディングの両方がスムーズに進みます。
2. “やりすぎデザイン”と“足りないデザイン”
（１）どこまで作り込むべきか迷うのは普通のこと
LP中心でデザインを続けていると、細かな装飾やアニメーションをしっかり作り込む習慣がつきますよね。それは素晴らしいスキルです。
ですが、サイト案件では、逆に作り込みすぎることで実装が複雑化する場面が多く、「どこまで作ればいいの？」と戸惑いがちになります。
この境界線を知ることが、効率的なサイト制作の鍵になります。
（２）コーダーが困る“やりすぎデザイン”
見た目はきれいでも、実装時に再現が難しく、工数が膨らむ原因となるデザインは「使い回しが効かない例外」です。
⚠️コーダーが困る「例外」デザイン
・ボタンごとに微妙に違う角丸やシャドウ（例: Aボタンは角丸3px、Bボタンは4px）。
・同じセクション内で余白の規則がバラバラ（例: 上余白が30pxの後に28pxが来る）。
・1文字単位で位置調整されたテキスト（画像化しないと再現が難しい）。
複雑なグラデーションや描画モードが多用されたパーツ。
デザイナーさんは「ちょっと見栄えを良くしただけ」のつもりでも、コーダーからすると毎回別パターンをコードで作る必要があり、工数が急上昇します。
（３）逆に“足りないデザイン”も問題になる
一方で、コーダーに「解釈で補うしかない」状況を作ってしまうデザインも、後からのズレの原因になります。
⚠️ 完成後のズレを生む「情報不足」デザイン
・ホバー（カーソルを乗せたとき）の指示がない。
・SP（スマホ）時の折り返しや要素の消える想定がない。
・画像なのかCSSで作るのか判断できないパーツ（例: 単色の線やシンプルな円）。
・テキストが最大文字数になったときの「崩れたときの見え方」の想定がない。
これらの情報が欠けていると、完成後に「意図と違った…」というズレが発生しやすくなります。
（４）やりすぎ vs 足りない —— よくあるズレ
「ちょっとした違い」が実装時には大きな負担になることが多いです。
🟧 デザイナー：
このボタン、角丸は3pxの方がかわいいと思って…
🟦 コーダー：
他のボタンは6pxなので、すべて3pxに変えると共通設定を上書きする必要があり、工数が3日分増えてしまって…
🟧 デザイナー：
そこまで影響すると思っていませんでした…
この「影響範囲の認識のズレ」をなくすことが大切です。
（５）境界線は“パーツとして再利用できるかどうか”
コーダーが喜ぶデザインは、実はすごくシンプルです。
👌 再利用できる：
同じボタン、同じ見出し、同じ余白ルールが繰り返し使える。
❌ 再利用できない：
使い回しができない特別仕様が増えるほど工数が急上昇する。
Figmaのコンポーネント機能を使って、ボタンや見出しを「一つ定義すれば、すべてに適用される」形でデザインできれば、コーダーにとって最高のバトン渡しになります。
（６）完璧な個性を目指すより「ルールを揃える」こと
デザインを制限する必要はまったくありません。むしろ、「ルールを揃えること」がデザインの説得力を上げ、コーディングの負担を劇的に下げます。
☘️ ボタンの統一
→ サイズ、角丸、色変化のルール
☘️ 見出しのルール化
→ H1, H2, H3のフォントサイズと余白を固定
☘️ 余白の規則
→ 4pxや8pxの倍数で統一する
これはLPでもすぐに活かせる考え方です。
3. 共通パーツ（ヘッダー・フッター・ナビ）の扱い方
（１）LPには存在しない“共通部分”という概念
LP制作が中心だと、「ページ単位で完結する生活」に慣れているため、サイト案件に登場する“共通パーツ”が意識の外にあることが多いです。
共通パーツ（ヘッダー、フッター、サイドナビなど）は、全ページで同じ形を保つシステム上の大前提があります。
LPのように自由に変えられない部分だということを、理解しておきましょう。
ここが最初に迷いやすい、そしてトラブルになりやすい部分です。
（２）「このページだけ特別に…」はNG!!
サイト制作において、以下のデザインはコーディングの負担が一気に跳ね上がります。
⚠️ 共通パーツへの例外指定
・ヘッダーをページごとに微妙に高さや色を変える。
・フッターの構成を途中から大きく変える（例：このページだけフッター内の企業情報がない）。
・ナビゲーションの順序や項目をページ単位で変える。
デザイナーさんは「見た目のバランスを整えたかっただけ」でも、コーダーから見ると “共通部分のルールを壊す”行為に見えてしまうのです。
（３）よくある会話のすれ違いをなくす
実装を知らなかっただけで、悪気も意図もないのに“困らせてしまう”ケースは本当に多いです。
🟧 デザイナー：
このページだけフッターを短くして余白を減らしたいんですが…
🟦 コーダー：
（共通パーツのCSSを上書きすると、他のページでフッターが崩れるリスクがある…）
このすれ違いを回避するため、共通パーツは「触れないエリア」として認識を切り替えることが重要です。
（４）共通パーツのデザインは“情報整理”と“運用耐性”が価値
ヘッダーやフッターは、実装だけでなく運用にも影響する部分です。
✅ 導線の整理：
サイト全体の主要な導線が迷わず整理されているか。
✅ 運用耐性：
メニュー数が増減してもデザインが崩れないか（例：グローバルナビの最大文字数、最大項目数）。
✅ 情報整理：
フッターの階層構造（会社概要、採用情報など）が論理的で分かりやすいか。
「おしゃれに見せる」よりも “変化しても壊れない”デザインが評価され、あなたのデザイナーとしての強みになります。
（５）LPデザイナーがつまずきやすい「運用」視点
LPでは滅多に考えない、サイトならではの視点があります。
・グローバルナビのメニュー数は最大何項目まで想定するか？
・フッターの著作権表記（コピーライト）が最新の年になっているか？
・ヘッダーに通知やお知らせのアイコンを置く場合、未読時のデザインは必要か？
（６）共通パーツのデザインは“先に相談する”
デザインを始める前に、コーダーにたった一言聞くだけで、デザインの方針が驚くほどクリアになります。
🟧 デザイナー：
共通パーツ（ヘッダー・フッター）について、今回はどこまで自由に変更してOKですか？ 高さや色は全ページ共通で良いでしょうか？
共通部分のルールを把握しておくと、それ以外のコンテンツ部分は自由度が高くなるため、結果としてデザインのストレスが減るのです。
4. 余白・グリッド・改行位置などズレやすいポイント
（１）デザインツールでは“綺麗に見えても”実装では崩れる
FigmaやXDでは、余白や整列がピタッと揃って見えるため、「実装してもこのまま再現されるだろう」と思いがちですよね。
しかし、実際のWebブラウザのコードでは、テキストの量、デバイス差、ブラウザ差、画面幅の可変性が影響し、デザインどおりに見えなくなることがよくあります。
↓↓↓デザインツールとブラウザの違い↓↓↓
☘️ デザインツール：
→ 固定されたキャンバス上の静止画
☘️ ブラウザ：
→ テキストや画像が流動する可変環境
この違いを理解し、「流れても崩れないルール」を作ることが大切です。
（２）余白がそろっていないと実装は複雑になる
LPデザインでは「見た目の調整」として、微妙な違いが生まれやすいです。しかし、コーダーからすると、こうした「微妙な違い」が大きな負担になります。
⚠️ コーダーが困る余白の「例外」
・セクションごとに微妙に違う上下余白（例：40pxのセクションの次に43pxのセクションがある）。
・要素ごとにバラバラの丸め方（ボタンAの角丸が4px、ボタンBの角丸が5px）。
・要素の横幅が統一基準なく決められている。
こうした「微妙な違い」はすべて、「別パターンのCSSを書く必要がある」という負担につながり、工数が膨らみます。
（３）「3pxのズレ」がプロジェクトを遅らせる
🟧 デザイナー：
ここ、見た目上3pxだけ上にずらしたいんですが…
🟦 コーダー：
この1ヶ所だけのために専用クラス（例外ルール）を増やすと、将来の修正時にバグを生むリスクがあります…
🟧 デザイナー：
そうなんですね…見た目の調整だと思っていました。
この会話をなくすには、デザイン時に「余白の基準ルール」を決めておくことでほぼ解消できます。
（４）改行位置・行間のズレは“テキスト量の変動”が原因
特にサイト案件では、テキストの可変性への配慮が不可欠です。
⚠️ 改行・行間が崩れる要因
・CMSで文字量が増減する。
・翻訳で文字数が変わる（例：日本語の「お問い合わせ」が英語の「Contact Us」になる）。
・更新作業でテキストが差し替わる。
デザイン時に「ここで改行したい」と意図的に改行を入れても、実際のブラウザでテキストが流れると、その指定は意味をなさず、意図しない場所で改行されてしまうことが多いです。
「改行指定」は、実装界隈でももっともズレやすい要素の一つだと認識しましょう。
（５）実装しやすい“ズレにくいデザイン”とは
コーダーが助かり、表示崩れにも強くなるのは、「パターン化されたデザイン」です。
☝️ 絶対マスターしたいグリッドシステム
☘️ 余白の基準を決める：
余白を8px、16px、24pxのように、「8の倍数」で統一する（8ptグリッドシステム）。
☘️ ボックス幅が一定：
コンテンツ幅（例：1440px）内での要素の幅を揃える。
☘️ 行間の規則：
テキストサイズに応じて行間の比率を統一する（例：フォントサイズの1.5倍）。
ただこれだけで、実装時のズレが大きく減り、表示崩れにも強くなります。
（６）揃えることでデザインの説得力も上がる
これはデザイナーさんとして嬉しいポイントですが、余白やグリッドを「揃える」ことは、実装しやすいだけでなくデザイン自体の完成度も格段に上げるんです。
“揃っている”というだけで、サイト全体がプロらしい印象に変わり、実装時のブレもほとんどなくなります。
5. SPとPCの関係性をどう考える？
（１）LPでは気づかない“可変幅”という考え方
LPでは「デザイン通りに表示される」前提で作ることが多いですよね。
しかし、サイト制作では、画面幅によってレイアウトが伸びたり縮んだりする「可変幅（レスポンシブ）」が前提になります。
☘️ LPの前提：
幅が固定された静止画に近い。
☘️ サイトの前提：
流動的で、画面幅全体に合わせて要素が変化する。
この前提の違いが、SPとPCの関係性で最初につまずきやすいポイントです。
（２）PCデザインを作ってからSPを考えるとズレる
よくあるのが、「PCを作り終えたあとにSPを考えたら、全然収まらない…」というケースです。
⚠️ PCから作ると失敗する構造
❌ テキスト量が多すぎる：
PCで綺麗に見えるテキストが、SPで5〜6行になり圧迫感が出る。
❌ 画像の比率がおかしい：
PCの横長画像をそのまま縮小すると、SPで小さすぎて見えない。
❌ レイアウトの順序が破綻：
SPで要素を縦に並べ替えたら、情報の優先順位が逆転してしまった。
これは、PCの大きな横幅を前提にデザインしてしまい、最小画面への耐久性を失うからです。
（３）コーダーとの間で起きやすいズレ
SPは特に「文字量の変化」が大きく影響するため、デザインを固定すると表示が破綻しやすいのです。
🟧 デザイナー：
SPではこのテキストを3行で収めたいんですが…
🟦 コーダー：
文字量が増える可能性があるので、固定行数にすると、溢れたテキストが見えなくなってしまうかもしれません…
🟧 デザイナー：
そうなんですね、固定で作るものだと思っていました。
👉 対策：
テキストは「最大何行まで許容するか」を決めるか、「溢れたら『…』で省略する」などのルールをデザインで示しましょう。
（４）「SP→PC」の順に考える（モバイルファースト）
コーダーがよく言うのが「SPが設計できているとPCは組み立てやすい」ということ。
☘️ SPからデザインを始めるメリット
⭕ 最小単位から考える：
SPは幅が狭いため、優先情報とテキストの省略限界を考える必要がある。
⭕ 構造のシンプル化：
複雑なレイアウトが組めないので、自然とシンプルで再利用しやすい構造になる。
SPが整理できていれば、PCで広げるのは要素を横に並べたり、余白を増やすだけでとても簡単になります。
（５）ブレイクポイントは“変化するタイミング”で考える
「ブレイクポイント＝992px / 375px」といった固定値で考える方が多いのですが、コーダーの世界では「崩れた瞬間がブレイクポイント」という考え方をします。
・デザインのどの幅で崩れそうか？
・どのタイミングでレイアウトを切り替えたいか？
という視点で、PCとSPのデザインデータを用意することが、コーダーとの連携をスムーズにします。
（６）SPとPCは“連続したひとつのデザイン”
SPとPCをまったく別物として作ると、コーダー側で統一感を保つのが難しくなります。理想は、同じ情報構造をベースにしながら、幅に応じてどう変化するかを考えること。
⭕ コンテンツの配置：
PCとSPで情報やセクションの順序は変えない。
⭕ 余白のルール：
PCで48pxの余白は、SPで24pxなど、比率を意識して変化させる。
この考え方が身につくと、実装から「このデザインは組みやすい」と信頼されるようになり、あなた自身も判断に迷わなくなります。
6. コーダーと相談すべきタイミングと、相談しないと危ないポイント
（１）「完成してから相談」は、ほぼ必ず手戻りが起きる
LP中心のデザイナーさんの多くが、「デザインがある程度固まってから相談した方がいい」と考えがちです。
ですが、サイト案件では、方向性を早く共有するほどスムーズに進みます。
❌ 遅い相談：
完成後に「実装が難しい」「構造が合わない」と指摘され、デザインの根幹から組み替えが必要になる。
⭕ 早い相談：
構造的なNGポイントを早期に避け、手戻りなしでデザインを進められる。
（２）最初に相談すべき内容は“デザイン”ではなく“構造”
コーダーが最も知りたいのは、「再現の難易度」ではなく、「実装のルール」に関わる部分です。
☝️ デザインのディテールより先に確認
☘️ 共通パーツの扱い：
ヘッダーやフッターはどこまで自由に変更してOKか？
☘️ 情報の階層：
記事一覧などのCMSで更新されるエリアの仕組みはどうなっているか？
☘️ ブレイクポイント：
PCとSPをどの幅で切り替える想定か？
デザインのディテールよりも、何を共通化するのか／どこは自由にしていいのか、といった「構造」の方が実装に直結します。
（３）よくある認識のズレ「相談の順番ミス」をなくす
この「相談の順番ミス」は、ほぼすべての案件で起きています。
🟧 デザイナー：
デザイン完成したのでレビューお願いします！
🟦 コーダー：
ワイヤーの段階で共通パーツの認識にズレがあり、ページ構造から組み直しが必要かもしれません…
🟧 デザイナー：
先に相談すればよかったです…
👉 対策：
デザイン着手前に、ワイヤーフレームの段階で「これはデザインレビューではなく、構造レビューです」と伝えて相談しましょう。
（４）デザイン途中でも相談した方がいいタイミング
「まだ荒いんですが…」と伝えても大丈夫ですし、むしろ実装者はその段階の方が助かることが多いです。
☝️ コーダーに共有すべきタイミング
☘️ ワイヤーフレームができたとき：
→ 構造の確認。
☘️ 共通パーツの仕様が見えてきたとき：
→ ルール確定のため。
☘️ 複雑なアニメーションや特殊表現を入れたいとき：
→ 実装可否の確認。
☘️ 画像かCSSか迷う要素があるとき：
→ 工数の確認。
（５）独断で進めると危険なポイント
以下の項目を「独断で進める」と非常に危険です。これらは見た目以上に実装への影響が大きく、後から修正すると莫大な工数が取られます。
・複雑なアニメーション（パララックスや凝った動き）。
・ブレイクポイント周りの切り替え挙動（タブレット時の特殊な動き）。
・ボタンやフォームなど機能を持つ要素（入力時のエラー表示など）。
・共通パーツの高さや幅の改変。
（６）相談すると作業が増える…は誤解
「相談すると、逆に指摘が増えて大変になるのでは？」と思う方も多いですが、実は真逆です。
☘️ 早期相談がもたらす最大のメリット
・NGポイントを事前に避けられる。
・実装しやすい「黄金ルート」のデザインに寄せやすい。
・後半の修正がほぼなくなる。
最終的に作業量が減り、精神的にもとても楽になります。
（７）相談の価値は“安心感”にある
最終的に伝えたいのは、相談は「迷っているからする」のではなく、「スムーズに進めるための工夫」だということ。
相談のハードルを下げるだけで、デザイナーさんの負担は驚くほど軽くなり、コーダーからも喜ばれる存在になります。
7. まとめ
LP制作中心のデザイナーさんが抱える「どこまで作ればいいの？」という不安は、これで解消されたはずです。
実装の構造やルールを少し知ることは、「デザインの制限」ではなく、むしろ「判断の軸」となって迷いを減らし、デザイナーさんの自由度を上げることにつながります。
現場で起きる多くのトラブルは、スキル不足ではなく、単に「共通パーツの仕組みや、SPとPCの関係性を知らなかっただけ」で起きています。
これからは、余白を揃える、SPを先に考える、共通部分を意識するといった「実装を助けるデザイン」を意識してみましょう。そして、不安な点は完成を待たずに「効率化の手段」としてコーダーに相談してください。
コーダーは早めに相談されたほうが助かるんです。
今日からこのどれか一つだけでも実践すれば、明日のデザインはぐっとスムーズになります。
気づけばあなたは「実装を想定してデザインできる、信頼性の高いデザイナー」として、クライアントから頼られる存在になっているはずです。
