最近、ia-j（情報アーキテクチャアソシエーションジャパン）のMLでIA用語の訳語を整理をしようというやりとりが活発にされています。その中の一つにWireframe(ワイヤーフレーム)が挙げられているのですが、最近個人的にも社内でWireframeってなによ！って議論があったりしたので、簡単に脳内を整理しておこうと思います。
Wireframe（ワイヤーフレーム）とは？
ウェブサイトを構成する要素（ナビゲーション、見出し、ボタンなど）を画面単位で記述したウェブサイトの設計資料の一つ。どのような要素が存在し、どこの場所に配置されるかを定義する。ビジュアライズされたデザインとの混同をさけるため、線画で記述されるのが一般的。
上記は個人的な定義ですが、IAIの用語集には以下のように記載されています。
A wireframe, also known as page architecture, page schematic, or blueprint, is a highly simplified sketch of the important information in a page.
The goal is to reflect the relative importance of different elements, including the content and the navigation….see more
ページの情報を単純に視覚化したもので、コンテンツやナビゲーションなどの各要素の優先度を定義する、といったところでしょうか。ただし、人・会社によっていくつか争点になるというか、異なる点があります。例えば
- 要素のレイアウトをどの程度まで精密に規定するか。
- ボタンやフォームなど、UIの挙動を記述するか。
- 画像やテキストなどのコンテンツを含むか。
- 全画面分作成するべきか。
- 公開後の変更をどこまで追記するか。
これらに関しては、それぞれの会社やプロジェクト、Wireframeを作成する人の職域で決めればよいとは思いますが、個人的には、以下のようにすることが多いです。
- レイアウトは相対的な位置（右寄り左寄りなど）や要素の優先順位のみを定義する。
- UIの挙動などの仕様に関しては、機能リストとして別途切り出す。
- コンテンツ自体は、基本的には含まずにコンテンツリストとして別途切り出す。ただしナビゲーションのラベルなど設計を確認するために想起されたほうがよい要素に関しては記述する。
- 画面のフォーマット分だけ作成する。
- あくまで設計用の資料なので、コスト的に余裕がある場合のみ現行仕様を反映する。
例えば、機能リストとして切り出しておけば、テストの際のチェックリストとしても活用できるし、コンテンツリストなどはライターや担当者に入力をしてもらうケースがあったりする切り出しておいたほうが便利。画面数に関しては、後行程の人（コーダーやプログラマ）の人に理解される程度にパターン化。画面のフォーマットもページリストなどで管理するのがよいかと。
経験上、高精細なWireframeはそれ自体の目的が”設計”という点から外れてしまうケースが多いので好きでありません。もちろんデザイナーでもないので、ピクセル単位でレイアウトも規定すること自体できないという事もありますが。
結局結論としては、結局Wireframeは設計に関する要求をすべて提示できるものではないので、その他の資料と組み合わた上で、何をどこまで定義すべきと決めるのがよいのではないでしょうか。
