# 379

クライアントとの関係とマルチデバイスWebサイト

クライアントとミーティングに入る時、クライアントにとってあなたはまるで未来からの訪問者だ。あなたはWebのプロとして、マルチデバイスWebサイトのパラダイムの中にどっぷり浸かった日々を過ごしている。しかし、そんなあなたにとってすら、インターネットを仕事にしていることから来る絶え間ない変化と修正には、参ってしまうことがある。ましてや、あなたのクライアントにとってはなおさらだ。

Webとは、流動的であり変化の連続だ。Web(とクライアント)に対応する私達のプロセスはその点を反映させる必要がある。(閉鎖的コミュニケーションと驚きの「大発表」に満ちた)広告の世界から引き継いだ古い考えを捨てて、誠実で包括的、そして真のコミュニケーションに基づいた新しいシステムを構築する時だ。クライアントにプロセスの過程で直面する欠点やトラブルをすべて見せることによって、私達はクライアントをこのプロセスの中にすぐに引き込むことができる。クライアントはこの関係を通じて、混乱して不安な気持ちの傍観者ではなく、私達の本当のパートナーとなるのだ。私達とクライアントが一緒に、この奇妙で進化を続けるデジタルの世界をいかに上手く渡っていくかを学んでいく中で。

視点がすべて

あなたのクライアントがまずWebサイトを考える時、デスクトップコンピューター上のWebブラウザの中のWebサイトが頭に浮かぶだろう。これはまったくもって無理もないことだ。結局のところ、彼らのWebサイト経験の大半は、机の前に座ってその上のものをいじっている時なのだから。

しかしながら、私達の視点からは、Webとはより多くのデバイスから構成されているものと見る。最近までは、これらのデバイスは、「スマートフォン」や「タブレット」「ノートパソコン」といった種類に分けられると考えるのが便利だった。しかしながら、市場に次から次へと多様なデバイスが登場する中で、この種類は増え続け、その種類分けには収まらないものも出てきて、やがては、ディスプレイサイズや解像度、ブラウザやOS、規約、インターフェイスの可能性、といった、明確な境界線を引き難い一続きなものへと道を譲ることになった。

この変化は、私達の考え方の見直しを求めるものだ。細部まで正確に各スクリーンに再現された一連の完璧な構築物であるWebサイトという考え方から離れ、Webデザイナーはシステムという観点から考え始めた。適応自在であることの方が、ある環境へ特化していることよりも、より重要になったのだ。

もしあなたのクライアントが以前、伝統的なデザインプロジェクトに携わったことがあったなら、クライアントはあたなとのミーティングでこの問題を想定していないだろう。では、私達はどうやってこのギャップを埋めたらいいだろう。どうやってクライアントに、私達の魔法のデザイン眼鏡を通じてインターネットの世界を見る手助けができるだろうか?一体全体、この問題をどうやって説明したらいいんだろう?

このインターネットの世界をどうやって説明しよう?

初心者を順応させるには大きく3つの要素があるが、私はそれを3つの「S」と考える – Statistics(統計)、Stories(ストーリー)、Specifics(具体性)だ。

事態の緊急性をすぐに伝えることができるという点で、統計はすばらしい。例えば、クライアントとモバイル市場の重要性について話す時、私はしばしば次の統計を引き合いに出す。

18〜29才のスマートフォン所有者の42%が、インターネットにアクセスする際のメインのデバイスはスマートフォンだと答えています。(Pew Internetより)

クライアント:何だって?42%?なんてことだ!携帯がそんなに重要だなんて全く知らなかった!じゃあ、どうしようか?

これが統計の力だ。統計は、多くの文脈を伝えてくれる訳ではないし、問題を全体的に理解するのを助けてくれる訳でもないが、人々の気を引くのに役立つし、ニーズを教えてくれる。衝撃的な統計は、上記のような会話を始めるにはぴったりの方法だ。

一方で、統計は確かに要点を伝えたい時に役立つが、しかし人間は社会的で感情的な生き物でもある。アイディアをずっと覚えていてもらうためには、論点をもっと実感できるよう、その論点をより強調するような個人的なストーリーに訴えかけるのが有効な手法だ。例えば、こんな。

