情報アーキテクチャ、インタラクションデザイン記述のためのビジュアルボキャブラリー

version 1.1b-j (29 June, 2002) based on version 1.1b (6 March 2002)

著者 Jesse James Garrett <jjg@jjg.net>
翻訳 長谷川敦士 <hase@concentinc.jp>
近藤哲也 <tetsu@022.org>

目次

  1. サマリー
  2. バージョン履歴
  3. はじめに
  4. 基本概念
  5. 基本要素：ページ、ファイル、そしてそれらの集まり
  6. 関係性の記述：コネクターと矢印
  7. すべてを一度に：並列セット
  8. 一時中断：連続ポイント
  9. 共通要素：エリアと反復エリア
  10. 再利用可能な要素：フローエリアと参照
  11. 条件要素の基本概念
  12. 選択せよ：意志決定点
  13. 探検者(パスの誘導)：条件的なコネクターと矢印
  14. 複数の選択：条件的な分岐
  15. 一つか複数か：条件的な選択肢
  16. 一つの決定、複数のパス：クラスター
  17. 制約条件あり：条件的なエリア
  18. 結論
  19. ダウンロード可能なパーツライブラリ

サマリー

ダイアグラムはウェブ開発チーム内で情報アーキテクチャやインタラクションデザインについて話をする際に必須のツールである。 このドキュメントでは、それらのダイアグラム生成の理由について議論を行い、情報アーキテクチャやインタラクションデザインコンセプト作図のための基本的記号体系、そしてそれらの要素を使うためのガイドラインについて述べる。

バージョン履歴

1.1b-j (29 June 2002)
日本語版リリース
1.1b (6 Mar 2002)
OmniGraffle 2.0に標準添付されたお知らせ
iGrafx Flowcharter向けの新シェイプライブラリ
1.1a (17 Sep 2001)
Macromedia FreeHand向けの新シェイプライブラリ
チートシートとPDFシェイプテンプレート掲載
1.1 (31 Jan 2001)
ファイルの集まりエレメント追加
条件的な選択肢エレメント追加
矢印エレメントが複数の矢じりをもてるように修正
クラスターエレメントの振る舞いを修正し、この結果条件分岐あるいは条件選択肢に現れていたのが、ダウンストリームのみになった。
条件分岐エレメントの振る舞いをヌル結果を許すように修正。
シェイプライブラリを大幅に改善
Adobe InDesign向けの新シェイプライブラリ
1.0 (17 Oct 2000)
最初のリリース

はじめに

一般に、ビジュアルボキャブラリーはなにかを（通常はシステムや構造や過程を）記述するための記号のセットである。 ここで定義されているこのボキャブラリーは、インフォメーションアーキテクトあるいはインタラクションデザイナーが、ウェブサイトにおけるストラクチャーあるいはユーザー経験のフロー、またはその両方を抽象度の高いレベルで記述するためのものだ。

この記述、あるいはダイアグラム、は５種類の人を対象にしている。

  • プロジェクトのスポンサーとマネージャー、はプロジェクトのスコープとかたちのだいたいのところを把握する感覚を身につけるためにビジュアルボキャブラリーを用いる。
  • コンテンツプロデューサー、はコンテンツのシステム要求事項を導き出すためにビジュアルボキャブラリーを用いる。
  • ビジュアルデザイナーとインターフェイスデザイナー、はいくつの個別ページデザインを作る必要があるかを数えて、それらのデザインのためのナビゲーションとインターフェイス要求事項に関する感触をつかむためにビジュアルボキャブラリーを用いる。
  • 技術者、は機能的要求事項を導き出すめにビジュアルボキャブラリーを用いる。
  • インフォメーションアーキテクトとインタラクションデザイナー、は各ページの詳細ナビゲーションとインターフェイス要求事項を開発するためにビジュアルボキャブラリーを用いる。

これらの対象者はみんな（スポンサーを除いて）、彼らの仕事を実行するために莫大な量の詳細情報を必要としている。 やっかいなのは、それぞれのそれぞれの役割の人々がそれぞれが必要としている詳細情報が、それぞれ他の種類の人に必要な情報と非常に異なっていて、そして大部分は他の種類の人にとっては見当違いな情報であるということだ。

