3.4 情報設計・画面設計
業務要件を確認した上で、その情報をもとにWebシステムを構成する要素としてのシステムコンポーネントを規定し、各システム間のI/Fを規定したら、フロントエンドの画面の情報設計・画面設計となります。
もちろん、業務要件を検討する段階でフロントエンドの画面として、どのような画面があって、どのような情報が表示されてどのような操作ができるものとするかなども想定するので、概略の画面内容はすでに業務要件の段階でイメージできている前提で、各画面の詳細を規定していく作業となります。
a. コンテンツ設計
コンテンツ設計というと、会社HPのようなWebサイトの設計においては、製品の差別化要素の説明コンテンツやどこまでのプロセスを経て生産/開発されている製品であるのかを訴求する制作/開発プロセス秘話や担当者インタビューなどのコンテンツをどこまで、Webサイトのどこに用意するかという設計となりますが、業務系のWebにおいては、受注決裁フローにおいて各商品の原価情報を取り込んで、申請価格では営業利益がいくらになるかをみせるなど、どのような情報を各画面で提示するかという設計となります。
これらのコンテンツ設計はクライアント側でも想定していることも多い部分でもあり、また新規にコンテンツを作成するためにはかなりコストと期間を要して、結構手間のかかる部分でもあるので、対応するには一番初期段階から取り掛かるか、中長期的な取り組みとして対応する必要がある作業でもあります。そのために、Web構築にあたっては、ベンダーとしてはクライアントに用意されたコンテンツを前提条件としてそれ以上のコンテンツ設計は行わない場合も珍しくありません。
ただし、近年、「コンテンツマーケティング」のようなことばも珍しくなくよく聞くようになったように、主題に合った効果的なコンテンツを掲載できることの効果は大きいので、あり得るプロセスステップのひとつとして認識はしていく必要があります。
b. 情報設計 / ナビゲーション設計
Webサイトのターゲットユーザ像、ビジネスゴール、サイトコンセプトなどとともに、サイトに掲載するコンテンツまで決まれば、どのようなWebサイトのページ構成/ナビゲーションを用意して、ユーザが必要とするタイミングで必要なアクションをとることができるようなWebサイトの画面の設計を行うことになります。
Webサイトに掲載される情報が多く、多数のページから構成される会社HPのようなサイトの場合には、まずはサイトに掲載する情報を分類・グルーピングしてカテゴリ(大カテゴリ/中カテゴリ/小カテゴリ)を規定していき、Webサイトの構造を決めていくというサイトの構造設計を行うことになります。設計アウトプットとしては、樹形図のようにWeb画面の構造を表現する「サイトストラクチャ」を作成する場合や、EXCELなどで画面の階層構造を含めて画面一覧を作成していく「画面一覧」を作成する場合などがあります。
一方で、業務系のWebの場合にはWebページの数や掲載するコンテンツ・情報が膨大とはならない場合も多く、サイトの構造を決定する手順としては、機能別の分類・グルーピングを行い、関連する機能/続けて操作するアクションなどに従いWebサイトの構造を決めていくことが多いかと思います。
また、ユーザが画面を操作していく手順が決まっている場合には「画面遷移図」として、操作していく手順で画面を並べた図で表現することもあります。
どのようなタイプのナビゲーションを画面のどのエリアに用意するのかを決めていくナビゲーション設計は、各画面ごとの設計ではなく、Webサイトの一種の構造を設計するプロセスといえます。
PC向けのWebサイトのナビゲーション、スマホサイトのナビゲーションで異なるところがありますが、代表的なナビゲーションがいくつかありますので、その中からサイトの構造や内容、想定するユーザの画面遷移の仕方などに従って、最適なナビゲーションを何種類か使用してサイトの導線設計を行います。そのことによりサイトに訪れたユーザーの文脈に沿った情報提供、登録への誘引、サイトからの離脱を防ぎ、使いやすいWebサイトを実現するひとつのポイントとなります。
c. 画面設計/レイアウト設計
どれだけの画面を用意してWebサイトとしてどのような構造のものとするのか、サイトの構造からナビゲーションまで設計できたら、各画面の詳細の設計を行っていくことになります。画面設計/レイアウト設計のアウトプットとしては「ワイヤフレーム」を作成することが多いかと思います。ワイヤフレームとは、デザインを行う前のプロセスとして各画面のレイアウト設計を行って、その画面に表示する構成要素は具体的には何として、各構成要素は画面上にどのように配置するかを決めていく作業のアウトプットとするものです。従って、色はついていないものですし、ボタンや枠などのデザイン要素もデザインされていないシンプルな骨組みの画面イメージを示す図です。コンテンツとしての文章もごく一部のさわりは入っていることもありますが、タイトルやナビゲーションメニュー名のほかは基本的には入ってない状態のものです。
ワイヤフレームは画面設計/レイアウト設計のアウトプットとなるとともに、その次の工程となるデザイン作業の指示書となります。また、デザイン作業とともに、システム開発を含むWeb構築においてはシステム設計(外部設計)の指示書ともなります。
Web構築に慣れていない顧客担当者にワイヤフレームの確認を求めると、どの観点での確認を行う必要があるのかがなかなかピンときてくれないことがあります。ボタンや枠などの見え方やタイトルの大きさなどの細かいところの指摘をされたり、文章を完全に入れてほしいとの要望をされたりすることがありますが、そのような担当者に対しては、作業プロセスを説明して、各段階のプロセスでどこまでの規定を行うかを理解してもらうことにより、ワイヤフレームに対しての必要十分な確認をしてもらえるようになります。
また、システム開発を含むWeb構築において、画面設計を行う段階で規定すべき内容として、以下のような内容を漏れなく規定することに注意を向ける必要があります。
a.ユーザ属性やアクションの段階/状態による画面表示の動的な変化
b.アクションのための画面要素(登録ボタンなど)を操作したときに
実行される「機能」がシステム設計書のどの機能に対応するか
c.システムの状態による実行できるアクションの変化
※ECサイトで製品出荷前までは取消ができるが、その後は取消が
できない等
したがって静的なWebサイトと同様にワイヤフレームを設計アウトプットとして作成するだけでは不十分で、以下のようなドキュメント上での記述を行っておくことが必要です。
a. 動的に変化する内容や変化する箇所がごく少ない場合は、ワイヤフレーム
資料の中に補足説明として記載する。ただし、変化する内容や変化する箇所が多い場合は、その表示の変化について一覧のようにまとめてドキュメントとする必要があります。
b. 画面に画面#をふり、各画面内の画面要素にも番号Noをふるとともに、
アクションのための「ボタン」などの画面要素を操作したときに実行されるのはシステム設計書に記載されているどの機能であるかの記述も入れた「画面定義書」の形態にワイヤフレームをベースとしてまとめてドキュメントとしておくとよいと思います
また、SaaSのUIを拡張するために外部にWebフォームを作成して、SaaSのAPIを呼ぶことによりフォーム画面の表示やフォームで入力された内容のSaaSへの登録を行うような場合には、各画面要素がSaaSのどのデータ項目(ex. HubSpotであれぱプロパティ)に該当するのかを一覧で記載してあげると、画面設計段階での設計ドキュメントとして後工程に対して想定している動作が明確となり好ましいです。※場合によっては、システム設計ドキュメントは不要でエンジニアがこの資料まであれば実装ができます
同様に、WordPressの画面をPHPでカスタマイズ/動的に変化させたい場合にも、PHPのプログラムで動的に表示変化させたい画面要素の表示内容/入力項目がWordPressのDBのどのテーブル/カラムに対応するのかを一覧で記載してあげると後工程を担当するSEやエンジニアが仕事をしやすくなります。
Webディレクタとして次のステップをさがしている方たちへ
これからのWeb構築・Webディレクションとして、業務にまで踏み込んでディレクション/プロデュースすること、それが近年のバズワードであるDXにもつながること、そしてWebの進化とともにWeb構築の各種ツール/サービスやSaaSが広がってきていることにしたがって、業務とシステムの両面からWeb構築・運用していく人間が求められていくこと、そのためにどのような知識や能力を身に着けていくとよいかについて解説している「マガジン」です。