酔いどれデザイン日誌 - Drunken Design Diary -

都内でデザインファームを営む酔っ払いが、UI/UX論やデザイン思考論を書き殴ります。

都内でデザインファームを営む酔っ払いが、UI/UX論やデザイン思考論を書き殴ります。

OKボタンの配置は、左右どっち?UI設計のための情報アーキテクチャ

f:id:information_architecture:20140926003522j:plain

仕事でBootstrapを使って管理画面の設計およびデザインをする機会がありました。そこふと気になってみて調べてみたのですが、皆さんはOKボタンを左右どちらに置いていますか?

これについての興味深い研究結果がありました。2006年の調査と少々古いものではありますが、その本質は非常に情報アーキテクチャとしての的を得ています。概略を説明すると、Windowsは左にOK、右にキャンセルが標準のUI。Macintoshはその逆で左にキャンセル、右にOKであり、この調査ではそれぞれのOSのユーザーに対して、左右どちらのOKボタンの方が認識されやすかったか?というのを統計で明らかにしています。

私はどうも、Windows標準の「左側にOKボタンがある配置」が気持ち悪く感じます。別にマカーでも無いですし、むしろ生まれてこのかたずっとWindowsを使っているのにも関わらずです。

そこで調査結果を見てみたのですが、Macユーザーは当然のこと、Windowsユーザーでも右下にOKがあるのが最も認識されやすいという結果になっていました。

やや、これは意外な結果。Windows標準のUIによって刷りこみがしっかりされているのかと思いきや、そんなことも無いようです。とすれば、情報設計をする上で「一般的である」という事はそこまで重要ではないという事になるのではないだろうか。

目次

「一般性」に捉われすぎない

UI設計関連の書籍や記事などを読んでいると必ずといっていいほど「迷ったら一般的なものを使え」と記されているかと思います。これについては私も同意見ですし、下手に奇抜なUIを作っても誰も使えないものになるという結果は火を見るより明らかです。

しかし、私はここに警鐘を鳴らしたいと考えています。冒頭でなぜBootstrapを使った管理画面デザインの話をしたかというと、Bootstrap標準のアラートの出し方がどうも気持ち悪いと感じるからです。

 

f:id:information_architecture:20140926003502j:plain

 

こういうやつです。大体が画面の上のほう(ファーストビューエリア)にポンと出てくる、Bootstrapを使って構築された殆どの管理画面に採用されている、誰もが一度は見た事があるであろう「一般的なアラート」だと思います。

しかし、Windows標準のOKボタン位置の例を思い出してみてください。UIの情報アーキテクチャにおいて、一般的であることは必ずしも正ではないという事ができます。

たしかに、一般性を無視してもユーザビリティが低下する例の方が圧倒的に多いでしょう。でも気持ち悪いんです。どうもこのアラートの出かた、形、出る位置、全てがアラートの本来もつべき情報の意味を損ねている気がしてならないのです。

何をするカタチなのかより、何が起こるカタチなのか。

以前、駅から学ぶ情報アーキテクチャの記事でも書きましたが、WEBの基本フローは“線”です。決してその時点だけを見た“点”ではありません。

UI設計をしていて陥りがちなのは、そのUIで何をするのかを考えた形や配置に気を取られるあまり、それを操作する事で何が起こるか、前後のページとの関連性や、アクションの後に何が待ち受けているかをスムーズにイメージ出来ないUIになってしまうという、一般性に捉われた思考プロセス的な問題です。

具体的に例を挙げると、OKボタンとキャンセルボタンを安易に横並びにするなどです。例えばエントリーフォームなどを設計する場合、その時点だけで考えるのであればこれは全くもって問題ではありません。非常に一般的で正しいUIのカタチです。しかし、線で考えるとどうでしょう。例えば前のページに利用規約に同意するボタンがあった場合、その時点でキャンセルを選択しなかったユーザー=フォームに到達したユーザーは、離脱する気は無いと判断するのが妥当ではないでしょうか。