すべての対象者に対してダイアグラムを有用に使ってもらうための正当なアプローチは、ダイアグラムの詳細を制限することだ。そうすることで、このダイアグラムはそれぞれの対象者の必要に特化したより詳細のドキュメントを作る際の基準して機能する。

情報アーキテクチャやインタラクションデザインのためのビジュアルボキャブラリーとして要求される他のポイント事項は以下の通り、

  • ホワイトボード互換： このボキャブラリーはダイアグラムが手で簡単に記述できるくらい単純でなければならない。ボキャブラリーの要素は適度にいいかげんな書き方をしてもダイアグラムの特徴が見分けられるくらいきちんと区別されている必要がある。
  • ツール独立： このボキャブラリーはダイアグラムを構成するのに、専用のソフトウェアを必要としないようにデザインされなければならない。 このボキャブラリーは特定のソフトウェア用には作られていない。逆にそれぞれのアーキテクトがそれぞれもっとも使いやすいツールで使えるようにできている。
  • 小さくてかつ自己完結していること： こういったダイアグラムは幅広い領域の人に使われる。 そしてそれらの人々は、既にさまざまな技術開発の領域で用いられているダイアグラムシステムに関しての異なるレベルの知識（そして関心）を持っている。 このボキャブラリーはそれらの知識や関心を必要としていない。 要素のセット全体はできるだけ小さく保たれていなければならなく、意味と記号（コンセプトとシンボル）は完全に互いに対応するようにメインテナンスされていなければならない。 そうすることで、このボキャブラリーは容易で迅速に理解され使えるものとなる。 ひとつのダイアグラムで表現されている概念は恣意的で複雑なものである。 でも、それらの表現の意味はそうであってはならない。

基本概念

情報アーキテクチャとインタラクションデザインはコインの表裏のようなものであるといってよい（ここで用いられている用語の定義は“ユーザーエクスペリエンスの要素”を参照のこと（訳注：原著））。 現代のウェブサイトのダイアグラムはいうまでもなく両面を持っている。 しかし、これらのに対して、ダイアグラムの目的は微妙に異なっている。

どちらのケースおいても、ダイアグラムはいわゆるマクロストラクチャ（全体像）とよばれるものに焦点を定め、チームメンバーにその全体像を十分に提供する。 アーキテクトの仕事はこの目的にかなった、しかるべきレベルの詳細を決定することである。 さらなる個別のページレベルの詳細、またはマイクロストラクチャは、このアーキテクトが主に開発の責任を負うもの以外のドキュメントで定義される。

情報アーキテクチャを記述する際、ダイアグラムは概念的な構造とコンテンツの組織を強調しなければならない。 ここでいう概念的な構造とは、ナビゲーション構造とは異なる。 情報アーキテクチャのダイアグラムの目的は、完璧なナビゲーションの仕様を提供することではない。 これらのレベルの詳細仕様は、混乱をさけるため別のドキュメントに残しておくべきだ。

インタラクションデザインを記述する際は、ダイアグラムはユーザーが定められたタスクをどのようにたどっていくのか、またそれらのタスクがどのようにタスク分割されているのかをを強調しなければならない。 ナビゲーションなどのインターフェースの詳細はダイアグラムにあらわれてはならないーもしもあなたがボタンやフィールドまでを書き込んでしまっているとしたら、それはたぶんダイアグラムに過剰に情報を詰め込み過ぎだということだ。

このボキャブラリーはインタラクションデザインと情報アーキテクチャの両方を網羅するシンプルな概念モデルに基づいている：

  • システムはユーザーにパスをあたえる。
  • ユーザーはアクションとしてこのパスを動く。
  • この動きは後にシステムに結果を引き起こす。

基本要素：ページ、ファイル、そしてそれらの集まり

