大阪の制作会社がコーディングを外注する前に｜デザインデータの不足仕様を洗い出す

トップページのPC版とスマートフォン版は完成した。画像も書き出してある。それでもコーディングを依頼すると、「その中間の幅ではカードを何列にしますか」「メニューを開いた画面はありますか」と質問が戻ることがあります。完成した一枚の画面から、すべての幅や操作状態を実装担当が一意に決められるわけではありません。

大阪の制作会社・デザイナーが実装を外部へ渡す前に必要なのは、全画面を描き切ることではなく、デザインデータから読み取れることと、まだ決めていないことを区別する作業です。この記事では架空の企業サイトを例に、ページ、部品、画面幅、操作状態、素材を対応表へまとめ、誰が何を決めてから実装するかを整理します。価格や納期、特定の会社の対応範囲を一律に決めるものではありません。

PCとスマホの二枚の間を、縮小で埋めない

広い画面で横三列のカードが、狭い画面で縦一列になるデザインがあるとします。その間の幅で三列を維持するのか、二列を挟むのか、本文の長さによって切り替えるのかは、二枚の完成図からは分かりません。写真と見出しの比率、カードの最小幅、並び順まで関係します。「レスポンシブ対応」とだけ書いて実装担当に渡すと、試作後にデザイナーの意図と違うことが分かり、修正が往復します。

MDNのレスポンシブデザイン解説は、固定された端末だけでなく、利用できる幅に応じて内容を組み直す設計を説明しています。ブレークポイントの考え方も、特定の機種名を並べるより、内容が窮屈になったり読みにくくなったりする位置を見て切替えを決めるものです。案件ではこの考え方を、実際の文章や画像で確かめます。機種ごとの固定ピクセル値だけを大量に指定する必要はありません。

まずページの中で、中間幅に弱い部分を探します。横長のナビゲーション、三列のカード、画像と本文の左右組み、比較表、長いボタン文言などです。幅が狭まった時、何を先に折り返し、何を積み重ね、何を常に表示するかをデザイナーと元請で決めます。実装担当から提案してもらう部分があれば、その範囲と確認のタイミングを書きます。「提案してほしい」は、勝手に確定してよいという意味ではありません。

幅そのものだけでなく、文字量の幅も試します。仮原稿の短い見出しでは三列で収まっても、公開用の長い商品名や部署名では重なることがあります。実際に近い文章を使った代表ページを選び、狭い幅・中間幅・広い幅で見ます。見た目だけを合わせるために文字を画像化するのではなく、折り返しや高さが変わっても情報が残る構成にします。

静止画にない「操作後」を部品ごとに挙げる

デザインデータに通常状態のボタンしかない場合、カーソルを置いたとき、キーボードで選んだとき、押せないとき、送信中のときの表示は未決です。ドロップダウンメニューなら、開いた位置、閉じ方、次の階層、狭い画面での扱いも必要です。フォームでは、必須項目の不足、入力形式の誤り、送信完了、通信に失敗した場合の案内までが一連の画面になります。

すべての状態を詳細な完成図にするかは案件次第です。ただし、状態が存在すること、内容を誰が決めるか、最初に確認する代表部品は明記します。W3CのWCAG 2.2「フォーカスの可視化」は、キーボードで操作する人がどの要素を選んでいるか見えることを求めます。「ホバーの色」だけではキーボードの操作状態を指定したことにはなりません。既存サイトの共通部品を使う場合も、そのフォーカス表示を取り込むか確認します。

タブやアコーディオンは、閉じた状態の図だけでは、開いた後の余白や他の部品との重なりを判断できません。メニューの開閉とフォームのエラーは、少なくとも一つの代表画面で実装前に確認します。後から「想定と違う」と言う前に、状態の一覧をデザインデータのページ名・部品名へ対応させます。

デザインデータと実装未決事項の対応表

次は、架空の制作会社が企業サイトのデザインを外部へ渡す場合の表です。特定の制作ツールや実装方式を指定するものではありません。「ない画面」をただ列挙するだけでなく、参照するデザイン、現時点の判断、決める人、いつ試すかを一行にします。既存の共通部品を再利用する場合も、その参照先を書きます。

デザインデータの箇所	分かっていること	実装前の未決事項	判断者・確認する画面
トップ／カード一覧	PCは三列、スマホは一列	中間幅の列数、長い見出しの折返し	デザイナーが方針、元請が代表ページ確認
共通ナビゲーション	閉じたPC・スマホ画面	メニュー展開、閉じ方、キーボード操作	デザイナーと実装担当が試作で確認
問い合わせフォーム	通常入力画面	必須漏れ、送信中、失敗、完了の文言と配置	元請が原稿、実装担当が動作、顧客が内容承認
実績一覧カード	写真と見出しの基本形	写真なし、長文、掲載数が増えた場合	元請が実データ、デザイナーが可変状態確認
素材と書体	画面上の見た目	使用許可、書き出し形式、代替書体	素材提供者と元請が権利・納品物確認

この表には、決まっていない内容を「未決」と書きます。実装担当が提案するなら「提案待ち」、顧客の原稿が必要なら「顧客確認待ち」と区別します。どちらも実装担当への丸投げにしないためです。各行にデザインデータのページ・フレーム名と版を入れ、あとでどの指示の話か探せるようにします。

重要度もすべて同じではありません。メニューの開閉やフォームのエラーは主要操作に直接関わり、代表画面を早く決めたい部分です。細い余白の数値は、共通のルールを決めて試作後に調整できる場合があります。「実装を始めるために必要」と「実装後に確認できる」を分けて、最初の相談で優先順位を付けます。元請と実装担当が合意した内容は、チャットの一言だけでなく対応表へ戻します。

