webサイトの画面設計ってどこまでやるの？８つの要素で解説します。
一般的にはワイヤーフレーム言われることが多い画面設計。
その作り方は設計者（Webディレクター）により様々。
フレームとしての大枠だけを定義したものもあれば、
どんなテキストが入るか、どんなイメージ画像が入るか。
まで細かく定義されているものもある。
今回は現実的にどのレベルで定義するのが良さそうか、というところをWebサイト設計歴20年になる自分の経験を踏まえて話したいと思います。
今回の記事は、以前書いた
webサイトの画面設計書（ワイヤーフレーム）で押さえるべきこと。
こちらの記事の内容を拡張するものとお考えいただいて差し支えありません。
制作フェーズを以下のように想定した場合、
- 提案・概算見積
- 調査・分析
- 戦略策定
- プロジェクト準備・環境準備
- 設計
- ベースデザイン・ベースコーディング
- コンテンツ準備
- 開発
- テスト
- コンテンツ移行・公開準備
- 公開
この「設計」部分で何をどこまでやるかという話になります。
以下便宜上、設計者＝Webディレクターという想定で話を進めます。
今回は設計を誰がすべきか、という話には踏み込みません。
会社によっては、デザイナーと呼ばれる職種の人が設計をやるケースもあるようです。
テキスト
全部の情報の中身は作れるわけではない。
提供されたものを加工するか、取材などを通し、ゼロから起こすか。
現実的には、
- H1のタイトル
- H2、H3、H4の見出しレベル
- キャッチコピー
- リード文
これらについては、サイトの設計者が定義・提案すべきだと思います。
もちろんクライアントチェックを経て、ひっくり返されることはあるかもしれませんが、まずは設計者側で提案、提示すべきものです。
画像（写真・図）
ワイヤーフレームに画像をどのような形で含めるべきかは悩ましい問題です。
画像そのものは設計者ではなく、デザイナーが作ります。
設計者がどこまで定義すべきでしょうか？
それは、その画像が
- 写真
- 説明図
のいずれに該当するかで話が変わってきます。
写真の場合
よくあるのは下記のようなパターンだと思います。
グレー地の部分が画像であることはイメージできますが、そこにどのような画像が入るのかは想像つきません。
こういうケースはよくある話だと思います。
なので、個人的には、ストックフォト、もしくはクライアントから提示された素材で
「これがマッチするのでないか」という写真をWebディレクターが画面設計書に含めて提示してしまった方が話は早いと思っています。
具体的な写真選定が難しい場合でも「ビジネスマンが会議しているような写真」というヒントくらいは入れておきたいものです。
説明図の場合
説明図の場合は、大体元になる説明図があることが多いです。
その図がそのままでわかりやすいのか？説明を変えた方が良いのではないか？
そういう判断はWebディレクターがするべきだと考えます。
その上で、可能なら手書きでも構わないので、「こんな図にしませんか？」という趣旨がわかるイメージは、含めておいた方が良いと思います。
私の場合、IPadの手書きノートアプリGoodNotesなどを使ってささっとイメージを書き、それを画像にして、XDやSketchといったアプリで読み込むようにしています。慣れてしまえればそんなに時間がかかるものでもないです。
表
表の扱いが実は画面設計書では一番難しいかもって思っています。
なぜなら、画面設計書を作成ツールに表を組み込む機能を予め備わっていないことが多いから。
そして表って「セルの結合」や「項目ラベルの形」などにバリエーションが多く、一つの型で表現することができないのですよね。
ここで言う画面設計書作成ツールとは、XDやSketchを指しています。
PowerPointやExcelは想定していません。（PowerPointやExcelには表を作る機能は備わっていますが、それを画面設計書に含めるものとして定義するのは難儀ですね。。）
なので、おすすめとしては、表は画面設計書には含めず、Excel等で別ファイルにすることです。
別ファイルの表にIDをつけておいて、画面設計書の方には「ExcelファイルのID●の表を参照」とだけ記載しておくのです。
画面設計書で定義するべきは「サイトとしてのあるべき形」です。
画面設計書に、「製品スペック」や「サービス仕様」などすべて含めてしまうと、その情報の最新化をしていく必要が出てきたりします。
製品スペック情報などは情報量も膨大になりがちで、更新も頻繁だったりします。
デザインフェーズに入ってから、画面設計書情報のメンテナンスが入ることは避けたいです。
情報のメンテナンスでなく、いつまで経っても画面設計書がFIXしない状況になってしまいます。
「詳細情報」と「画面設計書」は切り分けておいて方が進行がスムーズになります。
演出・アニメーション
Webサイトを構成する要素の出現にアニメーションをつけることがあります。
それは、画面設計書に記載しておくべきものでしょうか？
画面設計書に演出やアニメーションの説明は不要だと考えます。
なぜなら、Webサイトの本質的な意味での「質」を高めるものではないから。
アニメーションや演出を加える理由としては「より印象づける」ため。
と言ったところだと思います。
しかし、それ、本当に必要でしょうか？
アニメーションがないと印象づけられないでしょうか？
良さを訴求するキャッチコピー、テキストサイズなどでも十分訴求可能です。
なので、コーディング、開発フェーズにおいて「やってみましたが、いかがでしょうか？」とお伺いを立てるレベルで十分。演出・アニメーションは無くても成立するものなのであれば、Webサイトのあるべき形として定義する画面設計書にわざわざ含めるものではありません。
機能
CMSでどのように管理されるのか。そもそもそういう内容を画面設計書に含めるべきか？
といったところです。
機能定義は機能定義書として別で定義するべきだと考えます。
なぜなら、
- フロントエンドと管理画面の対応
- 選択肢
- 表記のバリエーション
- 状態遷移
- エラー表示
など、機能を定義する項目は多岐にわたるからです。
それを画面設計書に全て落とし込むには無理があります。
機能に関して画面設計書に記載するべきは、
- どういう操作が可能か
- その操作によりユーザーがどのような情報を得るか
その程度の概要で問題ないと考えます。
リンク先
画面設計書に記載のリンク要素をクリック、タップしたらどこに遷移するか？
それを画面設計書に含めるべきでしょうか？
画面設計書とサイトマップを比較すれば、リンク先は想像できる状態が理想です。
そうなっているなら、わざわざそのリンク先を画面設計書に含める必要はないと思います。
リンク要素一つ一つにリンク先の説明を入れないといけない状態は画面設計書として良い状態とは言えません。
例外として該当ページの下層へのリンクではなく、別カテゴリの情報に「関連情報」としてリンクする場合などは、リンク先を明記すべきケースもあります。
設計趣意
- リニューアル前の状態から何を変えたのか、なぜ変えたのか？
- 変えることで誰のどんな課題を解決できるのか？
そういうWebディレクターの考えですが、これは画面設計書に含めるべきだと考えます。
「クライアント担当者に画面設計書を見せながら説明する機会がある。口頭で説明するから大丈夫。」
という人もいるかもしれませんが、画面設計書の良し悪しを判断するのはクライアント担当者だけではありません。場合によってはクライアントの担当者が、関係する部門にデータを渡して意見を請うことだってあるでしょう。そこに意図にあたるものが記載されていないと、その資料を見ても良し悪しの判断ができません。
長文で書く必要はないですが、
- なぜ変えるのか？
- 何を変えるのか？
- その変更でどういう効果を期待するのか？
そういうことが伝わる説明をつけましょう。
コンポーネント定義
画面設計書でページを構成する要素（表現パターン）のことをコンポーネントと呼びます。
そのコンポーネントの定義を画面設計書に明記するかどうかです。
これは個人的には不要だと思います。
画面設計を作成するツールが、XDやSketchであれば、おのずとコンポーネントを定義することになるのですが、クライアント側はページを構成する要素がコンポーネントとして定義されているかどうかは大きな問題ではなく、それはどちらは制作側の都合です。
ただ、本来表現として同じであるべきものが、別々の見え方になったりするのは望む状況ではありません。
なので
「表現として同じであるべきものは、そうします。表現にばらつきが出ないように整理しながら設計を進めます。」
ということを明確に伝えておき、その考えに同意をしてもらえるのであれば、わざわざ画面設計書に、この要素はこのコンポーネント定義です、というようなことを記載する必要はないと考えます。
コンポーネント定義はされているべきだが、その説明を画面設計書上に記載する必要まではないですよ、ということです。
Webサイトのあるべき形を定義し、クライアントのビジネス成果につなげることに絞る。
今回は画面設計書を構成する要素として
- テキスト
- 画像（写真・図）
- 表
- 演出・アニメーション
- 機能
- リンク先
- 設計趣意
- コンポーネント定義
以上の８つを挙げ、Webサイトの設計者（Webディレクター）がそれぞれについてどの程度のレベルで定義を含めるべきか、ということをお話ししました。
画面設計書を作成するにあたって一番大事なことは、
Webサイトのあるべき形を定義し、クライアントのビジネス成果につなげること
です。そのためには、
- なぜ変えるのか？
- 何を変えるのか？
- その変更でどういう効果を期待するのか？
をクライアントに同意してもらう必要があります。
その視点をブレずに持っておけば、画面設計書で定義すべきことも洗練されるはず。
今回のお話がポイントを押さえた画面設計書作成の参考になると幸いです。
