本とかソフトウェアとか、あるいは、テレビの夜中の通販で取り扱っているものとか、自分のものにするまで、よくわからないことが多いものを買うときは、すでに自分のものにした人たちの意見を聞きたくなりますよね。
Amazonの評価とかね、もともとは立ち読みできないことを補うって発想だったのかも知れないけど、ぼんやりした自分の頭だけで立ち読みして判断するより、なんていうか、よっぽど、機能的ですよね。
購入を検討している人にとっての評判の確認って、ふたつ効果があるんだと思います。
第一に、こんなの買っちゃって自分だけが馬鹿を見るんじゃないかっていう不安や迷いの解消ですよね。それがそもそもの目的だし、本人も自覚していることですね。
あと、もうひとつ、そうやって先行する人たちの自慢を見せつけられているうちに、つい羨ましくなっちゃって勢いづいちゃう、という面もあると思うんですよね。
バイラルとかクチコミとかって、存在そのものを知らしめる手段としてターゲティングやコストの面で効果的ってだけじゃなくて、リーチのプロセスそのものが、そうやって購入動機の形成や購入の決心に良い影響を与えるからいいんですよね。
じゃあ、あれはどうでしょう？通販サイトとかで、ユーザーの皆様から喜びの声が続々 ... とかってやるやつ。
今、まじめに考えて、Amazonの評価とか他のブログや掲示板に書き込まれたレビューと、売り込もうとしている張本人が仕込んだに違いない、宣伝媒体に掲載されているユーザーの声を、同じものとしては受け取れないですよね。
いや、でも、それは、Webがあってこその比較なのかも知れないですけどね。
ブログやらSNSやら、もう全体として「評判データーベース」と呼んでもそんなに的外れじゃないような代物が目の前にあって、いうなれば、一億総レビュアー時代、今こうしている間にもきっとどこかで誰かが何かをレビューしているのです、ほら、あなたの隣にもって具合ですから。
つまり、売り手でもすでに買い手でもない"第三者"に、これだけアクセスしやすい状況は、Web以前になかったわけでしょう。
でも、購入前の評判の確認をめぐる動機や効果はWebとは関係なく昔からあって。すると、パンフレットやテレビ番組で、そこんところに刺さる情報をを提供しようとすれば、おのずと、おなじみの、ユーザーの皆様から喜びの声が続々 ... というかたちにならざるをえない。
話はそれますけど、こういうふうに、コンピューターやネットワークが発達してみて、これまでの実現形態やデザインが実は次善の策だったり挫折形態だったことが判るってことは結構あるような気がしますね。たとえば辞書とかね。あれは明らかに紙媒体には向かないコンテンツでしょう。
長い年月の間、辞書が分厚い冊子としてあったのは、それがベストだったからではなくて、それ以外にやりようがなかったからですよね。
それはともかく。
で、その喜びの声ですけども、でもね、テレビの通販番組なんか見てると、上に挙げた評判の確認の効果とは別の意味で有意義に活用されているな、とも思うんですよね。
セールストークの基本は、セールスポイントを繰り返し説いて、強調して、ユーザをその気にさせることですよね。しかし、売り子の目線と言葉で繰り返してると、ほんとに同じことに繰り返しになって飽きられちゃう。そのとき、有効なのが、喜びの声ですよね。
代わる代わる違う人が出てきて、結局はいくつかのセールスポイントに収斂していく話をするわけです。
これで、言葉は悪いかも知れないですけど、飽きさせずに同じことを刷り込んだり、植え付けたりできるようになる。
仕込まれた喜びの声だから話半分で聞くわけですけれども、ここには、スリーパー効果ってのがあるそうです。あまり信頼できない人から真偽のほどが定かではないことを聞くと、その場では胡散臭く思う。
でも、時間がたつと、話の内容と話した人から受けた印象は記憶の中でだんだん切り離されていくんだそうです。で、結果として、話の内容にまとわりついていた胡散臭さはとれちゃって、セールスポイントだけがフラットに残る。
そのへん、ちゃんと狙って作ってるのかなあ、とも思うんですよね。
そんなわけで、外部により信頼のおける第三者の声があふれかえっている世界においても、売り手の宣伝媒体における喜びの声にまったく意味がなくなったわけではないと思います。
だから、たとえば、ぼくらが何かのプロモーションサイトなんかを作っていく上では、喜びの声は、そうした、セールストークをリフレインするための手法として考えていくのがいいんだと思います。
間違っても、かつて喜びの声にも期待されていた、購入の一歩手前にいる人の背中を押すという役割を担わせようなんて思ってはなりません。
そっちは、正々堂々、外部のブログとか評価サイトとかにまかせる、というか、購入を検討してくれた人はたぶん自分で探しにいくんだろうから、サービスとしてそういう外部リソースのアグリゲーションくらいやってあげてもいいんじゃないでしょうか。仮にマイナスの評価が含まれてしまうとしても、あえて大目にみて太っ腹にね、公正に。
きっとそのほうがユーザーの皆さんとはやく仲良くなれますよ。
2008年12月16日火曜日
思わず完成させたくなるような立派なコンファメーション
入力フォームのデザインやユーザビリティ、それに HTML/CSS のコーディングのしかたについてはたくさん語られもするし、いろいろなサンプルが出回ってもいるんですが、確認画面、コンファメーションのところはどうなんでしょうね。
一回送信してしまったらあとで編集したり取り消したりできないような情報の登録については、この内容でよろしいですか？なんて画面を必ず挟むわけですけど、あれのうまいやり方とか、やってしまいがちな失敗とか、そういうのって何かありますかね。
なんとなく前から思っているのは、あれ、あんまり入力フォームに似てちゃ駄目なんじゃないでしょうか。たんに入力フォームの部分がテキストになっているだけみたいなのだと、面倒くさいのを我慢して今入れたばっかりのをもう一回あたまからなぞらされるなんてもううんざり、なんて、結局スルーされちゃいがちなんじゃないかって。
ブログ書いてても、編集画面では全然目にとまらなかった誤字脱字が、公開ページではパッと発見できたり、eラーニング教材のデータを作っていても、データを入力したメディアで何度も文字校正をかけたはずなのに、実際の学習画面を見始めると、また急にあちこちに修正が入ったりして。
結局、入力内容の確認は、入力時とは異なる見栄えでやったほうが有利ってことなんでしょうか。経験的にいっても、慣れや飽きが注意の敵なんだというのはなんとなくわかりますしね。
じゃあ、事前に空欄の確認用レイアウトを見せて、これを完成させるために入力フォームを使うって了解にもとづいて入力してもらうのはどうですかね。入力し終わったときのユーザーの気持ちが、うまくできたかな？になるような。ブログとかのプレビューがそれに近いわけですけれども。なんか Ｆlash とかで立派な申請用紙みたいなのができてるとかね。無駄かな。
細かい話ですけど、入力のしやすさ、データ表現の揺れの回避、あるいはデータの取り扱いやすさのために、入力欄を分けることはあっても、確認するときはそれらをまとめて表示したほうがユーザーとしては目や頭に入れやすいってものもありますよね。入力の都合の単位とユーザーが把握しやすい情報のチャンクは必ずしも一致しないわけで。姓名、住所、電話番号、日時とかね。だから、あながち、完成させたくなるようなやたら立派な確認画面ってのも、無駄にゴージャスなだけってわけでもないような気がするんですよね。
-----------------
sent from W-ZERO3
2008年12月12日金曜日
ネットの万次郎
夜中にケーブルTVで同時通訳も字幕もなくなったCNNに見入っちゃうことがあります。番組にしろCMにしろ、ビジュアルの作り方が日本のTVとは大分違ってておもしろいんで、何いってるかよくわからないながらも、頭からっぽでついボーっと見続けちゃうんですよね。そうしてみると、英語もまったく聞き取れないわけじゃなくて、知っている言葉はちゃんとわかるな、っていうか、聞いてると、今のあれか、って、知っている単語のスペルやカタカナと今聞こえた音声が急に一致する瞬間があって、地味に小さな感動を覚えたりします。いや、アホ丸出しで恥ずかしい話なんでけど、そうなんです。
だから、
英語ができないたった１つの決定的な理由
http://anond.hatelabo.jp/20081101050330
http://blog.livedoor.jp/dankogai/archives/51133522.html
なんかで言われていることは本当なんだろうな、とか思って、ふだん英語なんておれには無縁と決め込んで暮らしてても、ちょっと乗ってみたくなりますね。
しかし振り返ってみると、中学から大学出るまで、覚えさせられた英単語のそれぞれをネイティブがどう発音しているのか、ほとんど確かめてこなかったような気がします。だめだこりゃ、ってかんじですよね。今や、goo や excite の英和辞書には音声がついてるし、電子辞書でもそういうのがあるんだろうし、昔より格段にネイティブの発音を確かめやすい環境が整っているでしょう。今、中学生や高校生をやってたらちょっとは違うのかな、どうなんでしょう。心がけ次第っていやそれまでですけど。
そういう意味では、iKnow! のブックマークレットがすごいですよね。ブラウザに表示されている英単語の訳だけじゃなく発音までその場で確認できるというやつ。
http://www.iknow.co.jp/bookmarklet
できれば、マウスオーバーで音まで出るといいんですけどね。そしたらこれと一緒に毎日適当にIT系のニュースを追っかけていくだけでもけっこう英語が聞き取れるようになれそうな気がしちゃいます。ってそれは気のせいかな。
あと、上に紹介したURLで、dankogai さんがいってることも、そうかもなーって思うんですよね。要するに、あれでしょ、パックン英検みたいにして、和英じゃなく、英英で、語句の意味のネットワークを自分の頭の中に作り上げていくのがほんとの近道、ってことですよね。
パックン英検
http://www.nhk.or.jp/night/pakkun.htm
思うに、ジョン万次郎なんて、そうやってがんばったんでしょうね。これなんていうの？これどういう意味？って聞いても、英語でしか返ってこないわけで。たぶん五感との対応で直感的に了解できる語を自分のものにするところからはじめてね。
そういえば、学習したい言語で日記を書いて、それをネイティブの人に添削してもらって、その一方で、自分は自分の母国語で書かれた外国人の日記を添削してあげるという lang-8 ってありますよね。
これは外国語学習のグローバルなエコシステムってかんじで、なんて素晴らしい実践なんだろうと思うんですけど、これをパックン英検でやったらおもしろそうじゃないですか。
各国とも自分の国の言葉のうち基本中の基本で使用頻度の高そうなのを2000ぐらいピックアップして、みんなでその語句の意味を外国人に聞かれたつもりで、なるべく平易な言葉つかいでわかりやすく説明してみるんです。できれば音声で、だめならテキストで、音声かテキストにイラストや写真を添えるのはOKにして登録。で、それをいろんな切り口でまとめて、ID3タグつきのMP3とかでダウンロードできるようにしたりして。
なんていうんでしょう、ひとつの言葉の意味を確かめるのに、いろんな人の説明を聞いてみるってかんじで。そういえば、CNNを英語がわからないながらに聞いていると、話す人によって、なんか聞こえてくる語感の印象がけっこう違うんですよね。
いろんな人の、それぞれに他とは微妙に違う感じのする音声にたくさん触れて、そういう言葉をしゃべっている人たちがうじゃうじゃ確かに存在していることを感じながらボキャブラリーを増やしていくのって、学習方法としてもけっこう効果的なものになりそうな気がしませんか。教えてくれる人のキャラがたってたりして、その人なりに一生懸命説明してくれている様子が伝わってきたりすると、いわゆるエピソード記憶としても心に残りそうでしょ。特に中学生になって英語を習い始めるときなんか、最初にまとめて聞く英語が日本人教師の日本語なまりのっていうのよりは、だいぶいいんじゃないでしょうか。
さて、教えてもらったら、教えてくれた人にちゃんとありがとうと言うのが礼儀ですよね。だから、どんなんでもいいから、音声でもテキストでも、感謝のメッセージを送れるようにしておくんです。それと、自国人としてみて、その説明はうまい！というのをオススメできるようにもしておく。で、それらの数をポイントとしてみて、登録された説明をレーティングしてみたりして。そうやって自分の国の言葉の意味やニュアンスをどううまく説明できるものか、みんなで知恵を出し合っていく、すると、それが自国語を学びたい外国人のためになると。で、それはめぐりめぐって、ちゃんとお互い様になっている。
いやあ、なんていうか、実に愛にあふれた、善のかたまりみたいな活動じゃないですか、これ。いかがなもんでしょう。
-----------------
sent from W-ZERO3
2008年12月9日火曜日
サイトメッセージチャートの書き方
前に、サイトストラクチャからいきなりワイヤーフレームを描くのは乱暴で、その間に「サイトメッセージチャート」といって、各ページでユーザーに提示されるメッセージとページ間を結ぶユーザー導線を一望するような図を描いてみるのはどうか、というエントリーを書きました。
http://chushoww.blogspot.com/2008/09/blog-post_23.html
で、これを描くためのツールをずっと探していたのですが、いろいろ試してみた結果、Judeのステートチャート図で描くのがよさげ、という結論に達しました。
ためしに、Firefox の製品情報サイトを図にしてみたのがこれです。
http://dl.getdropbox.com/u/223789/site_message_chart_sample.png
こう書いてしまうと、じつにあっけないもんですよね。しかし、このあっけなさで、サイトデザインをいったん把握しておきたいんですよね。そうしないとワイヤーフレームを描くという行為がなんだか当てずっぽうなものになってしまうわけで。
さて、以下、作図のしかたの簡単な説明なんですけど、Jude でステートチャート図を描いた経験があることが前提になってしまいますので、悪しからず。
いや、特に知らなければ読みとれない記法があるわけでもないですし、その気になればパワポなんかで書いてもいいわけです。Jude じゃなきゃ書けないというわけではありませんよ。念のため。だけど、この図を描くのに、なるべく作図のオペレーションに気をとられないようにするには、と考えたときに Jude がおすすめかな、ということです。
えー、前置きが長くなりました。では、いきます。
一見しておわかりいただけるように、なにしろ「ステート(状態)」をページに見立てて描いていくわけです。当然、ステートの「名前」はページのタイトルになりますね。
そして、ステートの「内部遷移」の「イベント」に、当該のページにおけるユーザーへのメッセージを書きます。「イベント」と一緒に「ガード」と「アクション」を入力できますが、ふつう、これらを使うことはないでしょう。でも、ある条件の下でのみ表示されるメッセージの場合は、条件を「ガード」に入力するのがいいかもしれませんね。メッセージの記述順は、ユーザに提示する順番、もしくは、重要度の高いものから、と考えてよいでしょう。
ページ遷移=ユーザー導線は、「遷移」の矢印つきの線でページとページを結ぶことで表現します。「遷移」の「イベント」に、当該の導線に対応するリンクやボタンのラベル名を入力します。「アクション」には、その際の、ユーザーの動機や要求を想像して入力しておきます。
Jude のステートチャート図では、ステートを入れ子にすることができます。
必要に応じて複数のページをグルーピングしておくと、作図が冗長になる(導線だらけになる)のを避けることができます。グルーピングのためのステートの「名前」にはグループのタイトルを入力します。グループの「名前」は、それがページではないことをあらわすための記号(例:"▼")から始まるようにするといいでしょう。
また、グループ内に含まれるページに共通するナビゲーション上の要件や特徴を明示したい場合は、グループのステートの「ステレオタイプ」に書いておくのがよさそうです。たとえば、ランダムにアクセスされる並列コンテンツの一群であれば「ランダムアクセス」とか。認証が必要なコンテンツの一群であれば「要認証」とか。
このようにして、あるページでユーザーに提示されるメッセージの内容とオプションのラベル、あるオプションを選択するユーザーの動機や要求、そして、オプションを選択した結果として提示される次のメッセージの内容とオプションのラベル... と、こういった流れがスムーズに、自然につながっていることを確認しながら、要件段階で定義されたサイトの目的とユーザーのニーズをページに分解していけばいいのではないかと、こういうわけです。
しかし、いまのところ、いってみれば、これはプロトタイピングの段階ですね。これからいろんなケースに適用してみながら、本当に使って役立つものになるのかどうか、見極めていきたいと思います。
-----------------
sent from W-ZERO3
2008年12月5日金曜日
リッピングしてシンクしてあとで読む
通勤中や移動中の電車の中、w-zero3 の IEで、はてブをみたり、青空文庫を読んだり、気になったことをググったりします。でも通信で待たされたり、通信が途切れたり、いくらフルブラウザっていっても、PC向けのデザイン、レイアウトをこの中にレンダリングするってのにはやっぱり無理があったりで、相当に便利なんだけど、快適かっていうと、あんまりそうでもない。
いや、何か検索したいときってのは、不思議とそういう困難も、べつにたいして気にならないんですよね。もう、探すってこと自体が、いろんな検索キーワードの組み合わせを試したりして、全体に試行錯誤上等のチャレンジングな行為だからかもしれませんね。
でも、ぼーっと、はてブを斜め読みしたいときなんかは、通信やレンダリングがうまくいってないと、ああ、もう！ってすぐ思っちゃいますね。読むこと以外のことに気を使う時間が長すぎる！って。
ね、おんなじツールの話でも、コンテクストによってこうも違うわけですよ、ユーザー体験って。なんてね。
それはともかく。で、思ったんですけど、検索は今のままでいい。その気になれば、モバイルでどこにいてもインターネットのリソースにアクセスできることが担保されているっていうのは非常にすばらしい。でも、なんかちょっと時間をみつけての軽い読書、っていうか、雑誌や新聞に目を通すような体験は、今のままではつらいんで、これはたとえば、iPod=iTunesモデルで臨むべきかもなって。リッピングしてシンクしてあとで読む、みたいなかんじ。もちろん PC ありきの話として。
いや、話は単純で、リッピングって、ようするにダウンローダーですね。PCでフィードを読んで、新着 URLの内容をダウンロードしておく。ただ、Googleやはてながやっているモバイル向け変換を施してね。あれは、大変助かります。でも、権利関係的にはどうなのかな、とちょっと疑問でしたが、これならいいでしょ。個人の楽しみだけのためで。
それで、w-zero3 を PC に接続すると、ダウンロードしといたのを、だーっと Active Sync でシンクっていうか、w-zero3 に取り込んでね、で、あとでオフラインで読むと。
これ、どうでしょう。iTuneに相当するものとして、livedoor Reader みたなやつがあったりして。
そういえば、サイドフィードのサービスで、「あとで読も」っていうのがありましたね。
http://press.sidefeed.com/archives/2007/01/post_15.html
これしばらく気にいって使ってたんですけど、ぼく実は非常に怠けもので、人がブックマークしてくれたやつを読みたいんですよね ... 。
-----------------
sent from W-ZERO3
2008年12月3日水曜日
アクセスレポートは自然に出こない
Google Analytics のおかげで、Webサイトのアクセス状況を把握するのもずいぶん楽になりましたが、ケータイサイトではその恩恵に与れないんで、必要に迫られて http の生ログと格闘することもしばしばです。ＰＣ向けのサイトにしたって、なんでもかんでも全部 Google 頼みでいいかというと、規模やその他諸々の事情でそうはいかない場合もありますしね。
そもそも、Google Analytics を使うかどうかも含めて、要求段階でアクセスレポートについての定義が行われるべきだし、サイトストラクチャを書いてユーザー導線設計を行う際にも、ロギングについての計画があわせて検討されるべきですよね。それは直接に URL 設計に影響を与えるだろうし、HTTPのアクセスログの解析では得られないデータが要求されるのであれば、当然、専用のロギングシステムの実装を検討しなければいけないわけだし。
Web のメディアとしての特性のひとつは効果測定を正確に行えるところにあって、なんつっても、それって、だまってほっといてちゃなかなか容易なことではないんですよね。バンバン記録しといてください、あとでびっしびし読み解きますから、なんていうのは、実はぜんぜん通用しない。ログというものはあっと言う間に膨れ上がるもんで、そうそう手放しで長期間とっておけるもんでもないし、あとでこれこれこういう切り口で集計したいっていっても、げんに今ある数々のURLのバリエーションから、はたしてそうしたまとまりをつかみ出せるかどうかわからない。
このあいだ自分でHTTPの生ログを相手にそういう後出しの集計をやってみて、その無謀さをほとほと思い知らされました。これはじつに面倒くさい。
で、そうやって、ロギングについて思いをいたしてみると、この領域はメディア特性の一大特徴みたいに言われるわりには、けっこうまだまだプリミティブな状態にあるんじゃないかなあ、とも思うんですよね。
たとえば、ロギングの単位、じゃなくて、集計の単位は必ずしも URL じゃないんじゃないか、とか。まあ、これは集計ツールの汎用性をいかに担保するかということにも絡むんですけど、しかし、よくクライアントから求められるのは、あるセクションの（１）トップページと（２）その下位階層全体のアクセスレポートなんてかんじだったりします。把握したいアクセスの粒度はそれくらい大ざっぱで、また、下位階層っていうときの階層って、URL のパスの階層と一致しない場合もあるんですよね。効果測定の対象は、そういうふうに認識されているコンテンツのまとまりなんであって、けっして、URLがその表現となるようなデータ構造ではない、っていうか。
プリミティブっていいましたけど、たぶんサーバーを運用するエンジニア向けのレポートと、マーケティング向けのレポートが未分化なんですよね。いや、もともと、たいていのアクセスログ解析ツールは前者の要求に応じて作られてきたわけなんでしょう。Google Analytics は、そこのところを後者にふってみたという意味で画期的だったんですね。でも、まだ、前者にひきずられているような気もします。
ユーザー導線設計の抽象度にフィットしたロギングの定義を事前に行って、マーケティング指向に対して必要充分なアクセスレポートを残すことをサポートするような、CＭＳ なり、Web アプリケーションフレームワークなりが出てくるといいなって思うんですけど、どうでしょうね。まあ、まずはそこまでいかなくても、個別の案件で、プログラマーと相談しながらそういう方向を追求してみたいなと思ってます。それもWebサイトデザインのうちってことで。
-----------------
sent from W-ZERO3
2008年12月2日火曜日
Webサイトのイメージチャンプルー
あたらしいWebサイトを作るとき、サイトの存在価値や運用上の目標が定まったならば、次に、サイトの具体的な姿についてのイメージを、クライアントも含めたプロジェクトメンバー全員の間でしっかり共有しておくことが肝心です。これがきちんとできていないと、細部をつめていくごとに、みんながてんでばらばらなことを言い出して、Webディレクターは悲しい思いをすることになります。
しかし、Webサイトのイメージをみんなで共有しようとして、いきなりラフスケッチとかワイヤーフレームとかモックアップとかプロトタイプとか、画面のイメージに近づこうとするとのは、ぼくは間違いだと思います。これらは、それぞれ、広い意味でのユーザーテストの対象といっていい、中間成果物です。
ラフスケッチをユーザーテストの対象というと、奇異に聞こえるかも知れませんが、それをレビューする側は、スケッチから読みとれるナビゲーションやコンテンツの片鱗をヒントに、頭の中でいろいろと補完して、そこから何が読みとれ、そこでどんなアクションを起こしうるかシミュレーションするわけです。脳内の想像的なユーザー体験がうまくいかないと、ラフスケッチのあちこちを指さして、これはどういう意味？、ここはなんでこうなってるの？とラフスケッチを描いた人の頭の中にあるイメージを問い質すことになります。でも、それこそ、あらかじめ共有しようとしていたものでしょう。
どんなに粒度が粗い状態であれ、画面というのは常に最後の難関なんだと思います。画面は何かを表現するものですが、そこで表現されるものをプロジェクトメンバーの間で共有する目的でなら、画面よりももっと端的で直接的な方法があると思います。
たとえば、そのサイトに訪れたユーザーに一体どんな経験が待っているのか、ユースケース図やユースケース記述を書くほうがいい場合があります。また、ユーザーとWebサイトとの間の具体的なインタラクションに特徴があるなら、その部分をシーケンス図で書くほうがいいでしょう。あるいは、情報のカテゴライズに工夫があるなら、ツリー状のサイトマップを書けばいいでしょう。そして、そうしたさまざまな表現方法を必要に応じて大胆に混ぜながら、全体として共有されるべきイメージが描き出せればいいはずです。Webサイトのイメージチャンプルーですね。これは、あくまでもテストのアンチョコであって、けっしてそれ自体がテストされるようなものであってはなりません。
そして、イメージチャンプルーで明らかにされたことをうまく画面表現に変換できるかどうかを探るためにラフスケッチを描き、発見された画面表現の一貫性を確認するためにワイヤーフレームを描き、ワイヤーフレームに基づいた最終的な視覚表現の良し悪しを評価するためにモックアップを作成し、インタラクションのユーザビリティをチェックするためにプロトタイピングするわけです。
だから、web creators 2009年1月号の特集ページで「Web サイト制作をラフスケッチから始める」とか、「ラフスケッチでイメージを共有する」とかいう見出しが掲げられているのを見ると、正直、ちょっと違和感を覚えてしまいます。
もちろんチャンプルーの一部として、ラフスケッチを使うことが有効なケースはありえます。たとえば、レイアウトやインターフェースデザインの独自性を狙う場合など。しかし、ラフスケッチをWebサイトのイメージを共有するためのキラーメソッドだとしてしまうのには無理があります。
実は、ぼくの職場は元々編集プロダクションだったこともあって、ある時期までまさにラフスケッチドリブンな制作を行っていました。そしてその結果、以上の認識にいたるような失敗を繰り返してきたのです。いや、今でも、ラフスケッチをワイヤーフレームと言い換えただけで（これ自体間違いなんですが）、同じ失敗を繰り返してしまうことがあるくらいです。
ユーザーテストを軽視してきてしまったのも、「編集部員」がラフスケッチ＝ワイヤーフレームを描いて「編集長」や「デスク」にレビューを乞うというプロセスが、不十分なかたちでユーザーテストを先取りしてしまっていたからではないか、などと疑っています。
なんていう自戒をこめつつ、Web サイトのイメージを共有するならチャンプルーでいこう、だから Web ディレクターたるものいろんな作図法に明るくなくちゃね、と、少なくとも自分の周りには強く主張したい次第です。
-----------------
sent from W-ZERO3
登録:
投稿 (Atom)