実装担当者に伝わるデザインデータの渡し方 添えておきたい5つの指定

デザインを渡したあと、こんな確認が続くことはないでしょうか。
「スマホではどう並べますか」「文字が増えたときはどうしますか」「ボタンにカーソルを合わせたときは何か変わりますか」
ひとつずつは短いやりとりです。それでも積み上がると、確認の往復だけで数日が過ぎていきます。
渡しているデータ自体は、毎回きちんと作り込んでいるはずです。足りないのは作り込みではなく、データに添える情報のほうかもしれません。

この記事で扱うのは、ファイル名の付け方や画像の書き出し設定、フォントの共有方法、レイヤーの整理といった、データそのものの整え方ではありません。扱うのは、静止したカンプだけでは決まらない設計上の判断を、どう言葉にして添えるかです。
なお、ここでいう実装担当者とは、コーダーやフロントエンドエンジニアなど、デザインを画面として組み立てる人を指します。社外に依頼する場合も社内の担当者に渡す場合も、また自分で実装まで担当する場合も、先に判断の基準を決めておく点は変わりません。

※デザイナーがHTMLやCSSをどこまで理解しておくとよいかは、デザイナーはHTML/CSSをどこまで書ける必要がある？実務で効く範囲と学び方で扱っています。

カンプが示すのは、一時点の見た目

デザインカンプが示しているのは、特定の画面幅・特定の文字量における、一時点の見た目です。コンポーネントや自動レイアウトを使えば、データの中にもある程度の規則を持たせられますが、そこから読み取れる範囲には限りがあります。
たとえば、3枚のカードが横に並んでいるとします。画面の幅が狭くなったとき、カードは折り返して2段になるのか、横にスクロールする形になるのか、1列に積み替わるのか。カンプを見ただけでは、どれが正解なのかは決まりません。どれもありうる作りで、選び方によってスマートフォンでの見え方は変わります。
実装は、絵をそのまま画面に写しているわけではありません。どういう条件で、何がどう変わるかという規則に置き換えて組み立てています。指定のない部分は、実装担当者が判断して埋めることになります。
学ぶ段階では、きれいなカンプが仕上がれば、そこが完成でした。実務には、その先に渡すという工程があります。

データに添えたい5つの指定

具体的に、何を添えればいいのか。5つに整理しました。
はじめにお伝えしておくと、5つすべてが、どの案件でも必要になるわけではありません。 ページの構成が中心のLPであれば「変化」と「優先順位」が効きますし、操作の多いWebアプリケーションであれば「状態」と「例外」の比重が大きくなります。案件に該当する項目だけを使ってください。

1. 基準を渡す ― 個別の値ではなく、共通ルールで

余白・文字サイズ・色は、1箇所ごとの値ではなく、共通のルールとして渡します。

• 余白：一定の尺度から取る（8・16・24・32など、刻みを決めておく）
• 文字：見出し・小見出し・本文・注釈といった役割と、それぞれに対応するサイズ
• 色：文字・背景・強調・境界線といった用途。色値だけでなく、その色が何のための色かも明記する

カンプから数値を拾えば、個別の値は分かります。ただ、それが規則に沿った値なのか、その箇所だけの値なのかは、拾っただけでは判断がつきません。
共通のルールとして渡しておくと、カンプに描かれていない画面が出てきたときに効いてきます。あとから追加された要素、更新で増えたコンテンツ。そのときに、実装担当者が同じルールで判断できます。

2. 変化を渡す ― 想定の範囲内で、何がどう動くか

変化とは、通常想定する範囲内で、画面幅や文字量が変わったときの振る舞いです。
画面の幅が変わったときに何が起きるかは、次の3つを揃えて初めて決まります。

• 代表的なカンプの間を、どう補間するか（PC用とスマートフォン用の2枚を作っても、実際の画面幅はその間に連続して存在します）
• どの条件でレイアウトを切り替えるか
• どこが固定で、どこが伸縮するか

切り替える位置は、デザイナーが固定の値として指定する場合もあれば、レイアウトが崩れ始める位置を基準に、実装担当者と相談して決める場合もあります。どちらの進め方をとるかを先に共有しておくと、あとの手戻りが減ります。
テキストの量についても同じです。通常想定する範囲で文字量が増減したときに、要素が伸びるのか、折り返すのか、途中で省略するのかを決めます。省略する場合は、全文を確認できる手段（詳細ページや、タッチ・キーボードでも操作できる展開など）も併せて検討してください。

3. 状態を渡す ― 操作や利用可否に応じて変わるもの

