Web制作でデザインを決める前に決めておくこと6つ｜CMS・HTML・CSS設計

デザインは「箱」の中に入る

静的なHTMLだけで作るなら、デザイナーが描いたとおりに組めます。

1ページずつHTMLを書いていけるからです。

CMSを使う場合は違います。

CMSは決められた仕組みに沿ってHTMLを出力します。

記事本文、記事一覧、カテゴリページ、パンくずなど、それぞれにある程度決まった構造があります。

この構造を知らずにデザインを決めると、実装の段階で「この形にはできない」という話が出てきます。

もちろん、できないとは限りません。

ただし、その場合はCMSが出力するHTMLを変更したり、テンプレートを調整したりする作業が発生します。

つまり、デザインを自由にするほど、実装側の作業が増える場合があります。

だからデザインを決める前に、使うCMSがどのようなHTMLを出力するのかを確認しておく。

それだけでも、後からの手戻りを減らせます。

どこがCMS管理で、どこが固定なのか

次に決めておきたいのが、サイトのどこをCMSで管理するのかです。

同じ「1ページ」に見えても、中身の性質は違います。

• 毎回変わる……記事のタイトル、本文、日付、カテゴリ
• 時々変わる……ナビゲーション、お知らせ、キャンペーンの帯
• ほぼ変わらない……ロゴ、フッターの会社情報、著作権表記

この区別をせずにデザインを進めると、更新できないことを前提にしたデザインができてしまいます。

よくあるのが、見出しやタイトルを画像にしてしまうケースです。

見た目は自由になりますが、文字を変更するたびに画像を作り直さなければなりません。

更新頻度の高い場所にこの方法を使うと、運用の負担が増えます。

デザインを考える前に、

「誰が、どこを、どのくらいの頻度で更新するのか」

を決めておく。

これだけでも、運用しやすいサイトになるかどうかが変わります。

文章の長さは、想定より振れる

デザインカンプでは、タイトルがきれいに1行に収まっています。

ところが、実際の運用では2行、3行になることがあります。

これは当社でも実際に起きました。

ブログの記事一覧を、日付・カテゴリ・タイトルの横並びにしたのですが、実際の記事タイトルが長く、スマートフォンでは3行に折り返しました。

レイアウトが完全に崩れたわけではありません。

ただ、想定していた見た目とは違いました。

先に「長い場合」を考えておけば、一定の文字数を超えたら縦積みにする設計も最初から入れられます。

少なくとも、次の3つは決めておいたほうがいいでしょう。

1. タイトルの想定文字数と、最大何行まで許容するか
2. 想定を超えた場合に、折り返すのか、省略するのか
3. 画像がない記事をどのように表示するのか

特に3つ目は忘れがちです。

画像ありきのデザインは、画像のない記事を公開したときに破綻することがあります。

CSSをどこまで共有するか

ここは当社で実際に痛い目を見た部分です。

コーポレートサイトとブログのデザインを揃えたかったため、ブログ側にCSSを持たせず、本体サイトのCSSをそのまま読み込む構成にしました。

CSSの管理場所を1つにできるため、片方だけ古くなるといった問題を防げます。

しばらくして、記事本文の箇条書きから「・」が消えていることに気づきました。

原因は本体サイトのCSSでした。

ナビゲーションを組むために書いていた1行が、記事本文のリストにも適用されていました。

ul { list-style: none; padding: 0; margin: 0; }

ナビゲーション用としては、よくある指定です。

ただ、CSSを共有しているため、記事本文にも効いてしまいます。

これはCSSを共有する構成では避けにくい問題です。

デザインを1か所で管理できる利点と、別の場所に影響を与える欠点は、同じ仕組みから生まれます。

だからこそ、最初に共有範囲を決めておく必要があります。

• CSSを共有するのか、分けるのか
• 共有する場合、記事本文に影響を与えない範囲をどうするのか
• 全体を初期化するような指定を、どこに書くのか