そう考えると、入力項目が多岐にわたるエントリーフォームのようなページで、一度入力した情報が無に帰す「キャンセル」の様なボタンは、利用するユーザーにとってストレスの素でしかなく、設けるとしてもOKボタンとは距離を離すべきであると判断するのが適切ではないでしょうか。

一般性にだけ捉われてよくあるカタチで作ってしまうと、OK/キャンセルという「何をするか」は容易に満たせるのですが、「何が起こるか」は満たすことが出来ないという事態が頻発するのではないだろうか。

特に、ノンデザイナーでもある程度決まったデザインでそれなりのUI設計っぽい事が出来るBootstrapはとても便利で汎用性がある分「何をするカタチ」なのかに特化していて、前後のページや前後のアクションまで踏まえた“線”で考えた際に、冒頭で書いたような気持ち悪さがあちこちで頻発し得るのだろうと危惧しています。

個人的に理想のアラート

前置きが長くなりました。ぶー垂れてないでさっさとお前の考えるイカしたUIってもんを示してみろよ?と言われそうなので、散々例に挙げてきたBootstrapのアラートのどこがイケてなくて、どうすればイケてるようになるのか説明していきます。

まずイケてない部分は以下の点です。実際は設計と構築次第という部分が大きいので、Bootstrapを使ったもの全てに当てはまるわけではありません。

  • submit系ボタンの位置とアラートの位置が離れすぎている
  • アラートが出っ放しになっている
  • 画面遷移を挟むとアラートが画面のどこに出たか認識できない

まず、位置に関して。ほとんどの管理画面がsubmitは下、アラートは上、という配置になっていませんか?あれがどうも苦手です。アクションを起こしたことに対してのレスポンスが、アラートの持つ本来の情報的意味であるとするならば、アクションボタンとレスポンスメッセージの位置が上下でこんなに離れているのは不自然ではないでしょうか?

そこで私は、アラートメッセージはsubmitに隣接させるべきであると提唱します。まずこれが第一の改善案となります。

 

f:id:information_architecture:20140926003647j:plain

 

次に、アラートが出っ放しになっているという点。これは何らかの制御を挟まないといけないので、ほとんどの管理画面で×ボタンを押すまでアラートは消えないような作りになっていると予測されます。

しかし、これもアラートが持つ情報的な意味に着目すると違和感を覚えます。アラートメッセージは直前の動作に対するレスポンスであるべきなので、それがスタティックにページの一部として居座り続けるのは不自然です。

この違和感を例えるならば、「冷やし中華始めました」というPOPが秋になって冷やし中華が終りかけた段階でも残り続けているような感覚です。

そこで私は、アラートは動的に、かつ目立たせて表示し、時間制御で消す事を提唱します。これにより、「まさに今」操作した事へのレスポンスは的確に返しつつ、次の動作へ余分な情報遺産を残さずに済みます。

 

f:id:information_architecture:20140926003703j:plain

 

最後に画面遷移を挟んだ場合にアラートの位置が瞬時に認識できないという問題ですが、これは上記二つの問題点が複合されて起こる現象なので、上記を改善すれば同時に改善されるものとなります。

つまりまとめると、アクションとアラートメッセージは近接させるべきであり、その表示は動的に制御すべきである。というのが、私が考える理想的なアラートの設計です。

まとめ

Bootstrapに始まるフレームワークの数々は、もはやWEB制作の世界においてかかせないものとなりつつあります。

これらは非常に便利であると同時に、注意して利用しないと情報設計が全く施されていないページが乱造され、ユーザビリティやUXを損ない、WEB全体の品質低下という結果にもつながりかねないという事を念頭において、上手に活用すべきだと思います。

特にシステム開発関係のノンデザイナー系の方々が利用される際は、UIの持つ形的な意味だけでなく、導線を意識して適切な情報設計を少しでも心がけて頂ければ、WEBの未来は明るいものになるでしょう。お願いなので全部のボタンとりあえず横並びに配置しましたとか、全部の要素とりあえずリストにしてテーブルにブチ込みましたとか、やめてください・・・。