デザインの確定画面から未決の幅・操作状態・素材を洗い出し、判断者と確認画面へ結ぶ図 — 架空の制作案件の引渡し設計です。特定案件の仕様や受託条件を示しません。

部品の一覧は、ページ数より実装量を見えやすくする

トップ、会社概要、実績、問い合わせという四ページがあっても、同じ見出しやカードを使うなら共通部品としてまとめられます。反対に、一ページしかなくても、動くメニュー、絞り込み、入力状態が多ければ実装と確認の対象は増えます。ページ数だけで作業範囲を伝えず、繰り返す部品と、例外の部品を分けます。

例えば実績カードは、画像の有無、タイトルの長さ、カテゴリの数、リンク先の有無によって高さが変わります。デザインデータの一例が最もきれいな状態だけなら、実際の原稿を入れた時の扱いを決める必要があります。カードの余白や切り詰めを実装担当が提案するなら、元請がどのデータで確認するかを渡します。ダミーテキストだけで受け取ると、公開直前に崩れが見つかります。

共通部品の変更が複数ページへ波及することも、対応表に示します。ヘッダーの高さを変える、ボタンの文字を伸ばす、アイコンを差し替えると、個別ページのレイアウトへ影響します。「この一枚だけ修正」と思って依頼しないよう、部品と使うページの関係を確認します。デザイナーが最終的にどの版を承認したかも残します。

素材、原稿、版を「使ってよい状態」で渡す

デザインツール内に画像が表示されていても、実装用の素材が用意されたとは限りません。元画像、書き出したサイズ、背景の透過、使用許可、代替テキストをどこまで提供するかを整理します。写真のトリミング位置が画面幅で変わる場合は、どの被写体を残したいかを示します。小さな画面で主題が切れるなら、別画像を用意するのか、表示位置を変えるのかを相談します。

書体もデザイン上の名前だけでは足りません。Webで使えるライセンス、読み込み方法、代替書体にした時の行数や幅を確認します。特殊な書体を使えない場合、見出しが一行増えた時にレイアウトが保てるかを代表ページで見ます。ロゴやアイコンは元データと利用条件を確認し、必要な背景色や高解像度表示に合う形式を渡します。

原稿が仮の場合は、どこが確定で、誰がいつ差し替えるかを示します。入力欄の文言やエラーメッセージは画面の装飾ではなく利用者への案内です。顧客が承認する内容なら、実装担当の例文をそのまま本番へ残さないようにします。デザインデータにコメントが複数残る場合は、採用した指示を一つにまとめ、古いコメントと分かるようにします。

ファイルを渡す時には、閲覧できるリンクだけでなく、対象ページ・フレーム・最終更新日・確定状態を一覧にします。リンク先に複数の試案が並んでいるなら、着手してよい版を指定します。追加修正のたびに別ファイルを送る運用では、どの版で実装中かが見えなくなるため、変更した部品と影響するページを対応表へ記録します。

実装の試作と受入確認を、同じ問いでつなぐ

外注先へ渡す段階ですべての細部を確定できない案件もあります。その場合は、代表ページや共通部品を先に試作してもらい、中間幅や操作状態の方針を確認します。たとえば、カードが二列へ切り替わる位置をブラウザーで試し、文言が長い実績でも読めるかを見ます。試作で決めた方針を別ページへ展開する前に、元請とデザイナーの確認を入れます。

WCAG 2.2のリフロー基準は、原則として狭い表示で情報や機能が失われず、二方向のスクロールを求めないことを扱います。表のように二次元の配置が意味を持つ部分には例外があります。案件でアクセシビリティ基準をどう適用するかは対象範囲と試験方法を合意し、そのうえで「本文の横はみ出しはない」「表だけ横へ動かせる」など、実画面で確かめる条件へ落とします。規格名を書くだけで個別の受入確認を済ませたことにはなりません。

確認画面を受け取った元請は、デザインとの見た目の一致だけでなく、決めた状態が実際に操作できるかを見ます。メニューをキーボードで開閉できるか、フォーカスが見えるか、フォームの必須漏れが伝わるか、送信完了後に次の行動が分かるか。仕様相談の表に書いた問いを、そのまま受入時の確認項目にする形です。未決事項が解消されたら、採用した判断と確認結果を同じ行へ残します。

検証の対象は最も整った一画面だけにしません。文章が長い画面、画像がない画面、入力を間違えた画面を選び、デザインの方針が保てるか試します。中間幅の確認では、指定したピクセル値の前後も見て、切替えの境目で文字やボタンが重ならないか確かめます。問題が出た時は画面幅と部品名、操作、期待した表示を添えて戻すと、実装側が修正箇所を特定できます。スクリーンショットだけで済ませず、再現できる条件を記録します。

既存のWeb制作の要件定義の記事は、目的・範囲・責任分界・受入条件をサイト全体で整理しています。ここで必要なのは、デザインがある状態から実装へ進むため、描かれていない幅と操作状態を具体的に埋めることです。ページ数や作業人数の話へ広げず、対応表から実装前の質問と受入時の確認を対応させます。

大阪で依頼先を検討する際も、場所だけで対面の回数や対応速度を推定しません。みやあじよのWeb制作パートナー案内は、制作会社・クリエイター向けに、部分的なデザイン・コーディング、必要に応じたヒアリングやディレクション等を紹介しています。今回のデザインデータと未決事項を示し、どこを元請が決め、どこを仕様相談から依頼するか確認しましょう。