この記事の概要
Webデザインは「最終的にHTMLとCSSで表現される」ことは揺るぎません。
イケてるデザインツールを使おうが、流行りのフレームワークを使おうが、最後に存在するのはHTMLとCSSです。1
というわけで、避けては通れないHTMLとCSS。
コードを書かない人でもある程度は理解しておきたいものです。
この記事では「どんなデザインも最終的に構造化された文書（= HTML）で表されるのだから、初めからそのつもりで作る」を念頭に置いて考え方やトレーニングについて書きます。
細かなタグの使い分けやテクニックというより、文章全般を構造化して捉えるための記事です。
HTMLのテクニック自体は別の記事で書こうと思っています。
Webデザインの前に、日頃のドキュメントを考える
いきなりWebデザインを対象に話を進めると、構造だけでなくあしらいにも目が行ってしまいかねません。
そのため、まずは議事録とかメモとか、より身近なドキュメントを例に出して話を進めます。
時系列で発言を記録しただけの議事録
ある日の議事録のつもりで以下のテキストをご覧ください。
# 会議 2022年12月25日
## 話したこと
- 高橋：今日は「記事を読む」にはどんな機能が必要かを話したい。
- 佐藤：極端な話、リリース時はタイトルと本文だけでも良いのでは？
- 田中：「必要最低限でOK」は賛成。しかし、タグのようなざっくり分類するための機能は必要だと思う。
- 佐藤：とは言え、最初の頃は分類するほど記事数も無いだろうし、良いのでは？
- →タグは不要
- 高橋：記事にリアクションするための機能が欲しい。例えばコメントやLikeなど。
- 田中：最初から必要だろうか？
- 高橋：最初期に使ってくれる人が「このサービスを使ってもリアクションの1つももらえない」という印象を抱いたら、多くの人に広がらないと思っている。
- 佐藤：それはあるが、コメントまで作ると開発が遅くなるかもしれない。一度持ち帰って工数を確認した後判断したい。
- 田中、高橋：OK。
- →リアクション関連の機能は作る方向で、工数を確認して判断
- 高橋：話が戻るけどタグの件、やはり必要かも。タイトルだけでは「この記事を読むべきか」の判断がつかないかもしれない。
- 佐藤：言われてみれば、自分も競合サービスを使う際にタグなどを見て「これは気になる」とか「読まなくても良さそう」とか判断している。
- 結論→タグは必要
内容が理解できないことは無いと思いますが、ただ時系列に沿って発言を記録しているだけです。
結論として「タグ機能を実装する」になっていますが、途中まで読んだ段階では「タグ機能は実装しない」になっていて混乱を生むかもしれません。
また、議論の中に結論が混ざっているのでやや見つけづらいです。
構造化した議事録
次に、文書を少しだけ構造化したバージョンをご覧ください。
# エンジニア向け情報共有サービス ローンチ時の開発スコープについて
## 議題
「記事を読む」にはどんな機能が必要か
### 議論の要旨
- 佐藤：極端な話、リリース時はタイトルと本文だけでも良いのでは？
- 田中：「必要最低限でOK」は賛成。しかし、タグのようなざっくり分類するための機能は必要だと思う。
- 高橋：たしかにタイトルだけでは「この記事を読むべきか」の判断がつかないかもしれない。
- 佐藤：理解できた。他には何かあるだろうか？
- 高橋：記事にリアクションするための機能が欲しい。例えばコメントやLikeなど。
- 田中：最初から必要だろうか？
- 高橋：最初期に使ってくれる人が「このサービスを使ってもリアクションの1つももらえない」という印象を抱いたら、多くの人に広がらないと思っている。
- 佐藤：それはあるが、コメントまで作ると開発が遅くなるかもしれない。一度持ち帰って工数を確認した後判断したい。
- 田中、高橋：OK。
## 結論
### 実装すると確定したもの
- タイトル
- 本文
- タグ
### 次回ミーティングまでにどこまで実装するか確認するもの
- リアクション関連
- コメント
- Like
タイトルがあり、議題と結論が分離しているので概要を把握しやすいのではないでしょうか。
このように、グルーピングする単位や順番を記載する順番を工夫するだけでも見やすくなります。
「すべてに目を通せば同じ情報」なのですが、ぱっと見で分かりやすい方が良いに決まっています。
Webデザインを作る場合
次にWebデザインを作る場合です。
架空のSaasを作るとしましょう。
無秩序な「訴求したいことリスト」
例えば、次のような「訴求したいことリスト」が存在したとします。
機能や訴求が話の趣旨ではないので、全体的に「どこかで見たことあるような話」だけで構成しています。
ページ内に盛り込みたいこと
- 初期設定が簡単にできる
- アカウントの登録
- 既存のワークフローの登録
- 作業の自動化
- それによる高速化
- 多機能だけど、無駄がない
- 複数の機能があるので一括で仕事ができる
- それでいて、無駄な機能は無い
- 乗り換えがしやすい
- インポート機能が優秀
- 1,000社以上で導入されている
- 安心感を訴求
- 料金プランが一番安いものなら業界最安値
- だから乗り換えやすい
- もちろん新規に始めるのも大丈夫
- ノーコードで作れる
- 優秀なソフトでも、操作が難しくて使いこなせないものってありますよね？
- 他のツールとの連携が簡単
- 類似サービスからのインポートもしやすい
- チャットツールなどとの連携
- サポートがしっかりしている
- ヘルプやマニュアルも含む
- プランの種類
- Standard, Professional, Business
- 申し込みフォーム
それぞれの内容をそのままグラフィック化し、この順番の通りにレイアウトすることも、不可能では無いと思います。
ですが、より良くするために構造化の観点で見てみましょう。
1. 「このページは何のためのページ」かを整理する
色々なことが書いてありますが「つまり何を提供するのか」が一言で表されていません。
「煩雑な作業を簡単に自動化できる」と要約2し、まず最初にズバッと言い切るのが良いでしょう。
2. 訴求したい順番とダブりを整理する
先ほどの例では、ざっくり記載すると以下のように話題が変わっています。
- 簡単
- 高速
- 多機能
- 乗り換えやすい
- 安心
- 料金が安い
- 簡単
- 他サービスとの連携（乗り換え含む）
- 安心
- 料金
- 申し込みフォーム
簡単・安心・乗り換え・料金の話題が複数回登場しています。
同じ話題なのに一度で伝えないのはもったいないと言えるでしょう。
ダブっているものをまとめるとこのように整理できそうです。
- 3つの特徴
- 高速
- 簡単
- 多機能
- 多数の導入実績で安心
- 乗り換えやすい
- 料金が安い
- 資料請求フォーム
だいぶスッキリしました。
1と2をあわせて構造化する
上記の1と2をあわせて、少しだけ手を入れると次のように整理できます。
# 煩雑な作業を簡単に自動化できるソフトウェア
## こんなお悩みありませんか？
- 煩雑で時間がかかる仕事が多くて、他のことをする時間がない
- 解消のためにソフトウェアを導入しているけど、難しくて使いこなせていない
- 色々な仕事が複数のソフトウェアにまたがっているので効率が悪い
## 3つの特徴
- 複雑なワークフローを自動化して仕事を高速にできる
- ノーコードで完結するので難しい操作が無い
- 複数の機能が搭載されているのでこれ1つで解決する
## 他社での実績
1,000社以上での導入
- 事例1
- 事例2
- 事例3
## 乗り換えが簡単
インポート機能が優秀
- 具体例1
- 具体例2
## 料金プラン
- Standard
- Professional
- Business
## 資料請求フォーム
- 会社名
- メールアドレス
もうお分かりかもしれませんが、まだビジュアルを作っていないのにマークアップがほとんどできあがりました。
もちろん実際の仕事ではここまで単純ではありませんし、もっと細かなセクション分けなども必要でしょう。
とは言え、このような整理をしておけば後の仕事がスムーズなのがイメージできるのではないでしょうか？
理解しやすいコンテンツを作成できますし、実装時も破綻しづらいので、良いことづくめです。
最後に
例えば、バリバリに実装できないデザイナーだとしても、こういった観点を持ってビジュアルを作るのは重要だと考えています。
逆にマークアップエンジニアは、こういった整理がされていないモックアップが上がってきた際は、構造化の重要性を説いてデータのアップデートを図れると良いかもしれません。
どちらの立場の人にとっても、何かしらのお役に立てば幸いです。
最後まで読んでくださってありがとうございます！
Twitterでも情報を発信しているので、良かったらフォローお願いします！
Devトークでのお話してくださる方も募集中です！