「慣れ」による一般性は、たしかに一定のユーザビリティを生みます。しかし同時に、それ以上の可能性を失う事にもなります。生物は常に進化をしなければ絶滅すると言われています。WEBの世界はめまぐるしい勢いで進化し続けている世界なので、進化をやめたUIがどのような結末を迎えるかは、設計に携わる方々ならば説明しなくても容易に想像が出来るかと思います。

便利なもの程考えて使う。この意識を常に持つことで、WEBの世界はより便利に、より有意義に発展していくのではないでしょうか。皆さんも今一度、設計の重要性について考えてみては如何でしょうか。

『通る企画書』づくりの為の7つのデザインテクニック

以前の記事で「なんか案件降ってこないかなー」と書いてみたのを知って知らずか、WEBサービスの企画およびシステムの設計を裏表どっちもやるトンデモ案件が降ってきてしまってちょっと更新が止まってしまってました・・・。楽しいから良いのですが、フォトショを起動してる時間よりパワポを起動してる時間の方が圧倒的に長いので、そろそろ自分がWEBデザイナーである事を忘れつつあります・・・。しかし、そんなある日、システム部の方々と共同で企画書作りをしてふと気付いた事があります。ノンデザイナーの方々ってわざとやっているのかというくらい企画書の体裁や見た目には全く頓着しないのだという事です。文字サイズは全部一緒、改行位置も要素の配置もめちゃくちゃ・・・。これは勿体ない。とても勿体ないです。

いくら優れた企画力や専門知識を有していたとしても、それを相手に上手く伝えられなければこんなに勿体ない事はありません。今回はちょっと本職を思い出し、企画書づくりに使える7つのデザインテクニックをご紹介したいと思います。どうぞお付き合いください。

目次

「書けば伝わる」訳が無い

f:id:information_architecture:20140821075855j:plain

こういう企画書、作っていませんか?まさに冒頭でご紹介した「システム屋さんが作る企画書」の典型例です。今回は体裁やレイアウトなど、ビジュアルデザイン面でのテクニックにとどめようと思っているので内容の善し悪しには触れません。

これは本当によく勘違いされるのですが、「必要な事は全て書いたから読めば分かるだろう」と言う人が未だに居ます。読み手は企画書の内容の2割も読みません。これはWEBサイトにおけるユーザーに対する考え方と同じで、上から下まで舐めるように全部読む人なんて存在しないのです。なんならこの記事だって上から下まで一語一句洩らさず全部読む人は居ないでしょう。居るとしたら世界で私だけです。ここにうんことか書いておいても気付く人は居ないでしょう。

では、どうすれば伝わるのか?かんたんです。部分的に読んでも伝わるように工夫すればいいのです。例えばこの記事、基本的には「見出し」と「強調タグで囲った文言(太字)」だけ追えばざっくり内容が伝わるように作っています。残りは装飾品、繋ぎ、オマケにすぎないのです。

『通る企画書』づくりの為の7つのデザインテクニック

はいここから本題です。恐らくこの時点でもう殆どの人がここから読み始めるだろうというくらいの諦めた気持ちでいる事が肝心です。頭から順番に読むのを期待してはいけません。そんな人間は居ないのです。全部読んでる?ご愁傷様です。誠に残念ながら、どうやらあなたは人間ではなかったようですね・・・。

1.メリハリを付ける

じゃあ先程のイケてない企画書を、イカした企画書へと変身させていきます。まず気になる点と言えば、情報にメリハリが無いことですね。どこが重要なのか、見た目ですぐ分かるようにしてあげましょう。

f:id:information_architecture:20140821080113j:plain

こんな感じです。強調の意味合いは主に

  • 大きさ
  • 太さ

などで表現します。デザイン業界ではこのメリハリの事をジャンプ率と呼びます。課長にドヤ顔で説明する為に是非覚えておいてください。

2.グルーピングする

f:id:information_architecture:20140821080116j:plain

関連する情報や要素はまとめましょう。まとめ方は色々ありますが、

  • 枠で囲う(背景色を敷く)
  • 共通の色にする
  • その他の要素との距離を離す

などで表現します。カッコよく横文字を使うとグルーピングですが、要するにまとめましょうという事です。部長にドヤ顔で説明する為に是非覚えておいてください。

3.整列する

