POINT
■設計フェーズでは、Webサイトの全体的な構造、コンテンツ、ビジュアルデザイン、システムまで、幅広い範囲を検討します。
■設計フェーズで決定した事は、後の作業工程の拠り所となるので、関係者全員で共有します。
■適切に情報提供できるサイト構造と、その情報やイメージに合ったビジュアルデザインを作る準備をします。

テキストに基づいて内容を進めますが、目的を持ったサイト設計についての内容になっています。単純に「会社案内的なサイト」はサイト設計も考え方が“プロダクトアウト”になりがちで、効果の測定も難しいために、このように進めることは難しいかもしれません。

【設計フェーズの重要性】
現在のWebサイト構築では、調査分析やゴール設定の後、入念な設計作業が欠かせません。Webサイトの企画それ自体や、実制作や開発業務が注目されがちですが、両者をつなぐ設計フェーズをしっかり行わなければ、目的や目標の達成は難しくなります。
特にビジネスゴール、ユーザーニーズなどの基本戦略から、多様なデバイスへの対応、コンテンツ制作やシステム開発に至るプロセスを設計フェーズで具体化し、スタッフ全員で共有することで、完成までの長い期間、ブレずに作業が行えるようにすることが重要です。
【サイト設計の手順】
調査分析から得られた結果を基に、ターゲットユーザーが望むであろう行動プロセスを見出し、提供する情報や機能を決定します。ユーザーはWebサイトから必要な情報が得られなかったり、必要な機能が存在しない場合は、即座に離脱します。Webサイトで提供する情報や機能は、ターゲットユーザーの予想される行動プロセスを基に決定するのが基本です。

次に情報をどのように分類してユーザーに提供すればよいのかを検討します。ターゲットユーザーを設定したとしても、求める情報はざまざで、自分の求める情報にどのように辿り着くかというプロセスも多様です。

ユーザーが求める情報は、ただ漫然と提供すれば良いのでありません。伝えるべき情報一覧の中で、どの情報とどの情報を一緒にするかという組み合わせ方によって理解のし易さや、与える印象が変わります。ですから、ユーザーの動機や心理などをペルソナを元に考察し、最適な情報の分類と体系化を行います。

情報の分類が決定した後は、Webサイトの構造を組み立てることになります。一般的なWebサイトでは、トップページを頂点としてツリー型に情報を構成していくことになりますが、LPO型サイトや、サイト内の特定の箇所やコンテンツによってはリニア型のサイト構造にすることもあります。

また、ティーザーサイトやランディングページを用いた情報提供も検討できます。構造化の際にはコンテンツの中で情報のダブりや漏れを極力少なくすることが大切です。また、このプロセスでは情報の構造をどのようなディレクトリ構造で格納するかということも検討します。

ただし、近年ではCMSやフレームワークなど動的な出力形態を持つタイプの制作手法が増えたため、URLのディレクトリ構成と実際の格納ディレクトリが異なる場合があります。ですから、URL設計というプロセスで実際のURLを決めることが必要です。

サイト構造化と並行して、ビジュアルデザインのコンセプトを決める必要もあります。Webサイト内で情報がいくら整然とまとめられていても、ターゲットユーザーがそのWebサイトの中に必要とする情報があると感じなければ離脱してしまいます。

また、自分が求めている情報を発見できる手がかりがなければ、同じように離脱して別のWebサイトで目的を果たすでしょう。ターゲットユーザーに訴求でき、かつ提供している情報の信頼性を担保し、企業イメージに合うデザインコンセプトが要求されます。

ビジュアルデザインとも関連しますが、Webサイト内で使用するテキストの方向性の決定も、この設計段階で行っておくことが望ましいでしょう。完全なテキスト原稿の用意が後になるにしても、デザインに合ったテキストの雰囲気や言葉遣いなど、この時点で決定できます。特にキービジュアルで使うキャッチコピーやリードなどは、それ自体がビジュアルデザインに大きく関わることになり、良否にも影響を与えます。

Webサイトの雰囲気や構造を無視してテキスト素材を用意すると、ビジュアルデザインと組み合わせた際にちぐはぐになることがあります。文字もデザイン要素として考えることが、よいWebサイトにつながります。(柔らかい女性の口語調テキストを準備するのに、北○の拳に出てくるザコキャラみたいなのがメインのビジュアルだったら・・・笑えないですよね)

コンテンツ側の設計が終わった後は、これらをどのようにWebサーバー上で公開するかを検討します。フロントエンドの技術として、どのHTMLやCSSのバージョンを用いるか、インタラクティブな表現の手段としてJava Scriptを用いるのかFlashを用いるのか、それとも他の技術を用いるのか。バックエンド技術として、どのプログラム言語とデータベースシステムを用いるのか、予想される負荷に対して要求されるWebサーバーのスペックはどの程度か、などを検討します。

現在はゲーム機やタブレット端末でもインターネットに接続できてしまうので、端末によってはいくつかの言語や技術に対応していないとか、新技術に対して対応ブラウザの普及率が追い付いていないなど、コンテンツの提供に支障が出ることがあるので、多様な閲覧環境に対して慎重な検討が必要です。潤沢な予算を準備して対応できるクライアントは少ないので、個人的には「クライアントと推奨環境を協議して、一定の範囲で対応する」ようにしています。クライアントのWebリテラシーによっては、後々に問題となることもあるので、協議のうえでサイト上に明記した方が良いかもしれません。

そして、設計段階で決めたことを後々のフェーズで変更することは、実際にはよくある話なのですが、大きな工数の無駄になったり、スケジュールの遅延の原因となります。品質にも影響を及ぼすので、設計作業を入念に行うことは重要であり、クライアントのWebリテラシーによっては大きな課題でもあります。

おまけ【ペルソナを利用したサイト設計】
ペルソナは製品やサービスを利用する象徴的な仮想ユーザーです。気を付けてほしいのは単に「来てもらいたい顧客像」や、「過去の経験から想像した顧客像」ではないということです。詳細については機会が有れば改めますが、今回は大雑把な内容を記します。

CRMデータやアクセス解析、ユーザーインタビューや出口調査といった定量調査や定性調査の結果に基づく事実を背景に、価値観やパーソナリティー、ライフスタイルを何通りか設定します。それぞれのペルソナが、それぞれの場面でどのような行動を選択するかをシナリオ化してコンテンツ内容や遷移設計を行います。

ペルソナと、そうでないターゲット