webサイトの画面設計書（ワイヤーフレーム）で押さえるべきこと。
この記事の内容
webサイトの企画・設計に関わるwebディレクター向けに書いています。
webサイトの画面設計をすることになり、どう進めていいかわからない。
どういうポイントを押さえるべきかわからない。
そういった疑問を持っている方向けに書きました。
この記事を書いているわたしは、東京のweb制作会社で、webディレクターを7年ほど経験し、数多くの大手企業のサイト設計や課題解決の指針策定などに関わっています。わたしが設計に携わったwebサイトは、PV数や設定したコンバージョン数が大きく伸び、明確な成果を出しています。
webサイトの画面設計書（ワイヤーフレーム）を書く際に押さえるべきこと。
webサイトのページのレイアウトやコンテンツを定義・設計するものを「画面設計書」または「ワイヤーフレーム」と呼びます。
個人的には、ワイヤーフレームという言葉はあまり好きではありません。
なぜなら、ワイヤーフレームという言葉が意味する「枠組み」という意味以外のものも定義すべきだからです。
なので、自分は「画面設計書」という言い方をしています。
画面設計の書き方に、これという決まったパターンや教科書のようなものは存在していません。ここでは、一例として、自分のやり方を紹介します。
ページの種別ごとでのチェックポイントも別記事でまとめているのでそちらも参考ください。
webサイトの画面設計書では「コンテンツ、エリア定義、構成要素、機能」を定義。
画面の設計の前に、webサイト全体の目的や、各ページで伝えるべきテーマというものは、サイトの基本設計のステップで定義されている前提です。
画面設計書次の4点を定義することを意識するとスムーズに進みやすいです。
- コンテンツ
- エリア定義
- 構成要素
- 機能
この4つの定義については「こうあるべき！」という決まり事があるわけではなく、わたし個人として経験からそう考えているものです。
これが定義できていれば、デザインを作るデザイナーも「どうしたらいいか分からない」ということはないはずです。
では、順番にそれぞれの項目について見ていきます。
1. コンテンツ
コンテンツは「ページに掲載する情報そのもの」で、素材のようなものです。
まずはコンテンツありき。
コンテンツをいかに魅力的に見せられるか、ユーザーの課題を解決するものになっているかどうかという視点が大事です。
コンテンツは、テキストだったり画像だったり。
webサイトのリニューアルであれば、リニューアル前の既存サイトから引っ張ってくることもあります。
しかし、その前に、なぜリニューアルするのか。リニューアルすることでどういう課題を解決するのか、という視点で検討する必要があります。
コンテンツそのものが問題であるケースも多いので、アクセスログの分析結果などをもとに、コンテンツそのものもクライアントに提案してください。
コンテンツの元素材の準備をするのは、（基本的には）web制作会社ではなく、クライアントです。
ただ、その素材をきちんと料理して、ユーザーに伝わる情報に変換してあげるのはweb制作会社の役割だと思います。
「画面設計書に最終的なコンテンツが反映されている必要があるのか？」という質問もあるかもしれません。
それに対するわたしの意見は「YES」です。
なぜなら画面設計書では、「企業側が伝えたいことが端的に伝わるか」、「使いやすいか」、「ユーザーが求めている情報か」そういう検証が行われるべきだからです。
たまに、ワイヤーフレームのサンプルとして本文領域に「テキストテキストテキスト」とかって書いてあるのを見ます。
それは、あくまでサンプルデータだったとしても、それだとあんまり作る意味がないと思ってます。
「テキストテキストテキスト」では、そのコンテンツがユーザーの課題を解決するものになっているか、表現として正しいかという検証もできません。
画面設計に必要なのは「コンテンツファースト」の考え方です。
2. エリア定義
エリア定義とは、画面設計を行うページについてどのように領域を分けるかという定義です。
建築物の建設計画や都市計画において、空間や用地をどのようにエリア分けするか、といった定義の言葉で「ゾーニング」と言われたりもします。
このエリア定義は、次の2つのレベルに分けて考えると整理しやすいです。
サイト全体の共通ルール
サイト全体に共通する、ページのエリア分けの定義です。例えば、
- ヘッダー領域
- フッター領域
- コンテンツ領域
- サイドナビ領域
といったエリアの定義がそれにあたります。
コンテンツの情報分類とその優先度
コンテンツ領域内における機能や情報の括りです。例えば、
- メリットを強く訴える領域
- スペック詳細を伝える領域
- 購入の後押しする安心感を伝える領域
- コンバージョンやシェアを促す領域
といったエリア定義です。
ユーザーのモチベーションや感情をイメージしつつ、目的の理解やコンバージョンアクションにつながるかどうかという視点で領域を定義していきます。
そういう意味で単にエリアを区切るという意味だけではなく、何を優先するかという考えもここに含まれてきます。
3. 構成要素
ページを構成する要素です。例えば
- 見出し
- テキスト本文
- 画像
- 画像とテキストのセット
- コンバージョンボタン
- リンクリスト
- リスト
- 表
そういったものです。
構成要素は「コンポーネント」という単位で部品化し、サイト内のあらゆる場所で汎用的に使われます。
その最小パーツを定義しておくことで、「情報構造」と「その中に入るコンテンツ」を切り分けて考えることができます。
ちなみに、スマホにしたときにどうなるか。その定義もここに含みます。
例えば、どこでカラム落ちさせるか、スマホならではの表示をさせるのか、ということをコンポーネント単位で定義しておくのです。
これをしておけば、定義されたコンポーネントベースで、ページのコーディングができるので、全ページのページデザインを作成、ということがなくなります。
4. 機能
ここでいう機能というのは、ユーザーがアクションを起こすとどうなるか。何ができるのか、というところです。
例えば、リンク先、画像のスライドショー、アコーデオンメニューの動きといったものの定義です。
動きというのはアニメーションという意味ではなく、例えばアコーデオンメニューのUIを例にすると、クリックしたら開くのか、マウスオーバーで開くのか、閉じるにはどうしたらいいのか、そういったことです。
とはいえ、CMS管理項目との連携、複合検索機能の詳細、といった複雑な機能の定義を画面設計書にすべて含めることはできません。
そういう場合は、別途「機能設計書」を作成し、そちらで機能そのもののすり合わせを行う必要があると思います。
webサイト制作の設計フェーズがキモ
webディレクターはやることが多いです。
そんな状況下で、画面設計を行うのは大変、という声もあるでしょう。
わたしが想像するに、そうなりがちなのは、正直、設計フェーズを期間としてきちんと確保されていないことが原因だと思うのです。（違ったらごめんなさい。）
webサイトのリニューアルであれば、画面設計のすりあわせで最低1ヶ月は必要です。
その時間を取れていないのであれば、まずは、「建築物の設計」のお話などを例にお客さんに説明していくことをお勧めします。
要件定義、設計、デザイン、コーディング、開発、あらゆるものが並行して進んでいる状況になってしまうと、webディレクターのタスクは進行管理だけでパンパンになってしまいます。
まず「設計フェーズで正解を作る」それが完了して初めて、「デザインフェーズに進む」ようにプロジェクトマネジメントすると、時間の確保もしやすいです。
それに関連して、設計とデザインが並行してしまう理由の１つに、
「デザインを見てみないとわからない」とクライアントが言い出すことがあります。
なぜこういうことが起きるかというと、「完成形をイメージ出来る情報が画面設計書の中に無いから」です。
「テキストテキストテキスト」という中身のない設計をクライアントに見せたりはしてないでしょうか？
PowerPointで作られた、前後の繋がりがわからない、1ページをイメージできないワイヤーフレームになっていないでしょうか？
設計書は、最終形をイメージできるものであるべきです。
イメージできないものをお渡ししているのであれば、そこの責任はクライアントではなくwebサイトの設計者にあります。
「デザインを見てみないとわからない」と言われて、「じゃ、デザイン進めて持ってきますね。」となり、設計とデザインが同時に進み、進行がごちゃごちゃになる失敗を何度か見てきました。
最終的には、デザイナーの意見を取り入れ、意匠はデザイナーに任せますが、クライアントから「デザインを見てみないとワイヤーフレームでOKは出せない。」という状況を引き起こしてはいけないと思ってます。
まとめ
今回は画面設計書で抑えるべきポイントを紹介しました。
お伝えした、コンテンツ、エリア定義、構成要素、機能について正解を定義する、という前提で臨むと、設計の質、また効率も格段に上がると思います。
参考になると幸いです。