現状の企画書をよーく見てください。微妙に文章や図の頭とお尻がそろってないですね。ノンデザイナーの皆様が最も気にしないけど、我々が最も気にする部分がこれです。例えば、テキスト段組みの両端揃え・均等割り付けを使ってみたり、図の大きさを本文の横幅と揃えてみたりして、グルーピングした要素の塊が一つの箱に見えるようにする事で、視覚的にさらに認識がしやすくなります。

f:id:information_architecture:20140821080119j:plain

これをグリッドレイアウトと言います。久々に会った地元の友人にドヤ顔で説明する為にも覚えておいて損は無いです。

4.余白をつくる

本当に重要な項目であればあるほど要素の周りの余白を多くとり、視線を集中させる方が効果的に相手に伝わる企画書になります。ノンデザイナーは勿論、新人デザイナーでも「余白があるからまだ入れられる」をやってしまう事が多いですが、余白は余白それ自体に意味があります。埋めないでください。

f:id:information_architecture:20140821080122j:plain

この余白の事をマージンもしくはホワイトスペースと言います。最近よく聞くフラットデザインは、のっぺりとしたシンプルなデザインというよりも余白をゆったりと使う事で視線を集中させるデザインといった方が正しいと思っています。

5.視線の動きを理解する

人間の視線の動き方には、ある一定の規則性があります。代表的なものを挙げますと、

f:id:information_architecture:20140821080135j:plain

などです。あまり意識してないかもしれませんが、世界中の殆どの広告やWEBサイトはこの法則に則って要素が配置されています(例えば企業ロゴが常に左上である事など)。企画書を書く上では、左上にページタイトルや結論など、右下に次のページへの「引き」の要素を配置するなどで応用できます。

この2つの法則、凄く似てるけどどっちを意識すればいいの?という質問には、私であればZの法則を意識せよと答えます。何故ならば、企画書のフォーマットは常に一定サイズの紙・スライドが連続する形式であるためです。Fの法則はWEBサイトのように縦の長さが不定で、かつある程度長い読み物にしか適用できないと考えた方が、使い分けに困らないと思います。

f:id:information_architecture:20140821080124j:plain

Zの法則とFの法則。知っていればちょっとだけインテリぶれるので、是非覚えておいてください。

6.統一感をつくる

形や色に持たせる意味を企画書内で統一する事はとても大切なはずなのに、つい忘れがちな事の一つです。さっきのページでは赤はマイナスイメージのテーマカラーだったのに、このページでは成功例の強調部分で使われている。さっきは人間のクリップアートでユーザーを表していたのに、いつの間にか同じクリップアートがサービス管理者の説明に使われていた。などなど。

f:id:information_architecture:20140821080127j:plain

ルールの統一は、ビジュアルデザイン・UI設計・情報アーキテクチャ共通の基本理念です。これをやらないと読む人(ユーザー)に対して「意味の考察」という大きなストレスが発生してしまいます。この記事を読んだあなたは、そんな有象無象のビジネスマンから一歩リード出来ます。やったね!

7.リズムをつける

上記の事を全て実践して行っても、10枚20枚とページが増えるに従って読み手の読む気力はどんどん削がれて行きます。読み手(ユーザー)の基本行動は流し読みです。パラパラと企画書をめくって見られても大体どこに何があるか分かるように、しかもそのリズムに規則性を持たせるようにすることで、ちゃんと内容を読んでもらえる可能性がグーンと上がります。つるぎのまい くらいグーンです。

ちなみに当ブログで毎回かならず目次とまとめを挟んでいるのも、見出しでエリア分けを明確にしているのも、流し読みに対応するリズムを付ける為です。単純に並べただけだとお経と同じですからね。朝礼の校長の話で眠くなる原因はリズムが無いせいだと確信しています。

まとめ

ここでデザイナーの基本中の基本理念をおさらいします。常に相手(受け取り手)の事を考えてデザインをする。これは古今東西どのジャンルのデザイナーでも共通の理念であり、デザインとアートを明確に分かつ最大の要因でもあります。