ウェブにおける基本的なユーザーエキスペリエンスのユニットとは、いうまでもなく単純な四角形であらわされるページである。 ページはプレゼンテーションのユニットであり、必ずしも実装のユニットで（ある必要）はない。 ダイアグラムの１ページは、（一つのフレームセットインターフェースに入った）複数のHTMLファイルや（サーバーサイドインクルードやデータベース型実装などの）複数のコードのユニットと対応している。

ページに加えて、ナビゲートされない特性を持った固まりとして、ファイルというものがある。 ファイルはウェブブラウザーの外の環境で使うものとしてユーザーに提供される（たとえばオーディオやビデオファイル、またPDFや実行ファイルなどのスタンドアローンドキュメントなど）。 これらには古くからの親しみ深いページの隅が折れているアイコンを使って表すことにしよう。


図1a：［左］ページとファイル
図1b：［右］ページやファイルの集まり

サイトの全体像にあまり重要ではなく、ナビゲーショナルな属性のある機能的に同質のページ郡を表現するために、ページの集まりを使う。 同様に、ファイルの集まりは独立した処理を受けるファイルグループとして表現され、一つの単体として分類できる（例えば、ダウンロード可能なゲームや、PDFの説明書など）。

ページとファイルの確認にはラベルを使う。 これらは、HTMLの<title>エレメントやファイルネームなどの実際の指示と完全に相関関係がある必要はないが、ダイアグラム内での各々のページやファイルのためにユニークでなければならない。 ユニークな数値の識別子とタイプの記号表示は、ダイアグラム内で全てのページとファイルを把握する良い方法である。

関係性の記述：コネクターと矢印

エレメント郡の関係は、簡単な線かコネクターで表される。 これらの概念的な関係は、必ずナビゲーションの関係へと変換される。 しかし、全てのナビゲーションの関係がダイアグラムに表記されるわけではない。

情報アーキテクチャの場合、これらの関係性は一般にツリー型のページのヒエラルキー組織を反映したものとなる。 しかしながら、これは必須というわけではなく、（場合によっては）おすすめできない。


図2a：［左］ 単純なツリー構造
図2b：［右］2aと同じストラクチャーの異なったダイアグラム

インタラクションデザインを図式化する際には、コネクターはどのようにユーザーがシステム内を動き、ある仕事の到達点に達するのか方向を示なければならない。 コネクターを矢印に変えることで、うまく事が運ぶ。 要素の位置の、この前進の動きに対応して、ダウンストリーム、アップストリームという言葉を使うことにしよう。

これらの矢印は、一方通行を表しているのではなく、むしろショッピングモールの食品売り場の進行方向を表している。 ユーザーは反対方向へいくことを禁止されているわけではない： 矢印は単にユーザーがもっとも行きそうな方向を示しているだけである。