状態とは、同じUI要素が、ユーザーの操作や利用可否に応じて見え方を変えるものです。ボタンなら、通常・カーソルを合わせたとき・キーボード操作でフォーカスしたとき・押している間・押せないとき。フォームなら、入力前・入力中・エラー・完了。
これらは静止画には写りませんが、実装では指定が必要になります。状態ごとに一覧にすると、確認しやすくなります。画面を状態の数だけ作り込まなくても、「どの状態で、何がどう変わるか」を表にすれば足ります。
ひとつ添えておきたいのは、カーソルを合わせたときの見え方だけを用意しないことです。タッチ操作には「カーソルを合わせる」という操作自体がないため、その変化は起きません。またキーボードで操作する人にとっては、いまどこを選んでいるかを示すフォーカスの表示が手がかりになります。この2つは別のものとして指定してください。

4. 例外を渡す ― 想定の範囲を超えたときの受け止め方

例外とは、想定の範囲を超える条件や、データ・通信の状況によって生じるものです。操作とは関係なく発生します。データが1件も無いとき。読み込んでいる最中。通信に失敗したとき。タイトルが想定の3倍の長さで入ってきたとき。画像が用意されなかったとき。
一覧や検索、通信を伴う画面では、0件・読み込み中・通信失敗などの扱いを検討する必要があります。必要な例外は案件によって異なるので、該当するものだけを決めておけば十分です。
ここを決めずに渡すと、実装担当者が仮の見た目を用意することになり、仮のまま気づかれずに公開されることもあります。とはいえ、全部を作り込む必要はありません。「一覧が0件のときは、この文言を中央に置く」「画像が無いときは、この背景色で塗る」——一行の指定で足りるものも多くあります。

5. 優先順位を渡す ― 制約が出たときに守るもの

時間、技術、端末の制約で、指定どおりにいかない場面が出てくることは珍しくありません。そのときのために、何を守り、何を落としていいかを先に渡しておきます。
「この余白は詰めていいが、この文字サイズは下げない」「この動きは無くていいが、この並び順は変えない」。この粒度で構いません。
これがあると、やりとりの中身が変わります。「できません」で止まらずに、代替案を相談しやすくなります。何を優先すべきかを共有できていれば、実装担当者の側も判断の材料を持てるからです。
優先順位そのものを決めるのは、簡単なことではありません。それでも、言葉にして添える手数のわりに、実装時の判断に効きやすい指定です。そして、見落とされやすい指定のひとつでもあります。

5つを、ひとつのUIに当てはめてみる

記事やサービスを並べるカード一覧を例に、5つを当てはめてみます。デザインデータの脇に、次のように書き添えるイメージです。

• 基準：カード内側の余白は24px、カード同士の間隔は16px。いずれも共通の尺度から取っています
• 変化：PCは3列、狭い画面では1列に切り替えます。列数が変わっても、カードの表示順は変えません
• 状態：カード全体がリンクです。カーソルを合わせたときは枠線を濃くします。キーボード操作でフォーカスしたときは、アウトラインを表示してください
• 例外：画像が登録されていない場合は、共通の代替背景を表示します。タイトルは2行までとし、超える場合は省略したうえで、全文は詳細ページで確認できるようにします
• 優先順位：狭い画面で収まらない場合、画像の表示サイズは小さくして構いません。タイトルと、詳細への導線の読みやすさを優先してください

一つひとつは長い文章ではありません。それでも、この5行があると、実装の途中で判断に迷ったときに立ち返る場所ができます。

指定しすぎない ― 意図は渡し、実現方法は任せる

ここまで読んで、「全部を指定しなければ」と思う必要はありません。線引きの目安は、次のようになります。

• デザイナーが決めて共有するもの：守りたい意図、どう振る舞ってほしいか、どこまでなら許容できるか、何を優先するか
• 実装担当者が判断するもの：クラス名の付け方、ファイルの構成、どの技術で実現するか

※意図と実現方法の両立が難しい場合は、双方で相談して決めます。

実現方法まで指定してしまうと、実装側が持っている選択肢を狭めることがあります。意図と許容範囲が共有されていれば、実現方法はもっと良いものが出てくる余地があります。
そして、一方的に渡して終わりにしないことも同じくらい大切です。注釈だけでは決めにくい挙動は、実装に入る前に短く相談したほうが早く片づきます。そこで合意した内容は、口頭のままにせずデザインデータに書き戻しておくと、あとから参加する人にも同じ情報が渡ります。
なお、細部を詰めなくてよいという話ではありません。情報の優先順位やブランドの印象に関わる箇所は守り、OSやブラウザによって差が出ることのある箇所（フォントの見え方、入力欄やチェックボックスの標準の姿など）は許容範囲を決める。 この2つを分けておくと、どこに手間をかけるかがはっきりします。

