ワイヤーフレーム

ウェブサイトの画面設計をまとめるにあたって、よく使うのが、ワイヤーフレームという手法です。ワイヤーフレームとは、線 (wire) で描かれた枠/骨格 (frame) という意味で、詳細なビジュアルデザインまでは施さない形の、画面構成図/画面設計書のことを言います。

なぜワイヤーフレームを作るのか?

ワイヤーフレームには、大きくふたつの意義があります。

個人的には、前者はペーパープロトタイピングでやることがほとんどで、ワイヤーフレームはその清書、つまり後者の、立ち返るドキュメント (画面設計の仕様書) として捉えています。

最近では、ワイヤーフレームの代わりに HTML+CSS+JavaScript で直接プロトタイピングしながらデザインを詰めてゆくケースも増えているようです。マルチデバイス対応 (レスポンシブデザイン)、複雑なインタラクションの体感的な検証、システム側のつなぎの同時検討、といった面でメリットがありますが、小規模な組織やプロダクトでない限り、それとは別に立ち返るべきドキュメント (仕様書) は不可欠だと経験上感じていて、その意味で、ワイヤーフレームは今も重要だと思います。

コミュニケーションとして機能するワイヤーフレーム

ワイヤーフレームを、プロジェクト関係者が立ち返るドキュメント (画面設計仕様書) として捉えるならば、それは、プロジェクト内における有用なコミュニケーションとして機能しなければなりません。設計意図や、各関係者の作業に必要な情報が、誤解なく伝わる必要があります。

そのためワイヤーフレームの作成においては、単に画面構成を視覚的に描くだけでなく、具体的な注釈も記述します。たとえば、情報構造やマークアップに関する指示、ユーザビリティやアクセシビリティを担保するための要件、インタラクションの挙動、クリック/タップしたときのリンク先、といった情報です。絵的な完成度よりも、むしろこうしたノートの記述が重要だったりします。

また、ワイヤーフレームは、ウェブサイトの数ある設計仕様書のひとつに過ぎず、要件定義書、コンテンツインベントリー、サイトマップ、UI インベントリー、などといった他の仕様書と併存するケースが多いことでしょう。ワイヤーフレームに描かれた画面 (やその細部の要素) が、他の仕様書のどの記述に相当するかを明示的に紐づけておくと、関係者の理解を促すことができます。

もうひとつ、ワイヤーフレームがコミュニケーションとして機能し続けるためには、その作成過程においてプロジェクト関係者みんなが関与することが大事です。作成ツールの選定、ファイル共有のしかた、フィードバック (改善提案) のしかたなどを含め、プロジェクトに合ったやりかたで工夫してみるとよいでしょう。私の場合、ワイヤーフレームを作る前に、関係者に参加してもてもらう形で、ペーパープロトタイピングのセッションをすることが多いです。セッションを通じて合意形成されたペーパープロトタイプをワイヤーフレーム化することによって、自ずと関係者がインボルブされる形になるからです。

ワイヤーフレーム作成の勘所

ワイヤーフレームの作りかたに唯一の正解はありませんが、押さえておきたい勘所はいくつかあります。私自身は、以下のことに気をつけています (ワイヤーフレームの前にペーパープロトタイピングをする場合は、ペーパープロトタイピングの段階から、下記を意識するのが有効だと思います)。

UI を構成する要素の優先度と情報構造

UI を構成する要素 (コンテンツや各種 UI 部品など) のうち、ユーザーに優先的に認知してもらいたい (利用してもらいたい) ものはどれか?この画面で着実にユーザーにやってもらいたいことは何か?を意識しつつ、各要素の関係性、グルーピング (チャンク)、ビジュアルヒエラルキーを検討し、レイアウトに落とし込みます。

なお、レイアウトは、ビジュアル面だけでなく、情報構造 (セマンティックなマークアップ) の面から意識することも不可欠です。情報構造の適切さは、アクセシビリティに大きく影響するからです。

ナビゲーション

サイト共通のナビゲーションシステムは、そのサイトのアバウトネスや、その画面の (サイト内における) 位置づけを表現できているか?メジャーなタスクの遂行や軌道修正 (基点への立ち返り) をサポートできているか?を意識します。