私には3歳になる息子がいます。ご存知かどうか分かりませんが、3歳の子供っていうのは、放っておくと、驚くほどいろんな方法で怪我をする天才なんです。つまり、私が家にいてインターネットで何か調べ物をしないといけない時は、さっさと屋根裏に行って自分のデスクトップコンピューターの前に座る訳にはいかないんです。でも、便利なことに、私のポケットの中には別のコンピューター(自分のiPhoneのことだ)が入っています。私は今、自宅のソファーに座っています。私は典型的な「モバイルユーザー」ではありませんが、まさに典型的モバイル・デバイスを使っていて、それにはデスクトップと比べても遜色のないユーザーエクスペリエンスと情報アクセスを期待しています。自宅にいる時は、私のスマホが私のコンピューターなのです。

どういう風に効いてるのか分かっただろうか?まず私の統計は、説明を補強する。私のストーリーには、個性と状況設定、(簡単ではあるが)あら筋がある。こちらの方が、説得力のある統計が載ったパワーポイントよりも魅力的だし、今や私のストーリーも私のクライアントのインターネット観の一部となっていることだろう。彼らが「モバイルユーザー」について考え始める時、願わくは、旧知の友である「食料品店で行列に並ぶ男」や「バス停留所で待つ女」と共に、ソファーに座ってiPhoneに夢中になっているマット・グリフィン(私のことだ)とその周りをパジャマでグルグル回る子供の姿が浮かびますように。パラダイムがシフトしたのだ!

説明するのではなく、見せてみよう

「でもちょっと待って」とあなたは言うだろう。「3つ目のSがあったじゃない!」

素晴らしい、あなたは注意深い読者で、最初のテストは合格だ。では、specifics(具体性)について話そう。具体的に一体どの具体性かって?聞かれるのを待ってたよ!

もしあなたがiPhoneで、小さくてマルチコラムのサイトに慣れていて、ピンチ&ズームがしょっちゅうだとしたら、最初にレスポンシブWebサイトを見た時、みんなどこに行っちゃったんだろう?と思うかもしれない。ナビゲーションはどこ?サイドバーは?みんなどこに行ったんだ?

有意義な実習としては、私がプレゼンに使うプロジェクターもしくはテレビの中でレスポンシブWebサイトをリサイズして見せる一方で、私のスマホでも同じサイトを表示して部屋中に回覧することだ。クライアントは、メインのナビゲーションが、ハンバーガーアイコンの中にしまわれるのを見ることができる。サイドバーは、メインコンテンツの下に移動している。

携帯端末上にも再現しつつ、大きなスクリーン上にてこのインタラクションを見ることは、みながモバイルでの経験とデスクトップでの経験を結びつけて理解するのに役立つ。コンテンツが全く違うのではない。新しいコンテキストの中に置かれただけなのだ。

最初のミーティングでこのようなサイトをいくつか(特に、スターバックスParavelマイクロソフト・ホームページのような有名ブランド)デモンストレーションをすることは、レスポンシブデザインがスタンダード化してきており、あなたのクライアントのサイトにもユーザーがレスポンシブデザインを同様に期待しているであろうことをアピールするのに役に立つ。結局のところ、もし世界で最も確立された消費者ブランドが既に導入しているのだとしたら、あなたのクライアントもずっと安心な気分になれるだろう。

成果物の提出

クライアントがレスポンシブのルールにより詳しくなるのを手伝えば、クライアントはあなたのデザインへより良いフィードバックを返すのに必要なコンテキストを手入れることができる。しかしまずは、クライアントがチェックするのはどの成果物かを伝え、それぞれについてどんなフィードバックが有益であるかを理解してもらわなければならない。

レスポンシブデザインに関しては、細分化され、より的が絞られた成果物を、クライアントと頻繁に確認していった方が、より効果的に作業が進められることが分かった。

文書化しておこう

私達のプロジェクトすべては、短くスペックを記述した文書を作ることから始まる。そのスペックには、プロジェクトの目標や、主要点、サイトの情報アーキテクチャ、サイトマップ、ブランドのプロフィールなどが含まれる。ピッツバーグにあるアンディ・ウォーホル美術館と弊社Beardedが取り組んだ最近のプロジェクトでは、Basecampの中で、プロジェクトに関わった人誰でも編集可能(バージョンコントロールされている)なテキストファイルに全てを保存した。これにより、混乱させるような古いバージョンのファイルが行き交うことなく、迅速な更新が可能となった。バージョンコントロールはまた、後に過去の判断に疑問が生じた時に備えて、判断の変遷の記録をしっかりと残してもくれる。

