デザインカンプからコードへ——手戻りが減る「引き渡し」の書き方

デザインカンプを渡したあとに来る質問は、案件が変わってもだいたい同じ場所に集中します。「この余白は何px？」「ホバーはどうなる？」「文字が長くなったら？」の3つです。逆に言えば、この3つを先回りして書いておけば、引き渡し後の往復はかなり減ります。私はカンプそのものを作り込むより、この3点を添える作業に時間を使うようにしています。

手戻りは「解像度の落ちる場所」で起きる

カンプは1つの状態を固定した絵です。ある画面幅、ある文字量、ボタンの通常状態——その組み合わせのスナップショットでしかありません。ところがコードは、ありうる状態の全部を書く必要がある。この差がそのまま、実装側の「判断」になります。

自分でデザインして自分で実装していた頃は、この判断を頭の中で済ませていました。ただ、他の人に渡すとなると話が変わります。実装者が良かれと思って埋めた判断が、こちらの意図と違っていたときに手戻りになる。原因は実装者のミスではなく、渡す側が「絵にならない部分」を言語化していないことのほうが多い、というのが私の実感です。

添えるのは「余白・状態・可変」の3点

私が引き渡しに添えるのは、凝ったドキュメントではなく次の3項目です。だいたいA4一枚か、Figma上の注釈で収まります。

1. 余白のルール 個別の数値ではなく、使っていい値のセットを書きます。たとえば「4の倍数。セクション間は64／32、要素間は24／16／8」のように。数値の一覧があると、カンプで測った値が半端だったとき、実装者が近いほうに丸める判断ができます。「測って出た47px」より「ルール上の48px」のほうが正しい、と先に決めておくわけです。

2. 状態（ステート） インタラクションのある要素は、通常・ホバー・フォーカス・押下中・無効・読み込み中のうち、その案件で必要なものを列挙します。全部描く必要はなく、「ホバーは背景を1段暗く、フォーカスは2pxのアウトライン、無効は不透明度50%」と文章で書くだけでも足ります。フォーカスの見た目はキーボード操作の人にとって唯一の手がかりなので、ここを「ブラウザ標準のままでOK」と書くか「こう変える」と書くかは必ず決めておきます。

3. 可変（伸び縮み）の許容範囲 文字数・画像比率・画面幅の3つについて、どこまで伸びていいかを書きます。「商品名は2行まで、3行目は省略」「サムネは16:9固定でトリミング」「このカードは最小320px／最大480px」。ここが空欄だと、実装者はカンプの文字量をそのまま正解だと解釈するしかありません。運用が始まって長い文言が入った瞬間に崩れるのは、たいていこの項目の抜けです。

Figmaのどこに何を載せるか

Figmaを使うなら、注釈をひとつのテキストにまとめるより、機能ごとに置き場所を分けたほうが探しやすくなります。私の分け方はこうです。

内容	置き場所
色・タイポ・余白の値	バリアブル／スタイル
「ここから実装していい」の合図	Ready for dev
状態・可変の説明文	該当要素への注釈
実装後のコンポーネント、チケット	Dev resources のリンク

Figmaの開発モード（Dev Mode）には、フレームに「Mark as ready for dev」を付ける機能、前のバージョンとの差分を見る Compare changes、GitHubやJira・Storybookなどへのリンクを要素に紐づける Dev resources、CSSなどのコードスニペット表示があります（Guide to Dev Mode – Figma Learn）。利用には有料プランのFullまたはDev席が必要とされているので、体制を組む前に席の割り当てを確認しておくと安全です。

なお、スニペットに出るCSSは参考値です。そのまま貼るものではなく、「デザイナーが意図した値」を読み取る窓口として扱うのがちょうどいい距離感だと思っています。

値の受け渡しを仕組みにするなら

案件が続くなら、色や余白の値を手で書き写すのをやめ、機械が読める形で渡す方法もあります。デザイントークンの交換フォーマットを標準化しているW3Cのコミュニティグループ（DTCG）は、2025年10月28日に仕様の最初の安定版「2025.10」を公開したと発表しています（Design Tokens Community Group）。テーマ切り替えや新しい色空間への対応が入ったJSON形式で、ツールをまたいで同じトークンファイルを読み書きできるようにする、という方向性のものです。

ただ、これは複数プロダクト・複数プラットフォームを抱えるチーム向けの道具で、1サイトの制作案件では導入コストのほうが勝ちます。私自身、単発の案件ではCSSのカスタムプロパティに値を集約するところまでで止めることが多いです。それでも「値の出どころを一箇所にする」という考え方自体は、規模に関係なく効きます。

明日から試せる一手

次の引き渡しで、カンプに1枚だけメモを足してみてください。書くのは3行です。

• 余白に使っていい数値の一覧
• 押せる要素の、ホバーとフォーカスの見た目
• いちばん文字数が変わりそうな箇所の、上限と超えたときの扱い

この3行で、返ってくる質問が「どうすればいい？」から「この解釈で合ってる？」に変わります。確認の往復は残っても、作り直しの往復は減るはずです。