Webサイトのイメージチャンプルー

あたらしいWebサイトを作るとき、サイトの存在価値や運用上の目標が定まったならば、次に、サイトの具体的な姿についてのイメージを、クライアントも含めたプロジェクトメンバー全員の間でしっかり共有しておくことが肝心です。これがきちんとできていないと、細部をつめていくごとに、みんながてんでばらばらなことを言い出して、Webディレクターは悲しい思いをすることになります。

しかし、Webサイトのイメージをみんなで共有しようとして、いきなりラフスケッチとかワイヤーフレームとかモックアップとかプロトタイプとか、画面のイメージに近づこうとするとのは、ぼくは間違いだと思います。これらは、それぞれ、広い意味でのユーザーテストの対象といっていい、中間成果物です。

ラフスケッチをユーザーテストの対象というと、奇異に聞こえるかも知れませんが、それをレビューする側は、スケッチから読みとれるナビゲーションやコンテンツの片鱗をヒントに、頭の中でいろいろと補完して、そこから何が読みとれ、そこでどんなアクションを起こしうるかシミュレーションするわけです。脳内の想像的なユーザー体験がうまくいかないと、ラフスケッチのあちこちを指さして、これはどういう意味？、ここはなんでこうなってるの？とラフスケッチを描いた人の頭の中にあるイメージを問い質すことになります。でも、それこそ、あらかじめ共有しようとしていたものでしょう。

どんなに粒度が粗い状態であれ、画面というのは常に最後の難関なんだと思います。画面は何かを表現するものですが、そこで表現されるものをプロジェクトメンバーの間で共有する目的でなら、画面よりももっと端的で直接的な方法があると思います。

たとえば、そのサイトに訪れたユーザーに一体どんな経験が待っているのか、ユースケース図やユースケース記述を書くほうがいい場合があります。また、ユーザーとWebサイトとの間の具体的なインタラクションに特徴があるなら、その部分をシーケンス図で書くほうがいいでしょう。あるいは、情報のカテゴライズに工夫があるなら、ツリー状のサイトマップを書けばいいでしょう。そして、そうしたさまざまな表現方法を必要に応じて大胆に混ぜながら、全体として共有されるべきイメージが描き出せればいいはずです。Webサイトのイメージチャンプルーですね。これは、あくまでもテストのアンチョコであって、けっしてそれ自体がテストされるようなものであってはなりません。

そして、イメージチャンプルーで明らかにされたことをうまく画面表現に変換できるかどうかを探るためにラフスケッチを描き、発見された画面表現の一貫性を確認するためにワイヤーフレームを描き、ワイヤーフレームに基づいた最終的な視覚表現の良し悪しを評価するためにモックアップを作成し、インタラクションのユーザビリティをチェックするためにプロトタイピングするわけです。

だから、web creators 2009年1月号の特集ページで「Web サイト制作をラフスケッチから始める」とか、「ラフスケッチでイメージを共有する」とかいう見出しが掲げられているのを見ると、正直、ちょっと違和感を覚えてしまいます。

もちろんチャンプルーの一部として、ラフスケッチを使うことが有効なケースはありえます。たとえば、レイアウトやインターフェースデザインの独自性を狙う場合など。しかし、ラフスケッチをWebサイトのイメージを共有するためのキラーメソッドだとしてしまうのには無理があります。

実は、ぼくの職場は元々編集プロダクションだったこともあって、ある時期までまさにラフスケッチドリブンな制作を行っていました。そしてその結果、以上の認識にいたるような失敗を繰り返してきたのです。いや、今でも、ラフスケッチをワイヤーフレームと言い換えただけで（これ自体間違いなんですが）、同じ失敗を繰り返してしまうことがあるくらいです。

ユーザーテストを軽視してきてしまったのも、「編集部員」がラフスケッチ＝ワイヤーフレームを描いて「編集長」や「デスク」にレビューを乞うというプロセスが、不十分なかたちでユーザーテストを先取りしてしまっていたからではないか、などと疑っています。

なんていう自戒をこめつつ、Web サイトのイメージを共有するならチャンプルーでいこう、だから Web ディレクターたるものいろんな作図法に明るくなくちゃね、と、少なくとも自分の周りには強く主張したい次第です。

-----------------
sent from W-ZERO3