スペックを記述した文書は、プロジェクトの目標や戦略をはっきりと書き出したものだ。これは、勝利のリストであり、ゲーム・プランでもある。※1

この文書を初期のバージョンからクライアントに渡しておくのは、非常に重要なことだ。すべての関係者がこの文書の重要性を充分認識し、あなたが更にプロジェクトを進めてしまう前に、それに目を通して意見や懸念点を表明するよう、念を押すべきだ。例えば、以下のようなメッセージで。

スペック文書の記述に参加することは、あなたのアイディアが最終的なプロダクトに反映されることを意味しています。後で議論に参加し意見を述べたいと思っている人はみな、必ずこの文書に目を通して下さい。意見がある人にはぜひ伝えておいて下さい:もしこのプロジェクトがあなたにとって重要なら、今度の金曜日までにあなたのフィードバックを返して下さい !

しばしば、これらの提案された編集は、このプロジェクトで何を達成するのが重要かについて新しい議論を引き起こす。もし、サイトの主要点への誰かのアイディアやアプローチが見当違いに感じたら、なぜそれが重要だと思うのか彼らに聞くべきだ。どうそれがプロジェクトの目標に関わるのか?もし関係しないなら、あなたは目標を見直す必要があるのか?もしくはこの関係者に、もう一度全体像を思い起こしてもらう必要があるのか?

これらの重要事項が定まったなら(そしてチームの全員が編集を終えたなら)、ビジュアルに取り掛かる準備完了だ。

あなたのワイヤーを組み立てよう

レスポンシブデザイン用にページレイアウトを正確且つ効果的に決めるには、ブラウザの中でこそやるべきだ。ウォーホル美術館のために、私達はこのレスポンシブ・ワイヤーフレームを作成した。これは、私達のフロントエンド・スターターキットであるStubbleを使って、約2時間半で出来上がった。決してきれいとは言い難いが、そこが肝心なところだ。誰もこれをWebサイトのデザイン案とは間違えない。しかし皆、これが情報階層とレイアウトを決定するための最初のステップだと分かるだろう。

私達がクライアントにワイヤーフレームを見せる時、クライアントにはコンテンツに関係したフィードバックを求める。

何か重要なものをごっそり抜け落ちてはいないですよね?ここにあるものの中で、相対的な重要度の順番はどうですか?このページに必要な情報は大体これでよさそうですか?

この段階では、デザインにとりかかる前に、ページに必要なすべての要素が揃っているか確認しようとしている。しかし、未だにページコンテンツに取り組んでいるからといって、デザイン面について考え始められない訳ではない。

ロー・ファイ(低再現性)がベスト・ファイな時

ワイヤーフレームはワイヤーフレームとして使われれば素晴らしいが、見てくれや雰囲気を伝える役には立たない。スタイル・プロトタイプと旧来のページ・モックアップの中間にあるものとして、ロー・ファイ・モックアップはWebデザインの実用主義に即したもので、効果的に全体的なトーンを伝えてくる。私達は、ウォーホル美術館用のワイヤーフレームと対になるものとして、このロー・ファイで静的なモックアップを短時間で作成した。

これらのロー・ファイ・モックアップについて、私はクライアントに今の段階では細かい点は無視して、もっと大きな全体的なことについてのフィードバックをくれるように頼む。

私達は皆、これがまだWebサイトではないことを知っています。しかし、これは正しい方向に向かっていますか?まったくの方向違いだとしたら、それはなぜでしょう?カジュアル過ぎますか?プロっぽくなり過ぎですか?ブランドのイメージに合わないですか?もし「大体いい感じ」なら素晴らしい。了承いただけたとの認識で、その方向に向かって更に作業を進めていきます。

フィードバックはループさせよう

あなたのクライアントからのフィードバックのキメの細かさは、彼らがチェックしている成果物のディテールの度合いにマッチしていないといけない。ロー・ファイのビジュアルには、ロー・ファイのフィードバックと承認が返ってくる。一般的な反応を見てみよう。

