デザインデータを作成した後「またコーダーから質問が来てしまうかも…」と不安を感じたことはありませんか？
実は、どんなに完璧に作っても、デザイナーさんとコーダーの「見ている世界」がズレていると、ほぼ100％手戻りが発生します。
この記事では、コーダーがスムーズに作業を開始し、手戻りを最小限に抑えるためのデザインデータの渡し方を徹底解説します。
1. なぜ“データ渡しでつまずく”のか？
（１）「え、これ実装できません…」と言われるパターン
LP制作のデザイン承認後、コーダーからこんなメッセージが。。。
「このフォントはWebで使えないので代替フォントを探してください。」
「このレイアウトだと、レスポンシブ対応が難しいです。」
「スマホメニューを開いたときのデザインがありませんよ？」
こうした“実装前の指摘”は、デザインのやり直しだけでなく、プロジェクトの遅延と追加コストに直結します。
「え、私のデザインってそんなに無理があった…？」と不安になるかもしれませんが、これは単なる技術不足の問題ではありません。
（２）問題の本質は「クライアント視点」と「実装視点」の分断
“渡したあとに判明する不具合”は、デザイナーさんの技術不足が原因ではなく、必要とされる「情報」が違うことによる視点の分断が問題です。
クライアントが見て判断するのは「見た目や雰囲気」ですが、コーダーが最初に求めるのは「実装に必要な情報」です。
↓↓↓コーダーが最初にチェックする情報↓↓↓
・キャンバスの基準幅やブレイクポイント（PC幅、スマホ幅）。
・選択フォントがWebフォントか、代替CSSフォントがあるか。
・背景の描画モード（乗算など）を画像化して再現可能か。
・ボタンやリンクのホバー時、クリック時などの状態。
「クライアントのためのデザイン」だけを整えても、「実装のための情報」が不足したままでは、手戻りが発生します。
これは、制作フローにおいて「実装に必要な仕様の確認」が抜けていることが原因なんです。
（３）「実装の工程」をイメージしないと見落としが起きやすい
バナー制作や単発デザインの経験からWeb制作へ移ってきたデザイナーさんは、「デザインを仕上げること」がゴールになりがちで、その先にある実装の工程をイメージしづらいことがあります。
その結果、以下の見落としが起こり、制作の遅延につながります。
✅ 実装不可なフォントの選定: サーバーにアップロードできないライセンスのフォントを選んでいる。
✅ サイズ基準の欠落: スマホ幅を375px基準で作るべきか、750px基準で作るべきかの指示がない。
✅ 状態の欠落: メニュー展開時のナビゲーション、フォームのエラー表示などのデザインがない。
実装に必要な「仕様」の視点が抜け落ちているのです。そこに気づいて、情報を補完することが最初の一歩です。
（４）正しい渡し方は「工数削減＆信頼性向上」につながる
難しい技術を覚える必要はありませんが、ほんの少し視点を変えて、「実装に必要な情報をあらかじめデザインに含める」という意識を持つだけで、データ渡しのミスは激減します。
大切なのは、「何をどのように気をつければ、修正依頼がなくなるのか」という具体的なポイントを知ることです。
コーダーから「完璧なデザインデータです、すぐに着手できます！」と言われるようになると、コーディングの着手が遅れずに済むので、1日でも早くクライアントに納品できます。
2. コーダーとデザイナーが見ている世界のズレ
（１）同じ画面を見ていても、見ている“ポイント”がまったく違う
デザインデータを渡した後にコーダーから質問が続くと、「え、そんなに説明不足だった…？」と不安になりますよね。
実は、デザイナーさんとコーダーでは同じ画面でも注目している情報が根本的に違います。
✅ デザイナーの視点：
「見た目・体験・印象」「ロゴとメニューのバランス、整った…！」
✅ コーダーの視点：
「仕様・ルール・挙動」「スクロール時に固定されるか（position: fixed）？」「ヘッダーの重なり順（z-index）は？」
見えている層（レイヤー）が違うため、デザインデータに実装に必要な情報が欠けてしまうのも無理はありません。ただ必要な情報が違うだけです。
（２）サイズ・フォント・描画モードが噛み合わない
視点の違いから、実装基準のズレが生まれます。
↓↓↓ズレの具体例と解決策↓↓↓
◆ キャンバス幅のズレ
デザイン全体のキャンバス幅が1440pxで作成されているのに、「画面いっぱいに背景を広げて欲しい」とコーダーに要望。しかし、画像のサイズが足りていないのでコーディングできない。
✅ 解決策：
最大幅とブレイクポイント（PC、タブレット、スマホの基準幅）をコーダーと相談して決めてからデザインを開始する。
◆ スマホデザインのズレ
デザイナーが750px、コーダーが375px基準で計算するため、余白の数値がズレる。
✅ 解決策：
スマホのデザインは、一般的な基準幅（例：750pxまたは375px）をチーム内で固定し、計測のブレをなくす。（750px推奨の理由は後ほど解説します）
◆ フォントのズレ
Webフォントがない、またはライセンスがないためデザインどおりに再現できない。
✅ 解決策：
Google FontsやTypeSquareなど、実装可能なWebフォントライブラリから最初に選定する。
◆ 描画モードのズレ
描画モード（乗算/スクリーンなど）はCSSで再現できない場合が多いため、書き出し時に反映されない。
✅ 解決策：
描画モードを安易に使わず、CSSで再現可能な「不透明度」や「色調の調整」に留める。
どれも “間違っているわけではない” けれど、見ている基準が違うために噛み合わないのです。
（３）「アクションと状態のデザイン」が抜けると実装不可能
特に多いのが、ホバー・スマホメニュー・モーダルなど、ユーザーが何か操作をしたときに見た目が変わる箇所のデザイン不足です。
コーダーの本音：
「ホバーしたときのカラーコードは？半透明なら透明度はどのくらい？」「PCのサブメニューとSPのハンバーガーメニューを開いたときのデザインはどうしますか？」
デザイナーの本音：
「えっ…その状態、デザインが必要なの…？」
デザイナーさんは「完成見た目」のプロ、コーダーは「動きと状態」のプロです。静止した見た目だけでは、動作に必要な情報が必ず欠落します。
これは単に「状態のデザイン」の存在に気づく機会が少なかっただけです。
↓↓↓ Figmaのコンポーネント活用でズレを解消 ↓↓↓
ボタンなどのパーツをコンポーネント化し、バリアント（Variant）機能を使ってDefault、Hover、Disabledといった状態をあらかじめ定義しておきましょう。これだけでコーダーは迷わず実装に移れます。
（４）Figmaの渡し方も“計測と情報抽出”のズレが原因
Figmaで「開発モードにしてもらえると助かります」と言われるのも、情報の取得効率のズレが原因です。
↓↓↓コーダーが開発モードを求める理由↓↓↓
✅ 正確な数値のコピー:
margin や padding のpx値を一瞬でコピーしたい。
✅ CSSコードの生成:
テキストレイヤーからフォント情報などをまとめたCSSスニペットを生成したい。
✅ 余白情報の計測:
要素間の距離を一瞬で正確に測りたい。
これらの作業は「開発モード」で行う方が圧倒的に効率的なため、単なる表示モードではなく、実装に必要な情報の正確な抽出のためにモードの切り替えが必要なのです。
（５）このズレは“知れば埋まる”
大切なのは、このズレが「センス」や「才能」で埋まるものではないということ。ただ知らなかっただけ、経験していなかっただけです。
でも一度知ると、
✅ 実装可能なフォントを最初に決める
✅ 基準幅を最初に揃える
✅ 必要なアクション状態をデザインに含める
といった調整が自然にできるようになります。
そしてその結果、「渡した瞬間から実装がスムーズに始まるデザイン」へと変わり、デザイナーさんの制作は驚くほどラクになります。
3. 最初に決めよう「キャンバス幅・スマホ幅」
（１）キャンバス幅に迷ってしまうのは“当たり前”
「PCは1440px？ 1920px？」「スマホは375px？ それとも750px？」この迷いは、デザイナーさんが必ずぶつかるポイントです。
このルール、現場の暗黙知として扱われやすく、明確な基準を学ぶ機会がないデザイナーさんが多い気がします。
（２）PCキャンバス幅の最適解
現場で最もトラブルが少ない最適解は、次の基準です。
✅ コンテンツ幅：
1000～1400px（画面中央の主要コンテンツの最大幅）
✅ キャンバス幅：
1920px（デザインの作業領域）
↓↓↓1000～1400pxを推す技術的理由↓↓
コーダーはこのサイズ帯で組むことが多いです。CSSでmax-widthを使って中央揃え（margin-inline: auto;）にするのが最も安定した実装方法です。
コーダーの本音：
「コンテンツ幅が1000～1400pxで作られていれば、左右のブレがないので完璧です！」
キャンバスを1920pxにしておけば、PC画面幅いっぱいに背景を伸ばすこともできますし、左右のスペースの扱いも安定しやすくなります。
（３）SPキャンバス幅の最適解
昔は「375pxで作る」のが一般的でしたが、今は状況が違います。
今のスマホはほぼすべてRetina（レティナ/高解像度）前提、つまり2倍サイズでデザインしておくほうが綺麗で安全なのです。
↓↓↓750pxを採用する3つのメリット↓↓↓
画像品質の安定：画像を2倍サイズ（750px基準）で作成して書き出せば、画像が粗くなる問題がゼロになります。
計測の安定：
余白・フォントサイズを「実寸×2」で作るので視認性が安定します。
コーダーの効率化：
コーダー側で「すべて1/2で実装する」という一貫したルールになるため、迷いがありません。
750pxで作るということは、後工程が一気にラクになるという仕組みなんです。
（４）「375pxと750px」というズレの正体
このズレは、スマホのピクセル密度に関する技術的な用語の混在が原因で生まれます。
375px：
これはブラウザが認識する実寸（ビューポート幅）です。
750px：
これはスマホの画面の物理ピクセル数（2倍サイズ）です。
実寸計算は375pxなのですが、画質的には750pxでデザインした方が圧倒的に安全なのです。
現在は、「高画質で渡し、コーダーに実寸計算を任せる」750pxが主流です。
（５）“最初に幅を決めるだけ”でデザインが安定する理由
幅を決めると、すべてのデザイン判断に軸ができます。
・余白の基準が揃う。
・フォントサイズのブレが消える。
・修正のとき「基準からズレてないか」を判断できる。
コーダーに渡した瞬間から迷いがないデザインになります。
（６）幅の“初手ミス”を防ぐためのタスク
幅の基準が揃っていないことで起きる違和感は、積もり積もってストレスになります。
逆に言えば、キャンバス幅・スマホ幅の正解を最初に決めるだけで、制作が驚くほどスムーズになります。
↓↓↓デザイン開始時の必須タスク↓↓↓
✅ PCのコンテンツ幅を1000～1400pxに固定し、ガイドラインを引く。
✅ スマホのアートボードは必ず750pxで作成する。
✅ Figma/Sketchのブレイクポイント設定に、この数値を事前に設定しておく。
これさえ間違えなければ、後の工程は非常に安定します。
4. “実装できるウェブフォント”の見分け方
（１）「このフォント、Webで使えません…」
コーダーから「このフォント、Webフォントがなくて使えません」と言われたことありませんか？
↓↓↓Webフォントの正体と不使用の理由↓↓↓
✅ Webフォントとは、PCにインストールされているフォントとは違い、WOFFやWOFF2といったWeb閲覧専用のデータ形式で配信されるフォント。
✅ デザインで使う一般的なフォントファイル（OpenType/TrueType）は、Web配信用のデータに変換・許諾されていないと、ブラウザで正しく表示されないことがある。
（２）Webフォント対応かどうかを調べる方法
フォントの選定はコーダーが決めることではなく、デザインの初期段階で完了すべき重要タスクです。
ダーに「Webフォント化（変換）が可能か」を先に相談しましょう。
✅ Webフォント、digital use、web useなどの記載があれば使用可能。✅ 逆にこれがない場合、そのままでは使用できず、画像化（デメリットあり）が必要になる可能性が高い。
（３）Webフォントの「読み込み速度」も意識しよう
フォントの選定は、デザインの再現性だけでなく、サイトの読み込み速度（UX）にも影響します。
↓↓↓実装負荷を減らすための知識↓↓↓
日本語フォントは特にデータが重く、ページの表示速度を遅くする主要因です。Webフォントを使う際は、「サブセット化」（使用する文字だけを抜き出す処理）が必須になります。
※Googleフォントはデフォルトでサブセット化をサポートしています。
Webフォントを選定する際、コーダーに「読み込み速度を優先して、サブセット化をお願いします」と一言添えるだけでも、実装上の配慮があると評価されます。
もし利用不可のフォントを無理に画像化して使うと、SEOやアクセシビリティが低下するというデメリットが発生します。
フォント選定をデザインの初手で行うことが、後工程すべての品質を守ることにつながります。
5. どこまでデザインを作るべき？
デザインデータを渡すときに最も迷うのが、「どこまでデザインすべきか」という線引きです。
作り込みすぎても時間がかかり、足りなければコーダーに追加依頼されて制作が止まってしまいます。
この悩みは、機能の種類ごとに「作るべきもの・作らなくていいもの」の判断基準を知ることで解決します。
① スマホメニュー：必ずデザインが必要（必須）
スマホメニューは、デザイナーさんとコーダーの認識が最もズレやすい部分の一つです。
「閉じた状態」だけでなく「開いた状態」のデザインが絶対に必要です。
↓↓↓作るべき2つの状態と実装への指示↓↓↓
ハンバーガーの状態（閉じている時のアイコンデザイン）メニューが開いた時の表示（背景色、リンクの整列、閉じるボタン）
さらに、開いた状態のデザインには、実装時に必要な挙動の指示も添えましょう。
メニューが全画面を覆い、背後のページスクロールは止める（overflow: hiddenを意図）。
ヘッダーごと、またはメニュー部分を画面上部に固定する（position: fixedを意図）。
⚠️注意： これらを渡さないと、実装後に「背景が透過している」「背後のコンテンツがスクロールしてしまう」など、認識のズレが必ず起きます。
② ホバー状態：LPなら必須／コーポレートなら8割必須
ホバーは「カーソルを乗せたときの見え方」であり、ユーザー体験の質を左右します。
LPの場合： CTA（ボタン）・リンクテキストは最重要コンバージョン要素なので、すべて必ずホバーをデザインするべきです。
コーポレートの場合： グローバルメニュー、ボタン類、ニュース一覧などの操作可能な要素は必須です。
↓↓↓ホバーで決めておくべき実装情報↓↓↓
色や影の変化だけでなく、トランジション（変化速度）を伝える。「ふわっと0.3秒で変化」など具体的な指示が、意図通りの仕上がりにつながります。
複数のリンクがある場合、どの要素に変化をつけるか（リンク全体か、アイコンだけか）。
③ サンクスページ：ほぼ100％必要（作らないとプロジェクトが止まる）
サンクスページ（フォームの完了画面）は、「クライアントから要望されていない」と思いがちですが、フォームを実装する場合絶対必要です。
↓↓↓サンクスページが必要な3つの理由↓↓↓
専用のURLの存在： 完了ページ専用のURL（例: /thanks/）がないと、フォームを送信後に表示するページが決まらないため、ページが真っ白になったりエラーになります。
CV計測の起点：
マーケティング施策（コンバージョン計測）が、このページへの訪問をトリガーとして行われます。
イメージの統一：
完了の文章やレイアウトがないと、コーダーがデフォルトの表示で間に合わせることになり、世界観が崩れます。
最低限、完了の文章とシンプルなレイアウトだけでも作りましょう。
URLも決めておくと、コーダーがCVタグを埋め込みやすくなります。
④ 細かいのに必要なもの：設定画面・エラー表示・404
LPでは必須ではありませんが、コーポレートやサービスサイトでは必須です。
ユーザーの体験を中断させないために、これらの「フリーズポイント」をデザインしておくことが重要です。
↓↓↓デザイン必須のフリーズポイント↓↓↓
フォームのエラー表示（バリデーション）：
ユーザーがミスした際に表示される赤文字の見え方、表示位置、メッセージ。
404ページ：
ページが見つからないときの画面。デフォルトのままでは世界観が崩れるため、サイトのトーンに合わせたデザインが必要です。
⑤ 逆に、細かいデザインが不要なケースは？
文章だけのページ： 利用規約、プライバシーポリシー（レイアウトはシンプルでOK）。
CMSで自動生成されるページの細部： ブログの一覧ページなど、写真のトリミング、タグの自動挿入といった、システム側で調整される部分。
これらはコーダー・CMS側で調整できる領域なので、細かく作り込まなくても大丈夫です。
ただし、大枠のルールとして、余白の基準、フォントサイズ、リンクの色といった共通ルール（デザインのガイド）はきちんと指定しておきましょう。
⑥ 判断基準まとめ：“状態が変わるもの” は全部作る
状態が変わるもの → デザインが必要開く／閉じる、押す前／押した後、エラー前／エラー後、ホバー前／ホバー後
状態が変わらないもの → デザイン不要の可能性が高いテキストだけのページ、CMSが自動で組む箇所、デフォルト表示で問題ない要素
これさえ意識すれば迷いはほぼなくなります。
6. Figma開発モードは“有料でも使うべき？”
デザイナーさんから「Figmaの開発モードって、有料だけど使ったほうがいいんですか？」と、よく聞かれます。
この問題は「Figmaの料金」ではなく、「コーダーが必要としている情報を最速で渡せるかどうか」が本質です。
① コーダーの本音：開発モードは作業効率がケタ違い
まず、開発モードがあると何が変わるのかというと、コーダーがクリック一つで「実装に必要な単位」を理解できる状態になります。
↓↓↓開発モードが解決するコーダーの課題↓↓↓
・CSSスニペットが自動生成される（コピペするだけ）。
・単位（px/rem/em）や行間、色の情報が正確に取得できる。
・余白・距離が一瞬で確認できる。
・コンポーネントやバリアントの構造が整理されて見やすい。
・デザインシステムとの連携（カラートークンなど）がスムーズになる。
デザインモードのまま渡されると、コーダーは一つずつ「手作業で計測・単位を変換・情報を検索」する必要があり、作業が倍に膨らみます。コーディングの見積もりが跳ね上がることがあります。
② じゃあ有料でも開発モードを契約するべき？
答えは「チームの状況と制作頻度による」です。無理に毎月支払う必要はありませんが、以下の状況であれば、「制作効率への投資」として十分価値があります。
↓↓↓開発モードを契約すべき判断基準↓↓↓
・LP制作を毎月受注するなど、制作頻度が高い。
・コーダーとの分業案件が多い（特に外部コーダーとの連携）。
・受け渡しミスで何度も修正依頼がくる。
・短納期の案件が多い。
特にLP制作では、情報量が多い分、開発モードで渡すだけでコーダーの作業時間が1.5倍〜2倍速くなることも珍しくありません。
月額コストと、削減できる人件費と手戻り工数を比較して判断しましょう。
③ 無料で渡したい場合の“代替手段”もあります
Figmaの有料課金をしない選択も可能です。その場合、コーダーが求めるデータを手作業で用意するという、やっかいなタスクが発生します。
↓↓↓手作業で開発モードの便利さをカバーする方法↓↓↓
・画像の書き出し設定をすべて事前に行い、アセットとして書き出せる状態にしておく。
・Figmaの「スタイル機能」を活用し、テキストスタイル・カラー・余白ルールを事前に定義する。
・セクションごとにグループ化し、階層を揃えておく。
・コンポーネントは整理し、「これが正確な数値」というポイントをFigmaノートで明記する。
大事なのは、「開発モードの便利さを、手作業でどこまでカバーできるか」という視点です。
④ デザイナーとコーダーの“会話のズレ”が起きやすい部分
よくあるズレは、「情報の取得効率」への認識の違いです。
デザイナーの認識：
「デザインモードでも見れるでしょ？」
コーダーの認識：
「見れますけど、CSS単位（rem/em）への変換や、余白の計測が手作業になり、修正も含めると2倍時間がかかるんです。」
デザイナー側は「見れる＝渡せている」と思いがちですが、コーダー側は「見れるけど作業効率が悪い」と受け取っています。
⑤ 判断の最終ライン：“チーム制作ならほぼ必須”
LP案件ならなおさらですが、「デザイナーさんとコーダーが分業する体制」であれば、開発モードは非常に有効です。
✅ ズレが減る
✅ 修正依頼が減る
✅ コーダーの作業が速くなる
✅ コミュニケーションがスムーズになる
この効果は、短納期・低ストレス・高品質を３つとも実現できる強力な投資となります。逆に、自分がデザインもコーディングもする場合、開発モードの価値は十分に発揮されません。
7. コーダーが手を伸ばしている位置に“バトンを渡す”という考え方
デザインからコーディングへ。
この「バトン渡し」がスムーズにいくかどうかで、案件が止まるか、流れるように進むかが決まります。
多くのデザイナーさんが悩むのは「どこまで用意すればバトンになるのか？」が自分では見えにくいところです。
でも、「コーダーがどこに手を伸ばしているのか」を理解すれば、一気にわかりやすくなります。
（１）デザイナー目線とコーダー目線の根本的な違い
よくある会話で「ズレ」の正体が見えます。
デザイナーの視点：
「クライアントに見せて承認を取るためのデザイン」が完成形。
コーダーの視点：
「コードに落とし込めるだけの材料（設計図）」が揃っているか。
デザイナーさんが「完成したFigmaデータ」を渡しても、コーダーは「スマホメニューの開き時ってどういうデザインになりますか？」と聞いてきます。
このズレは、技術知識の差ではなく、工程で見ている世界が違うことが原因です。
（２）バトンは“手元に置いていても届かない”
・スマホ幅、フォント、ホバー、画像処理など...。
・ボタンはあるけどホバー状態がない。
・画像はあるけど書き出し設定がない。
・レイアウトはあるけど余白ルールが決まっていない。
これらは、バトンは手元にあるのに、コーダーの「手が届く位置」まで運べていない状態です。
コーダーは実装に入れません。
バトンの形（静的な見た目）はあっても、まだ次のランナーが握れる形ではない、という状況なんですね。
💡 解決策：レイヤー整理もバトンの一部
Figma内でレイヤー名が「Rectangle 1 copy」のままだったり、グループ化が乱雑だったりすると、コーダーは情報が拾えません。
レイヤーの整理も、バトンを渡すための「手の届く位置」にする重要なタスクです。
（３）コーダーが受け取りたい情報
コーダーが受け取りたいのは、見た目をコードで完全に再現できる情報のセットです。
これが、コーダー手を伸ばしている「実装開始できる状態」です。
↓↓↓コーダーが求めている情報↓↓↓
余白のルール（マージン・パディング）：
8pxグリッドなど、余白の基準となる単位。
タイポグラフィ：
フォントの種類・ウェイト・行間（line-height）。
アクションの状態：
ボタンの通常／ホバー／アクティブ、スマホメニューの開閉。
画像と書き出し：
画像の書き出し設定（1x / 2x）と、背景の描画モードの扱い。
カラートークン：
使用されているカラーコードをFigmaのスタイルで定義しているか。
これらの情報を「デザインガイドライン」としてまとめることで、コーダーは最初から「走れる状態」になります。
（４）“ここまで準備してくれている”という思いが信頼につながる
デザイナーさんが「相手の工程を理解してバトンを渡している」と伝われば、コーダーは圧倒的に動きやすくなります。
↓↓↓信頼性が向上する5つのメリット↓↓↓
・修正依頼が激減する。
・スケジュールが確実に守られる。
・コーダーからの信頼が高まる（「実装負荷の低いデザイン」と評価される）。
・案件の単価が自然に上がりやすい。
・チーム制作の依頼が継続的に続く。
実はこれこそが、技術に詳しくないデザイナーさんが最短で「評価される人」になる方法なんです。
（５）技術よりも大切な“つながり” の理解
「技術が苦手だから…」「もっと知識がないといけないのでは…」と不安になる必要はありません。
本当は、専門知識の前に、「工程のつながり」を理解すれば十分です。
どこでバトンが必要かがわかれば、そのために必要な最低限の知識が自然と身につきます。
これは、努力の量ではなく「視点」の問題なんです。
8. まとめ
デザインデータの渡し方に迷うのは、決してスキル不足ではなく「どこまで用意すれば相手が動けるか」が見えづらいだけです。
キャンバス幅・スマホ幅の基準、使えるフォントや画像の扱い、スマホメニューやホバーの状態デザイン、そしてFigma開発モードの判断など、少しのポイントを押さえるだけで、コーダーが安心して受け取れる“走り出せるデータ”になります。
デザイナーさんが気をつけたひと工夫は、必ずチームの信頼・案件のスムーズな進行・自分自身の心の余裕につながります。
焦らず、相手が手を伸ばす位置にそっとバトンを差し出すように進めていけば大丈夫です。
