Figma、画像、印刷物、参考サイトなどの支給物は、完成時の見た目や方向性を共有するうえで重要です。一方で、一つの画面だけでは、文章量が変わる場合、画像がない場合、画面幅が変わる場合、操作中の状態まで判断できません。
私たちも以前は、まず支給された画面へ近づけることに意識が向きがちでした。しかし、ページや担当者が増えるほど、それだけでは判断が揃いません。そこで、支給物の意図を読み取り、共通ルール、個別の例外、変化する条件、確認が必要な箇所へ分けてから実装するようになりました。
最初に、支給物が決めている範囲を確認する
支給物に描かれていることと、実装時に新たに決めることを分けます。色、書体、写真、余白、レイアウトが示されていても、すべての画面幅、文章量、操作状態、更新後の組み合わせまで定義されているとは限りません。
- 支給物の種類と、正として扱う版
- PC・スマートフォンなど用意されている画面幅
- 固定する表現と、実装側で補う振る舞い
- 未定義箇所の確認先と、判断を記録する場所
- 変更が入ったときに差分を反映する対象
不足を指摘するためではなく、支給物が担う役割と、実装設計が担う役割を揃えるための確認です。
代表画面を一つ実装し、共通ルールを抽出する
全ページを同時に進める前に、見出し、本文、画像、ボタン、一覧、フォームなど主要要素を含む代表画面を選びます。そこでHTMLの構造、クラス、余白、画像の扱い、画面幅による変化を確認します。
代表画面で合意した内容を、個別ページの完成見本だけに閉じず、再利用できる部品とルールへ戻します。後から参加する担当者も同じ判断を使えるため、ページごとのばらつきと大きな作り直しを抑えられます。
共通部品と例外を同時に整理する
すべてを同じ部品へ押し込むと、個別ページの要件が不自然になります。反対に、画面ごとに作ると、似た要素の見た目や動作が少しずつ変わります。
見出し、ボタン、カード、注記、画像、フォームなどを共通部品として整理し、色違い、配置違い、長文対応、画像なしなどを許容する変化として定義します。それでも共通化できないものだけを個別の例外として残し、理由も共有します。
印刷物や画像は、Webで使う要素へ分解する
印刷用デザインや一枚画像をそのまま縮小すると、スマートフォンで文字が読めず、検索や読み上げにも情報が伝わりにくくなります。文字、写真、背景、装飾、リンクやボタンに分け、可能な範囲でHTMLとして再構成します。
読む順序、画面幅に応じた並び替え、画像の切り抜き、色空間、解像度もWeb向けに確認します。見た目を再現することと、情報を利用できる形にすることを同じ作業として扱います。
文章量・件数・画像の有無を仕様に含める
短い仮原稿と同じ比率の画像だけで組むと、本番原稿を入れたときに高さや折り返しが変わります。最短・最長の見出し、複数行のボタン、画像なし、件数なし、最大件数を試し、崩れたときに縮めるのか、伸ばすのか、省略するのかを決めます。
CMSで更新する範囲は、入力できることだけでなく、どの条件まで同じ品質で表示できるかを確認します。文字数制限が必要なら、画面を合わせるためではなく、情報の役割と運用上の理由から決めます。
動きは、開始から終了までを言葉にする
参考サイトや動画で示された動きは、「同じように動かす」だけでは担当者ごとに解釈が変わります。開始条件、順序、継続時間、終了状態、再訪時の挙動、操作できるタイミングへ分解します。
読み込みが遅い場合、端末性能が低い場合、動きを抑える設定が使われている場合も想定します。演出が動かなくても情報と操作が失われない形を先に決めます。
変更は、正となる資料と影響範囲を揃えてから反映する
制作中にデザイン、原稿、機能要件が更新されたとき、どのファイルが最新か分からないまま個別修正すると、別ページへ古い状態が残ります。変更元、変更理由、対象ページ、共通部品への影響、確認者を一組で残します。
共通部品の変更は代表画面だけでなく、使われている全ページを確認します。個別対応にする場合は、共通ルールを変更しない理由を記録し、次の修正で判断が逆戻りしないようにします。
複数人で作るときは、判断を画面の外へ出す
担当者が完成画面を見比べながら各自で推測する状態では、確認のたびに同じ議論が繰り返されます。HTML構造、部品名、余白、画像書き出し、画面幅、動作、例外を短いルールとして共有します。
確認も最後にまとめず、代表画面、共通部品、個別ページの順に行います。早い段階で判断基準を揃えることで、後半は見た目の差分ではなく、本来確認すべき内容と操作へ時間を使えます。
この方法が向いているケース
- Figma、画像、PDF、印刷物、参考サイトから実装する
- 複数の制作会社や複数の実装担当者が参加する
- 同じ部品を多数のページで利用する
- CMSで文章量や画像の有無が変わる
- レスポンシブや動作仕様が完成図だけでは分からない
個別の確認だけで進められるケース
一画面だけの短期ページで、文章、画像、画面幅、動作がすべて確定し、一人で実装する場合は、大きな部品表や詳細な仕様書を作る必要はありません。それでも、どの支給物を正とするか、未定義箇所を誰が決めるか、公開前にどの画面幅を確認するかは揃えます。
実装仕様への変換チェック
- 支給物の種類、最新版、決定済みの範囲を確認したか
- 代表画面でHTML構造とレスポンシブを確認したか
- 共通部品、許容する変化、個別の例外を分けたか
- 文章量、件数、画像なしなどの境界を試したか
- 動きの開始条件、終了状態、代替表示を決めたか
- 変更時の正となる資料と影響範囲を揃えたか
- 複数人が同じ判断を使える短いルールを残したか
- 完成画面だけでなく、内容と操作を確認したか
