Figmaの自動レイアウトをWeb実装へ渡すには｜可変文字・幅・CMS更新の確認表

Figmaではきれいに並ぶのに、Webへ実装すると長い見出しが切れる。WordPressで項目を増やすと、支給デザインと違う配置になる。こうした問題を減らすには、画面の寸法だけでなく「何が変わると、どう並び直すか」を引き継ぎます。

この記事は、デザインを支給して実装を依頼する制作会社のディレクター・デザイナー・実装担当向けです。Figmaの自動レイアウトを読み、文字量と幅、画像と件数、CMSで変える範囲を実装と検収へ対応させます。特定の案件を再現した事例や、工数削減率を示す記事ではありません。

1. 正本と対象の部品、変更できる内容を決める

参照するFigmaファイルとページ・フレーム、承認した版、対象の部品を揃えます。PC/SPという名前だけで判断せず、幅、実際の文章、画像、表示状態を記録してください。検討途中の別案を、最終仕様として実装しないようにします。

更新後も保ちたい関係を言葉にする

「カードを同じ高さにする」「見出しが長いときは行を増やす」「件数が少ない最終行も左から並べる」など、結果を文章で残します。これは仕様の記入例で、すべてのサイトに同じルールを採用する提案ではありません。

原稿を差し替える人、デザインを決める人、実装と検収の担当が別なら、未決定事項と確認先も記します。着手・環境・公開までの依頼全体はWordPress実装の引き継ぎと検収へ整理し、この記事では可変レイアウトの合意へ集中します。

2. 自動レイアウトの方向と間隔を読む

Figmaの自動レイアウト公式ガイドでは、フレーム内の方向、間隔、内側の余白、整列やサイズ変更を説明しています。部品の追加・削除・文字変更で、どの関係が維持されるかをデザイン側で確認できます。

水平・垂直・グリッドの配置、親のpadding、項目間のgapを読み、見た目の空白を一つの値へまとめないようにします。別のフレームで作った空白や、配置の流れから外した要素も確認します。絶対座標が見えることだけで、Webでもすべてを絶対配置にするとは決めません。

Figmaの設定とCSSは、名前や見た目が似ていても同じ実行環境ではありません。ブラウザーの文字・画像・画面幅、HTML構造と操作順を含め、保ちたい関係から実装方式を選びます。

3. Hug・Fill・Fixedを、実装の完成条件へ言い換える

公式ガイドのHug contents、Fill container、Fixed width/heightは、内容や親との関係に応じた寸法の扱いです。名称をそのまま一つのCSS値へ機械的に置き換える前に、横と縦、親と子、最小・最大の条件を確認してください。

設定名だけでは、長い文章の扱いが決まらない

たとえば固定高のカードで長い文を入れるなら、行数制限・全文への移動・高さの可変化を比べます。大切な条件を、実装側の都合で見えないまま切らないようにします。省略を使う場合も、何を読める状態とするかを先に合意してください。

4. CSSは、行列と内容の関係から選ぶ

一つの軸に沿った配置と、複数行の列をそろえる配置では、FlexboxやGridの選び方が異なります。MDNのFlexbox基本概念を参照し、Figmaのフレーム名だけで実装を固定しません。

Flexboxの縮小や基本サイズ、読む順番はFlexboxの実装ガイドへ進めます。ここでは、そのコード例を選ぶ前に、可変時の振る舞いを仕様へ書くことが目的です。画像で見える並びとHTMLの順序も分けてください。

再現のために各要素へ座標を重ねる実装は、文字量や件数が変わる条件も確認します。通常の流れ、間隔、余白で保てる関係を優先し、必要な重なりだけを対象として設計します。デザインの見た目を変える判断は、実装者だけで確定しません。

5. 文字・画像・件数の変化を同じ部品で試す

一つのカードやナビについて、短い/長い見出し、本文なし/長文、画像なし/異なる比率、0件/1件/複数件を比べます。実際に運用する情報を使えるなら、掲載条件を確認したうえで試験します。架空の材料を使う場合は、試験用であることを区別します。

デザインにない状態は、実装前に確認する

0件時の案内、リンク先が未決定のボタン、画像がないときの枠、長い英数字などを記録します。デザインにないから表示しない、必ず仮画像を出す、という一律の判断をせず、読者と更新担当の必要から決めます。

狭幅へ変えた状態と、そこから広げた状態で、順序・行・余白を確認します。スマホでタップできること、キーボード移動が内容の順と合うことも検収に含めます。Figmaのプレビューが動くことを、そのまま公開の動作確認とはしません。

6. WordPressで更新する範囲を、寸法の仕様へつなぐ

更新担当が変えられる見出し、文章、画像、リンク、件数を部品ごとに一覧にします。CMSの入力欄が自由に長文を許すのに、表示は一行しか読めない設計になっていないかを確認してください。必須/任意の値と、空の場合の扱いも揃えます。

文章量の条件を設ける場合は、必要な説明を収められるかと、更新時に担当者へ条件が伝わるかを確認します。表示を守るためだけの短い上限が、顧客の判断に必要な条件を削っていないかも見ます。入力画面と公開画面を別々に検収することが必要です。

共通部品を変更するときは、使っているページと影響範囲を確認します。新しい見た目を一か所で試したことだけで、全使用先への反映を終えたと扱いません。共有の正本、個別の例外、次の更新者を対応させます。

7. 比較条件と差分を残して検収する

承認したデザインの幅と内容、実装URL、ブラウザー、確認した状態を揃えます。余白・文字・画像だけでなく、内容が増えた条件と操作を比較してください。デザインの変更と実装の不具合は、理由と承認の対象を分けて記録します。

一覧表で、未確認を残したまま完了にしない

部品、可変条件、期待する表示、実際の表示、修正担当、再確認の結果を残します。代表の一画面が合った確認と、合意した状態が全て通った確認は別です。判断する人へ未確認の条件も渡し、検収の合意を揃えます。

確認用サイトから公開へ反映した後も、同じ内容と幅で読み戻します。差分と戻し方、更新場所、使った素材と権限を引き継いでください。自動比較は変化を拾う補助に使い、空いた時間を読める内容と操作、未決定の条件の確認へ回します。

8. Acquaへ、可変時の仕様と検収を渡す

制作会社はWordPress実装支援へ、Figmaの正本、PC/SP、対象部品、可変文字・画像・件数、CMSの入力範囲、検収と公開担当を共有できます。未決定の状態は質問として残し、実装者が推測した値を正式仕様にしないようにします。

企業の担当者はWeb制作・運用の案内へ、更新したい内容と現在困る表示を伝えられます。必要な仕様整理、HTML/CSS・WordPress実装、公開検収と更新手順を相談する範囲として分けます。

解決状態は、合意したデザインと可変条件で情報が読め、操作でき、CMS更新後も確認方法が分かることです。相談窓口には、正本と困る状態を分かる範囲で伝えてください。Figmaの設定だけで、工数・公開品質・将来の全更新を保証するものではありません。