また、メインコンテンツ内の文脈的なナビゲーションにおいては、ユーザーにとって望ましい「動線」をサポートすべく、適切に「導線」が提示できているか?を意識します。

UI 部品の一貫性

サイト全体にわたって、UI 部品の一貫性を意識します。

画面構成を描く際に UI 部品のテンプレート (私は Keynotopia を愛用しています) を使うと便利ですが、それだけでは不十分で、サイト独自の一貫性ルールを明確にしておく必要があります (ヘッダー、フッター、各種リンクの提示、ボタン、見出し、アイコンの使用、画像とキャプションの位置関係、各種インタラクションおよびフィードバックの提示、などなど…)。別途、UI コンポーネントのリスト (UI インベントリー) を定義し、ワイヤーフレーム上で紐づけておく (各コンポーネントの番号をワイヤーフレーム上に記載する) というのも有効でしょう。

ダミーテキスト

ワイヤーフレームでは、「Lorem ipsum …」「テキストテキストテキスト…」といったダミーテキストがよく使われますが、その後の制作工程で実際にコンテンツを当て込んでみると、量感や表現のトーンが、ワイヤーフレーム作成時に抱いていたイメージと異なることがしばしばあります。

ワイヤーフレームにおいて、どの程度コンテンツを実際のものにするか (ダミーを排除するか) は、ワイヤーフレーム作成にかけられるリソースやコンテンツの準備状況にもよりますが、個人的には、コンテンツ量が増える可能性を考慮しつつ、少なくともサイト共通のナビゲーションシステムや、各レベルの見出し、主要なリンク、行動喚起 (Call To Action : CTA)、くらいはなるべく実際のラベルを入れるように心がけています。

リニューアル案件であれば既存コンテンツを活かしてワイヤーフレームに当て込んでみるのも有効ですし、場合によっては競合サイトのコンテンツを当て込んでみるのも一考でしょう。

配色

ワイヤーフレームにおいては、事前にカラースキームが決まっている場合を除き、基本的に色は使わないようにしています。アクセシビリティの観点で、情報の識別を色に依存することは適切でないからです。

むしろ、色彩を排しても UI の意味がユーザーに伝わることが大事だと思います。

インタラクション

ワイヤーフレームは「静的」で、昨今のインタラクティブなアプリケーション設計には向かないという考えかたもあるようです。

個人的には、ウェブサイトやウェブアプリケーションにおいては、凝ったインタラクション (特にアニメーション効果の類) は nice-to-have (あれば便利) なものであって、ワイヤーフレームがインタラクティブに動かなくても大きな問題は無いと考えています。ユーザーの認知を助けたり、ユーザーにより確かなフィードバックを与えて安心感を高めたり、といった優れた利点はあるものの、本来はそれが無くても十分にアクセシブル/ユーザブルであるべきだと思うからです。

もちろん、ユーザーのアクション (入力など) に呼応して特定のエリアの情報内容が差し替わったり、フォームでバリデーション (エラー表示) をしたり、など、フィードバック (主に情報の出力) が不適切だと基本的なユーザビリティを阻害してしまう類のインタラクションもあるので、それについては、フィードバック前後の画面構成をそれぞれ静的なワイヤーフレームに盛り込めばよいと思います。

マルチデバイス対応

マルチデバイス対応 (レスポンシブデザイン) を想定して、代表的な画面サイズごとに複数のワイヤーフレームを作らなければならないのか、という懸念があるかもしれません。案件によるかもしれませんが、個人的には「モバイルファースト/コンテンツファースト」の考えかた則って、ワイヤーフレームはスマートフォンでの利用を前提にした画面設計でよいのでは、と考えています。大きな画面 (タブレットや PC) での表示上の工夫は nice to have なものと位置づけ、注釈として記述するか、どうしても必要であれば、補足的に画面構成を描くのがよいかな、と思います。


以上、ウェブサイトのワイヤーフレームを作るにあたって、私自身が心がけていることなどをまとめてみました。