では、あなたが企画書を受け取る側だとして、文字や図が無秩序に散らばったページを読みたいと思いますか?多分面倒臭くなって読み飛ばしてしまうと思います。しかし、ノンデザイナーの方々は重要な項目ほど文字や図をギチギチに詰めこむような傾向があるように感じます。実際、「書いてあるんだから読めば伝わるだろ」のような方は、システム屋さんだけではなくて、営業でも広報でも、どこでもいらっしゃいます。私も長文癖があるので人の事はあまり言えませんが、文字が多いならせめて読みやすくしてあげる工夫はしてあげるべきだと思います。

相手の気持ちになってデザインをする。デザインだけじゃないですね、もう人として当然のことです。この記事を読破した皆様であれば、明日からは更に素晴らしい企画書が書けるものと期待しております!頑張ってくださいね!!!(人の書いた企画書の体裁を整えるのに疲れた顔)

■ ノンデザイナーの方々に特にオススメの本。

 

はてなブログでカスタムURLを設定する際に注意すべき3つのポイント

f:id:information_architecture:20140701115803j:plain

どうも。こちらの記事を読んでお恥ずかしながら、はてなブログにカスタムURL機能があることを初めて知った情弱です。こんにちは。

情強の皆様方ならば既にご存知&ご活用していらっしゃるであろう、このはてなブログの標準機能カスタムURL機能について、設定の際にちょっと気になった部分と注意した部分をまとめてみましたので、ご参考程度にご覧下さい。

カスタムURLを設定する際に注意すべき3つのポイント+追記

  • 1.人が見てもロボットが見ても分かりやすい文字列で
  • 2.単語と単語の繋ぎは「-(ハイフン)」で
  • 3.すでにアップした記事に設定するのは高リスク
  • α.もし後からカスタムURLを設定して、はてブとスターが消えてしまったら

1.人が見てもロボットが見ても分かりやすい文字列で

カスタムURLはその名の通り、自分の好きな文字列でURLを定義する事の出来る機能です。これを設定する際に気をつけることは、誰が見ても意味が通る文字列で設定することです。

誰がというのには、Google先生のクロールロボットも含まれています。要するに、記事の内容と齟齬がないように・無駄なワードが極力含まれないように設定すればOKのようです。

2.単語と単語の繋ぎは「-(ハイフン)」で

さて設定しようか。となった時、ふと頭に疑問が浮かびました。単語の繋ぎ方ってどうすればいいの?結論としては、冒頭でご紹介したブログでも示されたとおり、「-(ハイフン)」を使うことがGoogle大先生では推奨されているそうです。

「_(アンダーバー)」との明確な違いは、「_」で繋いだ単語はセットで1単語として扱われ、「-」で繋いだ単語はそれぞれ別々の単語として扱われるようになるそうです。

3.すでにアップした記事に設定するのは高リスク

わざわざこんな雑記の記事を書いた理由がここにあります。はてなブログで過去にアップした記事のカスタムURLを後から変更すると、変更前に取得したはてブ(コメント含む)とスターが反映されないという現象が発生しました。(紐付きURLが変わるため)

当ブログのような零細ブログではさして影響は無いものの、一度頂いたブックマークやコメントが消えてしまうというのは、評価をして下さった読者の方に対して非常に申し訳ないと感じております。(頂いたコメントは全て読ませて頂いておりますので、今回の施策で消えてしまった分もすでに目を通しております。ありがとうございます。)

皆さんがカスタムURLを活用する際は、記事の初回アップ段階から設定しておく事を強くおすすめします。

α.もし後からカスタムURLを設定して、はてブとスターが消えてしまったら

(追記)どうやら同じようにカスタムURLの後設定ではてブ(コメント)やスターが消失してしまう方が多いようですので、中項目に格上げしました。カスタムURL設定で一度紐付きが解除された記事は、再度元のURLに手動で戻してあげればはてブおよびスターが復活します。緊急用ですが備忘録として。

まとめ

カスタムURLはSEO上も有利に働く便利な機能ではありますが、使いどころに気をつけなければ取り返しの付かない事になるなと痛感した一日でした。(まだ昼)

駅から学ぶWEBサイトの導線設計と情報アーキテクチャ

目次

