つくるフェーズ
運用前提のデザイン 更新は自由、構造は守る
Webサイトは、公開して終わりではなく、運用され続けるものです。
更新を重ねる中で、見出しが崩れ、レイアウトが壊れ、「最初は整っていたはずのデザイン」が少しずつ劣化していくケースは少なくありません。
Flying High Works(FHW) では、更新を制限するのではなく、更新しても崩れない前提でデザインと構造を組むという考え方を採っています。
このページでは、運用フェーズで起きやすいズレを前提に、どのように設計しているかを整理します。
想定する更新担当と役割
FHWが主に想定している更新担当は、社内のディレクターです。
ディレクターは、
- お客様側のWeb担当者との窓口となり
- 更新内容を整理し
- 実際の反映や指示を行う
という立場にあります。
そのため、「誰が触っても崩れない」ではなく、「ディレクターが判断しやすく、守りやすい構造」 を前提に設計します。
運用で崩れやすいポイント
運用フェーズで特に崩れやすいのは、次のような箇所です。
- 見出し階層(H2/H3の飛び)
- 画像サイズや比率のばらつき
- カード数の増減
- テキスト量の増減
- 改行・装飾の多用
- 意図しないHTML編集
特に、お客様側で直接編集された場合や、Git管理外で修正された場合に構造が崩れるケースが目立ちます。
ガイドは「制限」ではなく「指針」
FHWでは、更新を厳密なルールで縛ることはしていません。
一方で、判断に迷わないための指針は重要だと考えています。
明文化された専用ガイドがあるとは限りませんが、
- Backlogに残された設計意図
- 過去のやりとりや判断理由
- 実装時に共有された前提
これらが、実質的なガイドとして機能します。
見出し階層は「構造」として扱う
見出しは、見た目を整えるための要素ではありません。
- 情報のまとまり
- ページの構造
- 更新時の判断基準
として扱います。
そのため、見出し階層は 自由に変更できる装飾ではなく、構造として固定するものとして設計します。
画像は自由度と安全域を両立させる
画像については、
- 比率や最低条件を決める
- すべてを固定せず、自由度も残す
というバランスを取ります。
これにより、
- 更新担当が迷わず差し替えられ
- 多少のブレがあっても崩れない
状態を作ります。
カード・一覧は「変わる前提」で考える
カードや一覧系のUIは、
- 件数が変わる
- テキスト量が変わる
ことを前提に設計します。
ただし、実装者の技量やスケジュールによって、この前提が十分に反映されていないケースもあります。
そのため、運用時に無理な更新を行わず、必要に応じて調整・改修できる余地を残します。
CMS操作説明に踏み込まない理由
このページでは、
- CMS(WordPress等)の操作方法
- 具体的な更新手順
には踏み込みません。
重要なのは操作ではなく、構造として何を守るべきかだからです。
このページで伝えたいこと
更新は自由です。
しかし、構造は守る必要があります。
その前提が共有されていれば、
- 引き継ぎが楽になる
- 更新の判断が早くなる
- 長期運用でも品質が保たれる
状態を作ることができます。
FHWでは、運用を前提にデザインと構造を組むことで、継続的に使えるWebサイトを支えています。