ワイヤーフレームコミュニケーション研究会

「ワイヤーフレーム (Wireframe)」という言葉を知ったのは多分2001年ごろだと思います。その当時は小さな制作会社でウェブディレクターの駆け出しだったと記憶しているのですが、「ワイヤーフレーム」「サイトストラクチャ」といった資料をいただく機会があり、当時の役割である制作・実装を踏まえて、不具合をなるべくなくなるような仕様書として理解していたと思います。そのせいで、整合性がとれてない箇所を見つけては修正する、を繰り返していたと思います。

• ワイヤーフレームコミュニケーション研究会

2009年7月24日 (金)、FXBの原一浩さんがTwitter上でつぶやいた一言から開催に至ったワイヤーフレームコミュニケーション勉強会に参加しました。場所はSINAPさんのオフィスで総勢30名となかなかの大人数で大盛況でした。

詳しくは、SINAPさんのサイトに原さんからのレポートも掲載していただいているようですのでそちらをご覧ください。

• 「ワイヤーフレームコミュニケーション研究会」第一回レポート – SINAPlog

研究会のトピックは以下の5つ。

• ワイヤーフレームって何ですか?
• ワイヤーフレームにデザイナーが引っ張られてしまった経験は?
• デザイナーが引っ張られないワイヤーフレームを作るにはどんな工夫が考えられるか?
• コミュニケーションとしてのワイヤーフレームとドキュメントとしてのワイヤーフレームがある?
• ワイヤーフレームの共通ガイドラインはあったほうがいいと思いますか?

原さんが作成されたスライドも公開されています。

• 第1回ワイヤーフレーム研究会のスライドをダウンロードする（PDF）

参加者について「ワイヤーフレームについて思い悩むことが多いディレクターが一番多い印象でした。デザイナーが3割くらい、発注側であるWeb担当者が1割ほどといった感じ」とあるので、実際にはウェブ制作会社のいわゆるウェブディレクターが多かったように思います。

いろいろなディスカッションをしていく中で個人的に感じたのは――

• 自分のバックグラウンド (デザイナー出身かエンジニア出身か)
• 自分のポジション (顧客に接する機会が多いのかそうでないのか)
• 自分が所属する組織 (社内で制作をしているのかそうでないのか)

といったポイントが人によりさまざまなため、参加者同士でも意見が合致せずそれぞれの主張でしかなかった印象でした。ただ、これからもこの悩みは続くと思いますし解決できる部分と解決できない部分とがあると思うので個人的に思うところを書き出してみたいと思います。

1. ドキュメントの目的や使われ方、誰のためのものかを明示的にする必要がある (IA One Sheeter参照)
2. ドキュメントの書式はできるだけ標準的な (※業界一般的に浸透している) ものを利用する

このうち1について状況が違えば、やはり話はズレますし求めているポイントも違うことになります。自分の状況があたかも相手もわかっているだろうと思ってしまうとやっぱり話がズレたままになってしまいディスカッションも消化不良になってしまいます。また、1を踏まえての2でもあるため、結論として1の前提を揃えた上でディスカッションをしないと本質的な解は得られにくいのだと思います。

ただ、個人的に言えるのはどの状況においても共通して――

• ワイヤーフレーム作成の後工程をきちんと考慮すべき (誰が行い・どのように進めるのか)

これに尽きるかと思います。

たとえば、自分がデザイナーだとして表現方法をわかりやすく顧客に説明するために必要な資料とはどういうものか。おそらくオブジェクトのクラス名や数値は不要でしょう。反対に、自分がディレクターとしてデザイナーに表現を依頼するのであれば、表現と見間違う装飾的な要素は不要でしょう。

そうして考えてみると、悩みの根本的なところはその後工程のことがわかっていないことに起因するように思います。もちろん後工程のことはわからなくて結構という意見もあるとは思いますが、結局のところ自分がやろうとしている方向性や実現性を担保するためには、実現する方法や手段を知識として身につけるということと、実現する人とのコミュニケーションが最も大事なことなのかも知れません。

「ワイヤーフレーム」についてはこれまでのエントリーでもいろいろ書いてはいますが、「ウェブサイトの設計図 ワイヤーフレームを活用しよう」にいくつかまとまっていますので、興味ある方はそちらも参照ください。