WEBサイトは点ではなく、線で考える。

私はWEBサイトやWEBサービスの画面設計を考える時、常に点ではなく、線で考えるようにしています。導“線”設計というくらいなので線で考えるのが当然だろうという声が聞こえそうですが、UI・ナビゲーション等のビジュアルデザインやその上流工程である画面設計をしていると割と陥りがちなのが点で使いやすさを仮定してしまう事です。

要するにそのページ内で使いやすいであろう形を仮定してデザインしてしまうことで、WEBサイト・WEBサービス全体で見た時に調和が乱れていたり、配置の持つ意味が微妙にブレていたりするという事が有り得るという事です。気を付けていても割とよく陥りがちな部分なので、UI・ナビゲーションを含めた全体の導線設計をする際には十分注意したいところです。

駅から学ぶ導線設計

そこで本題ですが、そういったユーザーインターフェースを含めた導線全体の設計として情報アーキテクチャの考え方が使われているものが身近なところにもあります。私がここで参考例として挙げたいのは、電車の駅・ホームです。

情報アーキテクチャはWEBに限った技術ではありません。むしろWEBが世界に広がるずっと前から実践されてきました。電車の駅を利用するユーザーというのは、その特性がWEBサイトやWEB サービスを利用するユーザーと似ていると思います。例えば、駅の利用者は「目的地に向かう電車に乗りたい」という明確な目的は持ちながら、どういう経路で歩いて行けばそこにたどり着くのかというのは予め決めてはおらず、歩きながら考えているという部分であったり、常に歩きながら移動しているため、一つの情報に触れる時間が数秒~1分未満と非常に短い点などです。

そこで駅のユーザー(乗客)を誘導するための導線として用意されているのが、案内看板です。特に、乗り換え案内看板は先述の「点ではなく線で導線を考える事」に最も特化したツールであると私は考えています。

f:id:information_architecture:20140623075808j:plain

たとえば、これは東京駅の駅案内板ですが、改札を入って最初に目にする案内板に示されているのは、なになに線というざっくりとした路線の分類だけです。これだけでは詳細な行先が良く分かりませんが、目的の駅がどの路線に属しているのか分かっていればその路線を目指して進んでいくことが可能になります。次に目に留まるのは、乗降ホームへの階段に設置された案内板です。先程の路線案内板に示された番号に追加情報として、今度は停車する主要な駅名が書かれています。乗客は目的の駅が上下線どちらの方面に存在しているのかをここで初めて認知します。そして最後は次の電車が何時何分に到着するかを示す発車時刻案内板です。

こういった具合で、駅のホームというのは入口から全ての情報を羅列せず、乗客の導線とフローに合わせて適切な情報を出し分ける事によって、煩雑な情報を整理し、ファインダビリティを向上しているのです。

細かい部分で言うと駅の利用者は改札に入った時点で、まず離脱する事は無いので、WEBのユーザーと少々性質が違うのですが、目的の場所に辿り着ける為の情報を適切に提示し、いち早くユーザーを誘導するという目的を達成するためには、WEBと同様に情報アーキテクチャの考え方が必要不可欠となるのです。

まとめ

今回は電車の駅を例に挙げましたが、その他にも家電量販店や図書館など、ユーザーの導線設計に情報アーキテクチャの考え方を生かしている施設は色々あります。使いやすいWEBからUI/UXや画面設計を学ぶのも大事だと思いますが、たまには街を歩きながら、ちょっといつもと違った視点で物事を観察してみる事も大事なのではないでしょうか。

全ての物には意味があります。常に「なんでこうなっているんだろう?」と考えながら歩いてみると、世界がちょっとだけ面白く見えるのでオススメですよ。

※駅案内板の参考画像はここからお借りしました。

その初期サイト設計は尖っているか!フルボッコ分析のススメ

f:id:information_architecture:20140609080255j:plain