いま手元にあるデータに、少しずつ足していく

新しい書式を用意する必要はありません。いま使っているデザインデータに、注釈として足していくところから始められます。
まず書き添えたいのは、制約が出たときに守るものです。1〜2行でも、実装時の判断材料になります。
そのうえで、その案件で手戻りになりやすい項目を選びます。

• ページの見え方が画面幅で大きく変わるなら → 変化
• 操作の多いUIが中心なら → 状態
• 一覧の表示や通信を伴うなら → 例外

共通の基準は、最初から作り込まなくて構いません。同じ値や同じ役割が複数の箇所に現れた段階で整理すると、無理なくまとまります。数値そのものを次の案件に持ち越せるわけではありませんが、整理の型は次の案件の土台として使えます。

指定の抜けを見つける方法として、AIを補助に使うこともできます。実装時に判断できない箇所や曖昧な箇所を、質問の形で洗い出させるやり方です。試作させて確かめる場合は、意図との差を一括りにせず、指定不足なのか、AIの解釈違いなのか、実装上の誤りなのかを分けて見る必要があります。抜けを見つける補助であり、最終的な判断は人が行います。

渡す前のチェックリスト

ここまでの内容を、手元で確認できる形にまとめました。案件に該当する項目だけ確認してください。

□　共通して使う余白・文字サイズ・色の役割を明記した
□　画面幅が変わったときの挙動（切り替える条件、固定と伸縮の区別）を明記した
□　文字量が想定より増えたときの扱いを明記した
□　該当するボタンやフォームについて、必要な状態を明記した
□　データや画像がない場合、読み込み中の場合の扱いを明記した
□　制約が出たときに守る優先順位を明記した
□　実装担当者が判断する範囲と、相談して決める部分を整理した

意図が届くと、判断は画面まで残る

デザインの仕事は、カンプを提出したところで終わりません。そのあと、実装という翻訳を経て、はじめて画面になります。
翻訳の材料が一時点の見た目だけだと、決まっていない部分は実装担当者が判断して埋めることになります。埋め方が悪いという話ではありません。そこは、デザイナーが事前に意図を示し、実装担当者と確認できた場所だった、という話です。
意図と判断の基準まで渡せると、デザインの判断が途中で薄まらずに画面まで残ります。そのために必要なのは、書き添える指定と、決めきれない部分についての対話の両方です。
とはいえ、自分の渡し方が適切な粒度かどうかは、一人で作業していると確かめる機会がありません。判断の精度を上げたいと感じたら、外の視点を使ってみてください。

まずは気軽に、話してみませんか？ ― 無料カウンセリング

「実装担当者への指定の粒度に、自信が持てない」「レビューしてくれる人が社内にいない」「自己流のAI活用に、限界と不安がある」——こうした悩みは、一人で考えていても、なかなか整理がつかないものです。
nestsの無料カウンセリングでは、これまでの経験やスキル、いま抱えている課題を一緒に言語化していきます。売り込みの場ではありませんし、しつこい勧誘もありません。完全無料・オンライン（30分〜1時間）、予約は約3分で日程が決まります。
自分の判断を言葉にして、人に渡せる形にする。その進め方を実務の中で身につけたいということであれば、1対1で伴走するパーソナルコースという選択肢もあります（コースの詳細はこちら）。
どのコースが合うかも含めて、まずは無料カウンセリングで話してみてください。

無料ウェビナー開催中！AIを使ったデザイン実務、実際に見てみませんか？

ここまで紹介してきたのは、意図や判断の基準を言葉にして渡す方法でした。この力が効くのは、実装担当者との連携だけではありません。生成AIを制作に取り入れるときも、何を任せて、出てきたもののどこを人が確認するのか——それを言葉にできるかどうかで、手元に残るものが変わります。
nestsは、Claudeをはじめとする生成AIを「使いこなす」デザイン実務を掲げています。無料ウェビナーでは、現役デザイナーが実際の制作フローを題材に、AIをどこに入れて、どこを人が判断しているのかを実例で解説します。参加は無料です。
回ごとにテーマや扱うツールが変わりますので、セミナー一覧から最新の開催情報をご確認ください。

この記事をシェアする

Twitter

Facebook