クライアント:うーん。このモックアップは、私が思っていたより少し面白みに欠ける感じだな。

私:スペック文書の中では、私達は洗練されてかつ遊び心もあるデザインにしたいと言っています。たぶん、遊び心に欠けていますか?真面目な感じを減らして、もう少し奇抜な感じにしてみますか?

クライアント:いいんじゃないかな。どうしようと思ってるんだい?

私:まだ具体的にははっきり言えませんが、この後で作っていくインタラクションでもっと楽しいものにできると思います。ちょっと試させてください。たぶん、全体の色味をもっと元気な感じに変更して、そのあとはブラウザの中でどうやったらもっと全体を生き生きしたものに出来るか試してみましょう。それでどうですか?

クライアント:いいね!そうしよう。

グループが「もうこれで充分だ」と同意するまで調整を続けるべきだが、ディテールの部分にはあまり凝らない方がいい。ここはディテールを検討する段階ではないからだ。頭の片隅が疼いて、「私達は重箱の隅をつついている」という声が聞こえたら、こう言う時だ。

しっかりした基礎が出来たと思います。この辺で、先へ進んでもよろしいですか?

先へ進むということは、もちろん、より多くのディテールが出てくるということだ。隠喩が少なくなり、代わりに現実感が増してくる。そう、あなたが予想したとおり、ここはHTML/CSSモックアップの番だ!

驚きの大発表よりも、会話を

ブラウザの中で見せるコンプは、セマンティックで且つ(私が以前、記事”Responsive Comping”の中で述べたように)再利用可能なHTMLとCSSを使った、正真正銘ハイ・ファイなインタラクティブ・モックアップのことであり、真剣勝負だ。ワイヤーフレームとロー・ファイのコンプを承認した後、私達のクライアントはウォーホル・プロジェクト用のこのモックアップを見たのだ。

これは、単にレスポンシブなだけではなく、先にロー・ファイで見たモックアップのデザインから大幅に進展したものだ。皆の合意が取れている静的モックアップとワイヤーフレームの構造を継承しつつ、ぐっと改良され、ディテールが加わり、洗練されている。しかもコード化されて。

この段階で、クライアントからのフィードバックは非常にマイナーなものになると予想される。なぜか?クライアントは、すべてのプロセスに参加してこの段階まで一緒に導いてきたからだ。クライアントは、どんな成果品が上がってくるか分かっており、あなたが見せたものに驚いたりはしなかった。これは「大発表」の正反対だ。不意の驚きはない。効果的なデザイン的解決策へ向かっての、しごく当然な進展の道のりだけだ。

覚えておこう:クライアントからの見直しのリクエスト一つ一つは、実際のところ、会話を求めるリクエストなのだ。変更に対する私のデフォルトの回答は「なぜですか?」だ。クライアントが「なぜ?」に集中するのを助け、「どうやって?」を見つけ出すのは私達の責任だとクライアントに思い出してもらおう。「なぜ?」に集中することで、枝葉末節かもしれない現象ではなく、根本的要因の方に取り組みやすくなる。

今こそ始められる

多少時間をかけても、私達のクライアントに私達が直面する困難を理解してもらい、彼らが私達のプロセスでどんな役割かを果たすのかを理解してもらえれば、彼らとコニュニケーションを取りやすくなるし、いっしょに働きやすくもなる。クライアントからの信頼も勝ち得ることができるし、親密な関係が強化され、今回のプロジェクトはもちろん、今後のプロジェクトにおいてもクライアントの全面的な協力を得やすくなる。

あなたの新しいクライアントは、このぐんにゃりと形の定まらないインターネットの世界を、まだあなたのようには知らないし愛してもいないかもしれない。しかし情熱というのは伝わるものだ。クライアントがインターネットの真の姿を見るのを手助けすれば(魔法のデザイン眼鏡ごしに見るかどうかはオプションで。)、あなたとクライアントとのインタラクションはその恩恵に預かることができるだろう。

備考
※1 スペック文章の記述について、更なる詳細は、私の記事「Don’t Go It Alone: Collaborative Web Design」参照のこと。