「ワイヤーフレームを作る」と一言でまとめている作業、ただなんとなくやっていませんか?「ファーストビューが~」「Fの法則が~」そんな小手先のテクニックどうでもいいんですよ。それは手段であって目的ではありません。目的はあくまで誰に対して何を伝えるかであり、その目的の為にあらゆる手段を用いて情報を最適化する(ファインダビリティを向上させる)のが、情報設計者(インフォメーションアーキテクト)の仕事なのだと思っています。つまり、「誰に」や「何を」をという目的をすっ飛ばして「どうやって」という手段を軸にワイヤーフレーム作成に着手するのは全くナンセンスなのです。それではワイヤーフレームごっこであり、本当の意味でのサイト設計には成り得ません。

当ブログを始めた時に「実案件で活かせるIAテクニック」をうたっておいて少々概念的な話が多めになってしまったので、ここらで実際に私がサイト設計をする時に課題点調査からワイヤーフレームを起こすまでにやっている初期設計フローをざっくり書き連ねて見たいと思います。あくまで私がやっている事なので、世の中のインフォメーションアーキテクト達が一般的にやっている事かどうかは分からないという旨を予めおことわりしておきます。

目次

あなたはWEBのプロフェッショナルです

私達WEBデザイナーやWEBディレクターがサイト設計をするのはどんな時でしょう。自社コンテンツの設計でも無い限り、基本的にはクライアントからの要望書ないし指示書ありきで事を進めるのが一般的ではないでしょうか。

ここで頻繁に見かけるのは、こんな状況です。

  • デザイナー「何この指示書、めちゃくちゃじゃねーか。」
  • ディレクター「でもお客様がこうしてと言っているんだから(納期もあるし)、仕方ないよ。言われた通り作って。」

受注仕事をしている限り、お客様が丹精込めて作って下さった指示書ないしワイヤーフレームをないがしろにする事は出来ないというのが今のWEB業界の悪しき慣例です。本当はおかしいと思っていてもそれは相手に届かず、相手の心象も考えて、下手に口出しをするよりも良好な関係性を維持する事に全力が注がれます。結果として、お客様はあなたの事を舐めますし、あなたもお客様の言いなりという身分から脱出できなくなります。

声を大にして言いたいです。なーにが「仕方ない」だアホかと。

確かに、要望そのものはクライアント側の経営判断に基づいて作られている為、我々が口出しを出来る範疇ではありません。しかし、その表現方法であるサイト設計についてはどうでしょう。クライアントの担当者に果たしてサイト設計の能力があるでしょうか?よほど勉強熱心な担当者でも無い限り、どう足掻いても毎日毎日終電までWEB制作をしているような人間に敵うわけが無いと思いませんか?

指示書を作っている担当者はあなたよりもWEB知識やサイト設計スキルの劣る素人です。そう胸を張って言えないようであれば、WEB業界なんかで働くのは諦めた方が良いのではないでしょうか?「仕方ない」という言葉に甘えて腑抜けないでください。

「自分言葉」でフルボッコにしろ

では、私がそういう素人考えの指示書や要望書が来た時に何をやっているかというと、まず自分の視点で現状のサイト設計の問題点をボッコボコにします

最初からワイヤーフレームを引く人も居ますが、私はまずWordやメモ帳などで現状サイトやコンテンツの問題点を箇条書きにしてフルボッコにします。褒め言葉は要りません。全身全霊を込めてフルボッコにして差し上げます。私はこれをフルボッコ分析と呼んでいます。ここで自分の視点とか言ってると「客観視点で見ないのか!」とかお説教を受けそうですが、主観/客観はコンテンツを提供する/されるの関係性であるため、受託仕事である限り普通に内容を見たり、普通にサービスを利用してみれば、普通に客観視点を得られます。何も特別なスキルは要らないのです。

これをやる事で、まず自分の中での案件に対しての軸が固まります。軸が固まれば、解決策も次々に浮かんできます。あとはそれを鮮度が落ちないうちに吐きだして、キレイにパワポなどで清書してからお客様にお送りすれば、ほら立派なサイト設計改善提案書の完成です。

フルボッコ分析で最も大切なのは、相手に見せる為の資料ではないので徹底的に自分言葉で書き殴る事です。本当はもっとズバズバ言ってやりたいのに、大切なお客様だから遠慮してしまって表現を丸めた結果生ぬるい提案書になってしまった・・・。そんな経験、ありませんか?