サイト全体の構成については、静的ページとCMSを1つのドメインで動かすでも詳しく書いています。

見出しの階層は、装飾ではない

見出しのタグを、文字の大きさで選んでしまうことがあります。

「ここは少し小さくしたいからh3にする」という選び方です。

気持ちは分かります。

しかし、これをやるとHTMLの文書構造が壊れてしまいます。

見出しの階層は、単なるデザインではありません。

文章やページの骨格です。

そして現在、その骨格を読むのは人間だけではありません。

• 目次の自動生成が、正しい階層をたどれなくなる
• 検索エンジンが、ページ内の話題の区切りを判断しにくくなる可能性がある
• AIなどがページの構造を理解するときに、情報の関係が分かりにくくなる可能性がある

大きさは見た目、階層は意味です。

文字を小さくしたいだけなら、CSSで調整できます。

見た目を理由に見出しタグを変更する必要はありません。

この考え方については、サイト設計とSEO・AEOにもまとめています。

画像は、書き出したら終わりではない

デザインの成果物として画像を書き出すと、それで終わったように感じます。

しかし、実際のWebサイトでは、その後にも決めることがあります。

• SNSで共有されたときの画像……OGP画像など、どの画像を表示するのか
• 代替テキスト……誰が、どのような基準で設定するのか
• 画像の比率……一覧と記事内で比率が違う場合、どのように切り抜くのか
• 画像がない場合……空欄にするのか、既定の画像を表示するのか

当社は、そのうちの一つを忘れていました。

設定では画像を参照しているのに、ファイルそのものが存在しない状態が続いていました。

SNSに記事を共有するまで気づきませんでした。

画像はデザインの仕事なのか、実装の仕事なのか、運用の仕事なのか。

境界が曖昧になりやすい部分です。

だからこそ、誰が何を担当するのかを最初に決めておく価値があります。

誰が更新するのか

最後に、実は一番大きな項目です。

サイトを更新するのが、パソコンに不慣れな人なのか。

それとも、制作者が毎回対応するのか。

ここでデザインの前提が変わります。

サイトを運営する本人が更新するなら、多少内容が変わっても崩れにくいデザインにしておく必要があります。

文字数が増えても、画像がなくても、それなりに成立する形です。

一方、制作者が更新を担当するのであれば、多少繊細なデザインでも維持できます。

ただし、その分だけ更新のたびに費用と時間がかかります。

どちらが正解という話ではありません。

問題なのは、更新する人を決めないままデザインを進めることです。

そうすると、「繊細なデザインを、Webに不慣れな人が自分で更新する」という、運用しにくい組み合わせになってしまいます。

デザインを決める前に、誰が更新するのかまで決めておく。

これはWeb制作では意外と重要なポイントです。

まとめ

デザインを最後に回すべき、という話ではありません。

デザインを決める前に、デザインの前提になる部分を決めておく。

という話です。

先に確認しておきたいのは、次の7つです。

1. 使う仕組みが、どのようなHTMLを出力するのか
2. どこがCMS管理で、どこが固定なのか
3. 文字数と行数の幅、画像がない場合をどうするのか
4. CSSをどこまで共有するのか
5. 見出しの階層をどのように扱うのか
6. 画像に関する作業を誰が担当するのか
7. 誰がサイトを更新するのか

どれも派手な作業ではありません。

しかし、ここを飛ばしてデザインを進めた分は、実装か運用のどこかで戻ってきます。

当社も最初からすべてできていたわけではありません。

CSSの干渉や画像の設定など、公開後に気づいて直したものもあります。

だからこそ、実際に作って分かったこととして書いておきます。

Webサイトは、見た目だけを作れば完成するものではありません。

誰が、何を、どのように更新するのか。

CMSが何を出力し、それをどのようにデザインへ組み込むのか。

そこまで決めて、初めて「運用できるデザイン」になります。