IAになりたい人、IAと仕事をしてみたい人必見!
実践的インフォメーションアーキテクト論
文=清水 誠
実践系Webコンサルタント。DTP・印刷・ネットビジネスの分野を中心に、ITとIAによる業務カイゼン を手がける。印 刷物とWebへ画像をシングルソースするためのカラーマネジメント、文字情報をシングルソースするECM・XML・自動組版、ビジネスを加速するITイノ ベーションが最近のテーマ。1995年国際基督教大学卒
第6回
捨てられないスタイルガイド
サイト構築の成果物として、最後に納品されることが多いスタイルガイド。しかし、労力をかけて作成しても、納品後に活用されずに埋もれてしまい、日々の運用どころか次回のリニューアルで無視されて無用の長物になることも多い。そうならないための、役に立つガイドラインとは?
■活用されないスタイルガイド
だれのためのドキュメント?
スタイルガイドでよくあるまちがいが、結果的にできあがったページに関するデザイン要素を延々と図解してしまうことだ。ページテンプレートのスクリーンショットを貼り付け、その上にカラーコードやフォントの種類、サイズ、領域のピクセル数などを重ねていく【1】。このような詳細情報が必要になるのは、制作途中のHTMLコーダーや品質チェックのテスト担当くらいで、納品後に必要になることはほとんどない。
![【1】デザイン指示書は制作スタッフ用でしかない](/attach/images/2008october/web_strategy/IA/06/01.gif)
【1】デザイン指示書は制作スタッフ用でしかない
資産として活用するには
スタイルガイドには、つくったページの詳細を記録するのではなく、なぜそのデザインに至ったかの考え方を記述すべきだ。配色やフォントサイズ、レイアウトなど、すべてのビジュアル要素には、リサーチ結果や業界標準、議論を重ねた結果、直感に基づく提案への合意など、何らかの理由や背景があって決められたはずだ。
この理由や背景が明確に書かれていて、かつ十分に論理的なルールとして成り立っていれば、納品後も長い間にわたって活用されるドキュメントになる【2】。日々の運用で新しいページを追加する必要が生じたときには、スタイルガイドを参照すれば、サイト全体の統一感を保ったまま新しいデザインを追加することができる。新しいニーズに対応するために、新しいスタイルの定義が必要になった場合には、ルールの改定や追加をしていく。ドキュメントが資産として長期的に活用されるようになるのだ。
![【2】理想のスタイルガイドは長期的に活用できる資産となる](/attach/images/2008october/web_strategy/IA/06/02.gif)
【2】理想のスタイルガイドは長期的に活用できる資産となる
■サイト構築の流れに合わせてスタイルガイドを構成する
章ごとに分担する
スタイルガイドの構成をサイト構築の流れ【3】に合わせれば、デザインに至る理由や背景をカバーできる。スタイルだからとデザイナーだけに任せてよいものではないのだ。サイトをIAや編集者、ライター、デザイナー、HTMLコーダーなどのスタッフが集まって構築するのと同じように、それぞれが自分の分野について書くようにするとよい。
![【3】スタイルガイドもサイト構築と同じように各スタッフで分担する](/attach/images/2008october/web_strategy/IA/06/03.gif)
【3】スタイルガイドもサイト構築と同じように各スタッフで分担する
デザインを支援するIA作業
IAの作業は、次に続くビジュアルデザインのための下準備をしているともいえる。そしてデザイナーは、それを基にデザインの過程で視覚表現のルールをつくり上げ、それを具現化していく。だが、論理、経験則、感性の交ざったこの思考を明確に記述するのは簡単なことではない。先にIAが情報の整理とUIのパターン化を行い、必要とされるテンプレートとモジュールを明確に定義しておくとよい。ビジネスの要件やシステムの制約を整理してドキュメント化し、関係者の間でコンセンサスを得ておけば、無駄の少ないデザイン作業が可能になる。
デザイナーから論理を引き出す
IA設計がデザインへ正しく反映されることを確かめるため、IAはデザインをレビューする必要がある。さらに、デザインの作業中に、IAがデザイナーとコラボレートしながらデザインを進めていくという、より積極的な関与の方法もある。デザイナーの頭の中にある思考を引き出して整理しつつ、そのルールはスタイルガイドに明確に書くことができるか、という観点でデザインを評価していく。
ドキュメント化と同時に修正も
こうして引き出して整理されたルールは、第三者が見ても理解できるように図や文章で明確に記述する必要がある。論理を確かめながら記述しているうちにルールの矛盾や例外が見つかることもあるので、ドキュメント作成中もデザインを微調整できるようなスケジュールを組む必要があるだろう。
■IAの担当部分
今回想定した構成は【4】の通り。サイト構築の流れ【3】に合わせてあり、それぞれのスタッフが執筆を担当することになる。
![【4】サイト構築の流れに合わせたスタイルガイド構成の例](/attach/images/2008october/web_strategy/IA/06/04.gif)
【4】サイト構築の流れに合わせたスタイルガイド構成の例
誌面の都合のため、IAが担当する部分である「コンセプトモデル」「分類」「ユーザビリティ」「ナビゲーション」「ウインドウ」「フォーム」について以下で解説していく。
コンセプトモデル
Webサイトとユーザーの位置づけを可視化(図解)したもの。最近ようやく公開できる良い例を見つけたので、紹介したい。【5】はオンライン写真共有サービス「Flickr」のコンセプトモデルだ。2005年にユーザーによって作成・公開され、IAの間で話題になった。Tagによって写真のコンテンツやコンテクストがわかる、Groupによって共通の話題の議論ができる、Organizrによって写真をまとめることができる、などサイトを使うことで写真の楽しみ方が広がることが一枚の図で表現されている。
![【5】soldierant.net IAのBryce GlassによるFlickrのコンセプトモデル(ユーザーモデル)](/attach/images/2008october/web_strategy/IA/06/05.gif)
【5】soldierant.net IAのBryce GlassによるFlickrのコンセプトモデル(ユーザーモデル)
分類・タクソノミー
次に、上記のコンセプトモデルを受けて、サイト上の機能とコンテンツをどう分類すべきかを定義する。最終的な結果としての分類だけでなく、その分類に至る根拠、分類の細かさや同じ階層における最大項目数など今後のメンテにおける留意点も含めるとよい。上位の分類は図などでわかりやすく記述し【6】、全部の階層を含む細かい分類はExcelを使ってテキストベースで管理すると後で更新するのが楽になる。ページとコンテンツが1対1になる場合は、サイトマップと兼用することもできるだろう。
![【6】ハイレベル(上階層)の分類は根拠ある定義にする](/attach/images/2008october/web_strategy/IA/06/06.gif)
【6】ハイレベル(上階層)の分類は根拠ある定義にする
タクソノミーは、コンテンツが大量にあり、通常のツリー構造の分類では無理がある場合の分類体系である。これも、コンセプトモデルで定義されたユーザー行動やサイトのあり方に合わせて、切り口としてのファセットを定義するとよい。これは、検索用のメタデータ(METAタグなど)やコンテンツのタギングに使われる。
分類の手法については、本連載の第3回を参照してほしい。サイトの根本的なコンセプトと密接な分類体系は、コンセプトが変わらない限り、長期の運用に耐えられる基礎となるはずだ。
ユーザビリティ方針
ユーザビリティをどこまで対応すべきかは、ターゲットユーザー像やコンセプトモデルから導き出されるユーザーの行動特性と結びつけて記述するとよい。また、概念的すぎるあいまいな定義だと、運用の段階で読み手の解釈に依存してしまうので、具体的な定義が望ましい。たとえば、チェックリストを作成し、対応は必須か推奨かを定義する。
UI:ナビゲーション
分類の定義によって、ナビゲーション体系が対応すべきサイト構造の幅(項目数)と深さ(階層)が明確になる。次に、項目の長さや想定されるユーザー行動をふまえて、画面上でナビゲーションをどうデザインすべきかを定義する【7】。たとえば、階層を飛び越えるナビゲーションが多いためにパン屑リストで階層構造における現在地を明確にする必要がある、ネットに不慣れなユーザーが対象のためにわかりやすいタブのメタファーによるナビゲーションが望ましいなど、明確な理由と必然性をもつ定義にする。
![【7】項目の長さや想定されるユーザー行動をふまえてナビゲーションを定義](/attach/images/2008october/web_strategy/IA/06/07.gif)
【7】項目の長さや想定されるユーザー行動をふまえてナビゲーションを定義
配色やフォントサイズ、ピクセルサイズなどはページデザインの章で定義するので、ここではインタラクションのふるまいの定義にとどめておく。ただし、要件によっては、このようなUIとしての必然性が低いことがある。その場合はデザイナーの感性に任せ、ビジュアルデザインとしてまとめて定義すればいいだろう。
UI:ウインドウ
ウインドウの扱い方について、ユーザビリティやアクセシビリティの方針を受けた必然性のある定義を行う。ウインドウの遷移方法、ポップアップの扱い、別ウインドウの使い方、ウインドウサイズの指定方法などについて記述する【8】。
![【8】ウインドウにはユーザビリティなどの方針を受けた必然性のある定義を行う](/attach/images/2008october/web_strategy/IA/06/08.gif)
【8】ウインドウにはユーザビリティなどの方針を受けた必然性のある定義を行う
UI:フォーム
フォームはもともとパーツを組み合わせるものなので、ルール化しやすいだろう。ブランディングとユーザビリティの要件を受けて見た目と使い勝手のバランスを導き出し、ルールに反映させる。定義すべき内容としては、ラベルの表記方法、例の表示方法、コントロールの使い分け方法、入力チェックの定義、エラー時の対応方法、ボタンの使い方、などがある。
スタイルガイドは制作の集大成
このように、本来のスタイルガイドは制作の集大成であり、最終的にサイトが完成するまでに至る意図や意思決定をもれなく記述するのが理想的だ。特にIAやUIの定義に関しては、定義の妥当性が高ければ、将来のリニューアル時に見た目のデザインだけ変更し、IAとUIの定義はそのまま生かされるかもしれない。また、デザインの裏づけが増えることで、ビジュアルデザインの効率や品質向上につながるだろう。
本記事は『Web STRATEGY』2006年11-12 vol.6からの転載です
実践的インフォメーションアーキテクト論
![文=清水 誠](/attach/images/2008february/web_strategy/cms_rensai/01/mshimizu.jpg)
実践系Webコンサルタント。DTP・印刷・ネットビジネスの分野を中心に、ITとIAによる業務カイゼン を手がける。印 刷物とWebへ画像をシングルソースするためのカラーマネジメント、文字情報をシングルソースするECM・XML・自動組版、ビジネスを加速するITイノ ベーションが最近のテーマ。1995年国際基督教大学卒
第6回
捨てられないスタイルガイド
サイト構築の成果物として、最後に納品されることが多いスタイルガイド。しかし、労力をかけて作成しても、納品後に活用されずに埋もれてしまい、日々の運用どころか次回のリニューアルで無視されて無用の長物になることも多い。そうならないための、役に立つガイドラインとは?
■活用されないスタイルガイド
だれのためのドキュメント?
スタイルガイドでよくあるまちがいが、結果的にできあがったページに関するデザイン要素を延々と図解してしまうことだ。ページテンプレートのスクリーンショットを貼り付け、その上にカラーコードやフォントの種類、サイズ、領域のピクセル数などを重ねていく【1】。このような詳細情報が必要になるのは、制作途中のHTMLコーダーや品質チェックのテスト担当くらいで、納品後に必要になることはほとんどない。
![【1】デザイン指示書は制作スタッフ用でしかない](/attach/images/2008october/web_strategy/IA/06/01.gif)
【1】デザイン指示書は制作スタッフ用でしかない
資産として活用するには
スタイルガイドには、つくったページの詳細を記録するのではなく、なぜそのデザインに至ったかの考え方を記述すべきだ。配色やフォントサイズ、レイアウトなど、すべてのビジュアル要素には、リサーチ結果や業界標準、議論を重ねた結果、直感に基づく提案への合意など、何らかの理由や背景があって決められたはずだ。
この理由や背景が明確に書かれていて、かつ十分に論理的なルールとして成り立っていれば、納品後も長い間にわたって活用されるドキュメントになる【2】。日々の運用で新しいページを追加する必要が生じたときには、スタイルガイドを参照すれば、サイト全体の統一感を保ったまま新しいデザインを追加することができる。新しいニーズに対応するために、新しいスタイルの定義が必要になった場合には、ルールの改定や追加をしていく。ドキュメントが資産として長期的に活用されるようになるのだ。
![【2】理想のスタイルガイドは長期的に活用できる資産となる](/attach/images/2008october/web_strategy/IA/06/02.gif)
【2】理想のスタイルガイドは長期的に活用できる資産となる
■サイト構築の流れに合わせてスタイルガイドを構成する
章ごとに分担する
スタイルガイドの構成をサイト構築の流れ【3】に合わせれば、デザインに至る理由や背景をカバーできる。スタイルだからとデザイナーだけに任せてよいものではないのだ。サイトをIAや編集者、ライター、デザイナー、HTMLコーダーなどのスタッフが集まって構築するのと同じように、それぞれが自分の分野について書くようにするとよい。
![【3】スタイルガイドもサイト構築と同じように各スタッフで分担する](/attach/images/2008october/web_strategy/IA/06/03.gif)
【3】スタイルガイドもサイト構築と同じように各スタッフで分担する
デザインを支援するIA作業
IAの作業は、次に続くビジュアルデザインのための下準備をしているともいえる。そしてデザイナーは、それを基にデザインの過程で視覚表現のルールをつくり上げ、それを具現化していく。だが、論理、経験則、感性の交ざったこの思考を明確に記述するのは簡単なことではない。先にIAが情報の整理とUIのパターン化を行い、必要とされるテンプレートとモジュールを明確に定義しておくとよい。ビジネスの要件やシステムの制約を整理してドキュメント化し、関係者の間でコンセンサスを得ておけば、無駄の少ないデザイン作業が可能になる。
デザイナーから論理を引き出す
IA設計がデザインへ正しく反映されることを確かめるため、IAはデザインをレビューする必要がある。さらに、デザインの作業中に、IAがデザイナーとコラボレートしながらデザインを進めていくという、より積極的な関与の方法もある。デザイナーの頭の中にある思考を引き出して整理しつつ、そのルールはスタイルガイドに明確に書くことができるか、という観点でデザインを評価していく。
ドキュメント化と同時に修正も
こうして引き出して整理されたルールは、第三者が見ても理解できるように図や文章で明確に記述する必要がある。論理を確かめながら記述しているうちにルールの矛盾や例外が見つかることもあるので、ドキュメント作成中もデザインを微調整できるようなスケジュールを組む必要があるだろう。
■IAの担当部分
今回想定した構成は【4】の通り。サイト構築の流れ【3】に合わせてあり、それぞれのスタッフが執筆を担当することになる。
![【4】サイト構築の流れに合わせたスタイルガイド構成の例](/attach/images/2008october/web_strategy/IA/06/04.gif)
【4】サイト構築の流れに合わせたスタイルガイド構成の例
誌面の都合のため、IAが担当する部分である「コンセプトモデル」「分類」「ユーザビリティ」「ナビゲーション」「ウインドウ」「フォーム」について以下で解説していく。
コンセプトモデル
Webサイトとユーザーの位置づけを可視化(図解)したもの。最近ようやく公開できる良い例を見つけたので、紹介したい。【5】はオンライン写真共有サービス「Flickr」のコンセプトモデルだ。2005年にユーザーによって作成・公開され、IAの間で話題になった。Tagによって写真のコンテンツやコンテクストがわかる、Groupによって共通の話題の議論ができる、Organizrによって写真をまとめることができる、などサイトを使うことで写真の楽しみ方が広がることが一枚の図で表現されている。
![【5】soldierant.net IAのBryce GlassによるFlickrのコンセプトモデル(ユーザーモデル)](/attach/images/2008october/web_strategy/IA/06/05.gif)
【5】soldierant.net IAのBryce GlassによるFlickrのコンセプトモデル(ユーザーモデル)
分類・タクソノミー
次に、上記のコンセプトモデルを受けて、サイト上の機能とコンテンツをどう分類すべきかを定義する。最終的な結果としての分類だけでなく、その分類に至る根拠、分類の細かさや同じ階層における最大項目数など今後のメンテにおける留意点も含めるとよい。上位の分類は図などでわかりやすく記述し【6】、全部の階層を含む細かい分類はExcelを使ってテキストベースで管理すると後で更新するのが楽になる。ページとコンテンツが1対1になる場合は、サイトマップと兼用することもできるだろう。
![【6】ハイレベル(上階層)の分類は根拠ある定義にする](/attach/images/2008october/web_strategy/IA/06/06.gif)
【6】ハイレベル(上階層)の分類は根拠ある定義にする
タクソノミーは、コンテンツが大量にあり、通常のツリー構造の分類では無理がある場合の分類体系である。これも、コンセプトモデルで定義されたユーザー行動やサイトのあり方に合わせて、切り口としてのファセットを定義するとよい。これは、検索用のメタデータ(METAタグなど)やコンテンツのタギングに使われる。
分類の手法については、本連載の第3回を参照してほしい。サイトの根本的なコンセプトと密接な分類体系は、コンセプトが変わらない限り、長期の運用に耐えられる基礎となるはずだ。
ユーザビリティ方針
ユーザビリティをどこまで対応すべきかは、ターゲットユーザー像やコンセプトモデルから導き出されるユーザーの行動特性と結びつけて記述するとよい。また、概念的すぎるあいまいな定義だと、運用の段階で読み手の解釈に依存してしまうので、具体的な定義が望ましい。たとえば、チェックリストを作成し、対応は必須か推奨かを定義する。
UI:ナビゲーション
分類の定義によって、ナビゲーション体系が対応すべきサイト構造の幅(項目数)と深さ(階層)が明確になる。次に、項目の長さや想定されるユーザー行動をふまえて、画面上でナビゲーションをどうデザインすべきかを定義する【7】。たとえば、階層を飛び越えるナビゲーションが多いためにパン屑リストで階層構造における現在地を明確にする必要がある、ネットに不慣れなユーザーが対象のためにわかりやすいタブのメタファーによるナビゲーションが望ましいなど、明確な理由と必然性をもつ定義にする。
![【7】項目の長さや想定されるユーザー行動をふまえてナビゲーションを定義](/attach/images/2008october/web_strategy/IA/06/07.gif)
【7】項目の長さや想定されるユーザー行動をふまえてナビゲーションを定義
配色やフォントサイズ、ピクセルサイズなどはページデザインの章で定義するので、ここではインタラクションのふるまいの定義にとどめておく。ただし、要件によっては、このようなUIとしての必然性が低いことがある。その場合はデザイナーの感性に任せ、ビジュアルデザインとしてまとめて定義すればいいだろう。
UI:ウインドウ
ウインドウの扱い方について、ユーザビリティやアクセシビリティの方針を受けた必然性のある定義を行う。ウインドウの遷移方法、ポップアップの扱い、別ウインドウの使い方、ウインドウサイズの指定方法などについて記述する【8】。
![【8】ウインドウにはユーザビリティなどの方針を受けた必然性のある定義を行う](/attach/images/2008october/web_strategy/IA/06/08.gif)
【8】ウインドウにはユーザビリティなどの方針を受けた必然性のある定義を行う
UI:フォーム
フォームはもともとパーツを組み合わせるものなので、ルール化しやすいだろう。ブランディングとユーザビリティの要件を受けて見た目と使い勝手のバランスを導き出し、ルールに反映させる。定義すべき内容としては、ラベルの表記方法、例の表示方法、コントロールの使い分け方法、入力チェックの定義、エラー時の対応方法、ボタンの使い方、などがある。
スタイルガイドは制作の集大成
このように、本来のスタイルガイドは制作の集大成であり、最終的にサイトが完成するまでに至る意図や意思決定をもれなく記述するのが理想的だ。特にIAやUIの定義に関しては、定義の妥当性が高ければ、将来のリニューアル時に見た目のデザインだけ変更し、IAとUIの定義はそのまま生かされるかもしれない。また、デザインの裏づけが増えることで、ビジュアルデザインの効率や品質向上につながるだろう。
本記事は『Web STRATEGY』2006年11-12 vol.6からの転載です