図3a： [左上］矢印はタスクの完了のためのダウンストリーム
図3a： [左下］クロスバーはアップストリームの動きが許されないこと表す
図3a： [右］複数の矢印は進行方向を明らかにする。

なんらかの理由でアップストリームへの動きを禁止したいのなら（たとえば記録の削除などの取り消しできないアクションが行われた場合など）、そのことを示すために矢印の反対側の付け根のところに（短い線の）クロスバーを表記する。

ときにはより複雑なアーキテクチャのなかで流れの方向を明確にするために、アップストリームページ付近にもう一つ矢印を付け加える必要があるだろう。 （実践ノート：多くのダイアグラム記述のためのアプリケーションは、このように矢印を一緒に並べて描くことができない。 こうするためには、“グルードット”エレメントを含んだシェイプライブラリーや、単体の接点からなる見えないエレメントなどを使い、矢印をつなぎあわせる。）

コネクターと矢印にもラベルをつけることができる。 しかしこれらの使用は、ユーザーのアクションを具体的に明示したい場合のみに制限しなければいけない。 もしラベルが長くなったり、重くなったり、またダイアグラムを乱したりするようであれば、読者に対して脚注や付録への指示を示そう。

このドキュメントで使われている例では、脚注または付録への参照は括弧でくくられた数字とアルファベット文字のコンビネーションとして示される。 数字はリファレンスのあるダイアグラムのページを、文字は特定の記述を表す。 たとえば、ダイアグラムのページ３の最初の記述は（3a）として、次は(3b)という風に表記される。


図4a: ［左］不必要ななラベル
図4b: ［中］有効なラベル
図4c: ［右］ 脚注または付録参照

すべてを一度に：並列セット

並列セット（半円で表す）は、一人のユーザーのアクションが複合的であったり、同時に起こる結果を引き起こす場合などに使われる。 これは、例えばポップアップウインドウが表示されると同時にメインウインドウにページがロードされたり、またはファイルがダウンロードされているときにページがあらわれたりすることをいう。


図5： 並列セット

矢印のように、並列セットは方向がある。 アップストリーム要素は円の曲線につなげられ、ダウンストリーム要素は平面側につなげられる。

一時中断：連続ポイント

情報アーキテクトたちは、いつも自分たちの仕事をダイアグラム化することのできる広大な用紙を熱望している。 しかしプロッタなどの大規模の作図デバイスが普及したとしても、いくつかのアーキテクチャは複雑すぎるために、一つの網羅的なダイアグラムでは表現できない。

ダイアグラムを簡単に消化できる部分に分けるために、連続ポイント（四角のカッコ）を用いて、ページ同士の接続する。


図6a：［左］他のダイアグラムへの“接続”ポイント。
図6b：［右］図6aからつながっている、“接続される”ポイント。

一つの連続ポイントには必要に応じて一つもしくはそれ以上の起点や目的地がリストアップされる。 括弧の方向（平行か垂直か）は、特に意味はなくアーキテクトの美的判断に依存する。

共通要素：エリアと反復エリア

エリア要素（丸みのある長方形）は、一つもしくはそれ以上の共通の属性を持ったページグループを表している（たとえば同じポップアップウインドウに表示されたり、なんらかのユニークなデザイン処理が施されている、など）。 これらの属性を識別するためラベル表記を行うか、（コネクターと同様に）言わなければならないことが多くあるのなら、ドキュメント中の他の記述を参照する。


図7： ポップアップウインドウを表すときの使用例

多くのアーキテクチャは、いくつかの機能的な情報要素によって構成される、同じ基本ストラクチャの繰り返しを含んでいる。 たとえば、それぞれの商品が複数のページを含んでいるような、商品カタログがあるとしよう。 それぞれの商品についてこの構造の例を描く事は可能であるが、時間の無駄ではないだろうか？ その代わり、反復エリアー丸みのある長方形の集まりーを使えばよい。


図8：製品カタログの反復エリアを表現するときの使用例

コネクターと矢印は、エリアに対しては用いられない。 エリア要素はページを囲むだけである。 エリアは、注意深く用いなければならない。 どのページがどのサーバにホスティングされている、といったようなユーザー体験と無関係な事項も含めて、すべての種類の要素をエリア要素として囲ってしまうことは簡単だが、こうするとマクロストラクチャを伝えるというダイアグラムのそもそもの目的を妨げることになってしまう。

再利用可能な要素：フローエリアと参照

いくつかのインタラクションデザインにおいて、そのデザイン全体を通して異なった文脈において繰り返し現れる一連のステップというものが存在する（たとえばログイン手順など）。 通常これらのシーケンスは、一つあるいはそれより大きなユーザーが達成しようとしているタスクの単なる構成要素にすぎない。 これはコンピュータプログラミングにおけるサブルーチンの概念と似ている。

このような再利用可能なシーケンスはフローとよばれ、２つの要素によってダイアグラムに表現される。 その２つの要素とは、繰り返される流れそのものを囲うフローエリアと、もとの文脈のなかで繰り返しのフローを示すためのフロー参照である。 どちらの要素も角を削がれた長方形（好みに応じて歪んだ８角形でもよい）で基本的に同じ形をしている。


図9a：［左］フロー参照の書式。“～へ”、“～から”の両方を表す。
図9b：［右］ 図9aの記号から参照されるフローエリア

フローエリアはまた、２つの特別な連続ポイントが必要となる。 それはエントリーポイントと、エグジットポイントである。 これらは、複数のダイアグラムによって示されるフローをフローエリアで囲っている外側に配置される。

フロー参照自体は、連続ポイントとよく似たような機能を果たす。 これら２つの要素のタイプの目的は同じであり、それはアーキテクトにページをこえてダイアグラムを分割できるようにすることだ。 両者の違いは、フロー参照は一つのポイントで“～へ”と“～から”の両方を表現することができることである。 もし、この両方の役割が必要ないようであれば、そのときはフローが必要ないときであろう。

条件要素の基本概念

情報アーキテクチャやインタラクションデザインがユーザーのサイトの上での動きに応じてシステムによって動的に生成されることが多くなってきている。 この生成は条件ロジックによって実現されており、またこのボキャブラリーの残りの要素は条件ロジック構造について触れることにしよう。 ここでは、条件要素の応用のための基本概念モデルを示そう。

  • システムは、一つかそれ以上の属性（特性）を保持する。 これらの属性とは以下となる：
    • ユーザー（ユーザータイプなど）
    • セッション（ログイン状況など）
    • アクセスされる内容（目的事項など）
    • もしくは“実世界”の属性（時間や日など）
  • 属性は、値を持つ（“３時”は“日のなかの時間”におけるとられうる値の一つである）。
  • 特定の値を持つ属性の組み合わせをコンディションと呼ぶ。
  • コンディションはシステムによって正かどうか決定するために評価される。

静的なアーキテクチャにおいては、すべてのパスはすべてのユーザーにすべての環境において提示される。 そして、それぞれのパスは常に同じ結果を導き出す。 動的なアーキテクチャにおいては、一つかそれ以上のコンディションの評価に基づいてシステムはどのパスをユーザーに提示するか決定する。

ダイアグラムの複雑さを最小限にするために、これらのコンディションは主として脚注や付録として示すことにしよう。

選択せよ：意志決定点

もしも一回のユーザーアクションがいくつかの結果のうち、一つを生成するのなら、システムはどの結果を提示するのかを決定しなければならない。 （たぶんもっとも一般的な例は、フォーム申し込みにおけるエラー処理だろう。） これらを、意志決定点とよび、従来のフローチャートのようにダイアモンドとして表そう。


図10：ログイン処理における意志決定点の例

意志決定点に関連づけられた要素がアップストリームなのかダウンストリームなのかを明確にするために、意志決定点とともに矢印が用いられなければならない。

先駆者（Pathfinding）：条件的なコネクターと矢印

条件的なコネクター（点線で表記）は、一つもしくはいくつかの条件に応じてパスがユーザーに与えられたりられなかったりするようなときに用いられる。


図11a： ［左］条件的なコネクター
図11b： ［右］条件的な矢印

例えば、会社の社員のみがアクセスできるような微妙な情報を含むページがありえる。 この場合のコンディションはユーザータイプ（社員）となるであろう。 ここでコンディションが条件を満たすときパスは現れ、そうでなければパスは現れない。

（訳注：英語ではpathfindingは先駆者、パイオニアなどの意味を持つ。path（パス）とfind（見つける）とをかけた言葉遊び。）

複数の選択：条件的な分岐

システムがユーザーに提示する相互排他的なオプションのなかから一つのパスを選択するとき、条件的な分岐（三角形）を使おう。 アップストリーム要素は三角形の一つの点につなげられ、ダウンストリーム要素はその反対側につなげられる。


図12： 条件的な分岐

図12に示されている例は、図10の意志決定点の例に多くの点で似ている。 しかし、ここで表されている動きは全く違うものである。 意志決定点の例では、一つのパス（もしくはナビゲーション要素）しかユーザーに提示されない。 このため、ユーザーがたどるパスはいくつかのコンディションに依存していることになる。

図12では、システムは似たような意志決定を行うが、これはユーザーのアクションの前に決められる。 この条件的な分岐はシステムがどのパスをユーザーに提示するかを示している。 ページAからページB、Ｃ、Dへのパスは相互排他的となる。 つまり、もしページBへのパスが存在するのなら、ページC、Dへのパスは存在しないということになる。

条件的なコネクターと矢印と同様に、ある条件的な分岐がユーザーにまったくパスを提示しないことがありうる（空の結果）。 ここでの違いは、条件的な分岐においては空の結果は全く許されない。 もし許されるとしたら、その空の結果が３つあるいはもっと多くの可能性のある結果のうちの一つのときということになる。 この分岐が空の結果を許可するかどうかは脚注か付録に示しておこう。

一つか複数か：条件的な選択肢

条件的な選択肢要素は（台形で表す）、条件的な分岐と似たように機能する。 重要な違いは、選択肢からのダウンストリームパスは相互排他的ではないということである。 条件を満たすパスであれば、ユーザーにいくつでもパスが提供される。


図13： 条件的な選択肢

条件的な選択肢の一般的な応用例はサーチエンジンによる結果だろう。 この場合、検索結果のページは選択肢のアップストリームに現れ、コンディションはユーザーに入力されたキーワード、ダウンストリームパスはサーチエンジンによってインデクシングされたコンテンツページへとつながれる。 条件的な分岐と同様に、条件的な選択肢は空の結果を生成しうる。 実際、これはこれは分岐よりも選択肢の方が一般的にである。

一つの決定、複数のパス：クラスター

いくつかの条件構造では、ある条件に基づいて一つ以上のパスをシステムが提示する必要がある。 これらのパスを構造内でクラスター（円で表示）によって関連づける。 クラスターは、条件的な分岐と条件的な選択肢のどちらダウンストリームにも現れる。


図14： 分岐からダウンストリームするクラスター

図14で表されている構造は、標準の条件的な分岐とよく似ている。 しかしここでは一つの条件に対して、一つ以上のパスがユーザー提示されている。 属性の値がXであったなら、ユーザにはページBへのパスが提示される。 しかし、もし値がYであったなら、ユーザーはページCとDへの両方のパスを見ることになる。

制約条件あり：条件的なエリア

一つもしくはそれ以上の条件がページのグループに適応されるとき、それらのページは条件的なエリアとして囲まれる。 これは標準エリアと似た丸い角の長方形、しかし条件的なコネクターと同じ点線で表現される。


図15： 安全な接続が要求される条件的なエリアの使用例

条件的なエリアは、ログインやSSLによる暗号化が必要となるようなアクセス許可が必要となるような状況で用いられる。 他のエリアと異なり、条件的なエリアは、１つあるいは複数の条件が満たされていないようなイベントの結果と関連している。

結論

どのように全システムが機能しているか御覧になりたいのなら、こちらにMetaFillerのインタラクションデザインと情報アーキテクトのダイアグラムの例があります（私自身このサイトの設計には加わっていません。このダイアグラムは、このサイトから単純に再考したものです）。

Scott Larsonは簡単に様々な要素を参照できるこのハンディカンニングチャートを製作しました。 これ以上のもっと多くのボキャブラリーを使って、自分自身のライブラリを形作っていきたい方のためにPDFがここにあります（Ross Olson、提案ありがとう）。

このボキャブラリーは初めのステップを示したにすぎません。 ウェブの情報アーキテクチャとインタラクションデザインが進化すれば、状況は否応なく変化し、このボキャブラリーは対応しえなくなるでしょう。 あなたのフィードバックとアドバイスが、次のバージョンに大きく役に立つこととなるでしょう。

（訳注：これらのドキュメント（PDF）は和訳されていません。）

ダウンロード可能なパーツライブラリ

OmniGraffle2.0がビジュアルボキャブラリをとりいれた最初のアプリケーションです。 OmniGraffleは最近ではパワーマック、パワーブックにあらかじめインストールされている。 またOmniのサイトから直接ダウンロードも可能である。

（訳注：現在のバージョンのMacOS Xには同梱されていないようです。また、日本ではOmniGraffleはAct2から購入可能です。）

他のシェイプライブラリはこちらから（訳注：英語版です）：

(C) 2000-2002 Jesse James Garrett
This document (original): http://www.jjg.net/ia/visvocab/
(In Japanese): http://www.concentinc.jp/ia/visvocab/
More IA resources: http://www.jjg.net/ia/