顧客も更新する静的サイトに、編集ルールと崩れにくさを設計

CMSを使わず、顧客側でもHTMLとCSSを直接編集するため、納品時の見た目だけでなく、その後にどの範囲をどの方法で変更するかまで設計する必要がありました。ページ追加時にテンプレートを想定外の形で使った場合や、サイト全体のCSSを変更した場合にも、既存ページへの影響を把握できることが重要です。製品ごとに異なる文章量や画像点数、撮影素材、見出しの種類を受け止めつつ、社内担当者が更新しやすく、FHWが保守を引き継ぐ際にも判断に迷わない構成が求められました。

コーディング前に顧客の編集経験、追加予定のページ、触るディレクトリ、利用したいテンプレートの種類を確認し、双方の担当範囲を整理しました。見出し階層、余白、画像比率、ファイル名、CSSの適用範囲をルール化し、代表的な製品ページと追加用テンプレートへ反映。仕様に関する判断はBacklogへ集約し、別の連絡手段で決まった内容も転記して履歴を一本化しました。納品データだけでなく、反映先の環境と公開手順も確認し、顧客による更新とFHWによる追加制作が同じ規則で続けられる形にしています。

オリジナル撮影の写真を企業の信頼感と製品理解へつなげるため、使用箇所とトリミングを構成段階から計画しました。見出し、リード文、製品カード、詳細情報の組み合わせを共通化し、登録する文章や画像が変わってもサイト全体の印象がそろう設計です。静的ページを追加する担当者が迷わないよう、文字サイズ、ウェイト、余白、画像比率の基準を一覧化。デザインにない使い方も想定して複数の表示例を用意し、自由な更新を許容しながらブランド表現が崩れにくい部品へまとめました。

顧客がHTMLとCSSを直接扱う前提で、ページ固有の指定と共通指定を分離し、変更の影響範囲を追いやすい構造にしました。見出し、ボタン、製品情報、画像、フォーム導線などを再利用できるクラスへ整理し、追加ページ用のテンプレートと記述例を用意。命名規則とディレクトリ構成を共有し、サイト全体へ効くCSSを変更する場合の確認箇所も明確にしています。納品後は製品ページ、多言語フォーム、特設ページ、内部SEO、PHP更新に同じルールを適用し、顧客編集部分と保守対応部分を両立させています。