以前の記事でも持論を述べましたが、お客様が外部の人間に求めるのは同調やお世辞などではなく、鋭く的確な指摘なのだと思います。自分の想いを最も効率よくアウトプット出来るのは、美しい敬語などでは絶対にありません。だからこそ、自分の中で情報を整理する段階では自分言葉で書くという事がとても重要なのだと考えて、サイト設計前には必ずこのフローを行うようにしています。

パワポなんか後でいい。軸が決まればスピード命

サイト設計に必要な問題点・課題点の洗い出しが終ったら、あとはそれを形にするだけです。(案件規模によっては更に詳細なマーケティングや分析フローが入りますが、それはまた別の機会に。)ここからは自分の中に固まった軸を、なるべく鮮度が落ちないうちにアウトプットする事に全力を費やします。提案の軸が固まったから続きは明日でいいやーとか抜かすディレクターが居たら頭ひっぱたいてやってください。鉄は熱いうちに打つもんです。考えるだけで形に出来ないようでは、二流三流なのです。

スピード感のあるアウトプット手段として、私はいつも「メモ帳」を使っています。どうせあとでパワポでまとめるんだから、最初からパワポで作れば良いじゃないかと思いますか?あなたはメモ帳を舐めています。

メモ帳の良さは、その“不自由さ”にあります。windows標準のメモ帳は、なんとCtrl+Zの戻る機能で一段階しか戻れません。これにより、意識せずとも手戻りが少なくなり、どんどん書き進めるという動きが自然と身体に染み付きます。さらに、資料としてのレイアウトや体裁を全く気にしなくて良いので、純粋に頭の中身を言葉として起こすことが出来るようになります。パワポで綺麗にまとめるのなんか最後でいいのです。初期サイト設計段階では、まずメモ帳を使いましょう!

サイト設計の初期段階はスピードが命。でないと、どんどん軸がブレてきて何がしたかったのか分からなくなってきます。可能な限り、頭に浮かんだ情報はその場でアウトプットする事が大切です。ここでさらに私がオススメするのは一人で考えない事。あなたがフリーランスでも無い限り、同じ部署内に優秀な人材がゴロゴロ居るでしょう?その人達を引っ捕まえてきてさっき殴り書いたフルボッコ分析資料と今書いたラフサイト設計案を叩き台(議論の元となるプロトタイプ)にして会話をして下さい。「あーじゃないか?いやこーかもしれない・・・」なんて一人でやっていたのが馬鹿らしく思える程すぐに話がまとまる事をお約束いたします。

まとめ

  • 客はあなたに指摘されたがっている
  • フルボッコにする事で問題解決の「軸」が見えてくる
  • 最速でアウトプットする。オススメは「メモ帳」

情報アーキテクチャは、誰に・何を・どう伝えるかを設計する一連のプロセスです。今回ご紹介したフローは、「誰に・何を」を一気に決めてしまおうという少々乱暴なやり方ではありますが、これがスっと出てくるとその後の「どうやって」を考える大事な部分が格段にスムーズに進みます。自分言葉で課題点を洗い出し、軸がブレないうちに一気にプロトタイプを作る。フルボッコ分析なんてふざけた名前を付けましたが、イケてないと感じるサイトが「何故、ダメなのか。」を一つ一つしっかり紐解いていくのは情報設計(サイト設計)のとても良いトレーニングになります。自分言葉での分析は早くて純度が高い分、視点が俯瞰的ではなくなってしまうというリスクがありますが、そこは一人で考えない事で補いましょう。

IAはソロプレイヤーではありません。情報アーキテクチャはWEB制作において最上流工程に位置するため、周りを巻き込んで社内外問わずプロジェクト全体の意識を統一する重要な仕事だと思っています。だって、各々が想定しているターゲットがふわっとしていたら、コンテンツもふわっとするじゃないですか?そんなふわふわしたモノは作りたくないですよね。だったら井戸端会議でいいので、意見をぶつけあってすり合わせた方が早いし確実。フルボッコ分析からの井戸端会議、是非一度やってみてください!意外とエキサイティングでスッキリしますよ。