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

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

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

目次

• 「書けば伝わる」訳が無い
• 『通る企画書』づくりの為の7つのデザインテクニック
• まとめ

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

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

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

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

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

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

• 1.メリハリを付ける
• 2.グルーピングする
• 3.整列する
• 4.余白をつくる
• 5.視線の動きを理解する
• 6.統一感をつくる
• 7.リズムをつける

1.メリハリを付ける

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

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

• 大きさ
• 太さ
• 色

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

2.グルーピングする

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

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

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

3.整列する

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

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

4.余白をつくる

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

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

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

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

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

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

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

6.統一感をつくる

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

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

7.リズムをつける

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

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

まとめ

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

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

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

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

ノンデザイナーズ・デザインブック　［フルカラー新装増補版］

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

どうも。こちらの記事を読んでお恥ずかしながら、はてなブログにカスタム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サイトやWEBサービスの画面設計を考える時、常に点ではなく、線で考えるようにしています。導“線”設計というくらいなので線で考えるのが当然だろうという声が聞こえそうですが、UI・ナビゲーション等のビジュアルデザインやその上流工程である画面設計をしていると割と陥りがちなのが点で使いやすさを仮定してしまう事です。

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

駅から学ぶ導線設計

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

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

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

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

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

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

まとめ

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

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

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

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

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

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

目次

• あなたはWEBのプロフェッショナルです
• 「自分言葉」でフルボッコにしろ
• パワポなんか後でいい。軸が決まればスピード命

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

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

ニコニコプレーヤーの失敗から学ぶ「UXの為のUI」の問題点とは

目次

• ただ使いやすいだけのUIは要らない
• ニコニコプレーヤーの失敗から学ぶ「UXの為のUI」の問題点とは
• 本当の意味でのユーザビリティとは

ただ使いやすいだけのUIは要らない

UI（ユーザーインターフェース）の設計をしていると、よくよくユーザビリティという言葉を耳にします。
UIやUXについて真剣に考えているあなたならご存知でしょうヤコブ・ニールセン博士によると、ユーザビリティとは

1. 学習しやすさ: システムは、ユーザがそれを使ってすぐ作業を始められるよう、簡単に学習できるようにしなければならない。
2. 効率性: システムは、一度ユーザがそれについて学習すれば、後は高い生産性を上げられるよう、効率的な使用を可能にすべきである。
3. 記憶しやすさ: システムは、不定期利用のユーザがしばらく使わなくても、再び使うときに覚え直さないで使えるよう、覚えやすくしなければならない。
4. エラー: システムはエラー発生率を低くし、ユーザがシステム使用中にエラーを起こしにくく、もしエラーが発生しても簡単に回復できるようにしなければならない。また、致命的なエラーが起こってはいけない
5. 主観的満足度: システムは、ユーザが個人的に満足できるよう、また好きになるよう楽しく利用できるようにしなければならない。

(出典：wikipedia)

といったような定義がされています。この中で特に学習しやすさと記憶しやすさに関連する用語としてアフォーダンスという言葉があります。

これは認知心理学に関係する言葉で、「モノの形や色自体が自らの操作方法を人間に伝えている」という考え方の事です。これをUI設計に応用する事でなんか凄く良いものが出来る気がしませんか？

実際、UIデザインの中ではこういった考え方がとても大事なのは事実ですし、UIデザインの本などを読むとそれっぽい説明文がズラズラ書いてあります。

ただ、ちょっと待ってください。アフォーダンスを軸に据えればユーザビリティが向上すると考えてUIを設計してしまうのは危険です。下の図は、J.J.ギャレット氏によるUXデザインの5階層図です。下が基礎部分で上に行くに従って下流工程という事になりますが、アフォーダンスはこのプロセスにおいてインターフェースデザインとビジュアルデザインの中間部分に位置し、最後の仕上げに意識するスパイス的な要素である為です。アフォーダンスの考え方を設計の土台に据えるのは間違っているのです。

ニールセン博士が提唱したユーザビリティでは、使いやすさの定義は「学習」から始まっています。つまり究極に使いやすいUIとは、操作方法を学習する必要のないUIであると言えます。そして、これを実現する為には、アフォーダンスの考え方が必要不可欠です。

しかし、使いやすさを極めていった結果、ユーザーから不評が相次ぐという不思議なケースをご存知でしょうか。

それは、『ニコニコ動画』の動画プレーヤー「ニコニコプレーヤー」の例です。

ニコニコプレーヤーの失敗から学ぶ「UXの為のUI」の問題点とは

予め断っておくと、この場でニコニコ動画のサービスや設計思想の善し悪しについて議論するつもりはありません。UIとUXの相関性を考察するのに非常に適しているユーザーの反応事例があったので、例として挙げただけです。

ニコニコプレーヤーの変遷について詳しく知らない方の為にざっくりと説明すると、YoutubeのHTML5化などの時代の流れに影響を受けたニコニコ動画が、これまでサービス開始から（見た目やシステム上）大きな変更を加えていなかった動画プレーヤーをごっそり一新。しかし一般家庭の環境では全く使い物にならないレベルの重さと慣れない操作感でユーザーの不満が大爆発。「旧バージョンに一時的に戻す」という段階移行の為の機能にユーザーが殺到するという事態になってしまった。というものなのですが、さらに興味がある人はこのあたりから当時のユーザー反応がどういったものだったか感じ取ってみてください。

なぜニコニコプレーヤーのリニューアルは失敗してしまったのか。先程のニールセン博士のユーザビリティ定義を思い出してみましょう。「学習しやすさ」「記憶しやすさ」は申し分ありません。現代風のシンプルなデザイン、一目で操作方法をアフォーダンスするボタンの数々、おまけにマウスカーソルに合わせて情報が出たり隠れたりするインタラクティブデザイン性まであるのですから、UIの設計としては申し分無いように見えます。

では、その他の項目に着目してみるとどうでしょう。「効率性」については、サービス開始以来初めてとなる大幅なUIデザインの改修なので反発が予想されますが、時間経過と共に解決する問題なのでそこまで大きな問題の要因とはなりません。ニコニコプレーヤーリニューアル失敗の重大な問題点は「エラー」と「主観的満足度」にあります。

あるユーザーの言葉で、この問題の核心を的確に捉えた一言があります。

「私たちはニコニコ動画で動画を観たいんです 動画プレイヤーを見たいんじゃない」

先述のとおりユーザーの不満が最も大きく募ったのはその「重さ」です。システム的には正常に動画が視聴出来るのだとしても、それが利用に耐えない程の精神的苦痛を伴うようなものであれば、動いていたとしても「エラー」とするのが妥当でしょう。しかもそれが今まで出来ていた物が改修によって出来なくなったのですから、「主観的満足度」は当然のようにガタ落ちします。

私はこの問題について、最近UIとセットで語られる事の多いUX（ユーザー体験）について、プレーヤー開発者側が間違った解釈をしてしまったが為に起こってしまったのだと考えています。

まずUIとUXについてですが、語感が似ているというだけで本来セットで語るものではありません。UI（ユーザーインターフェース）とは、純粋に操作機能を司る部分の事を指し、UX（ユーザー体験）とは、過去・現在・未来を含めた体験全体の事を指します。

よく混同されがちな誤った認識の例として、UXはUIの結果として存在するというものがあります。「ユーザビリティを向上する為には、UIを操作して得られるUX（ユーザー体験）を向上すれば良い」といったように、ユーザーの操作によって生じるUXにフォーカスをしていった結果、使いやすいUIが出来上がるというような機能的合理性の考え方です。

この考え方ではUIの利用中という「現在」にしかフォーカス出来ず、それまでのUIにユーザーが慣れ親しんだ「過去」と、これからずっとこれを使い続けなければならなくなるという「未来」が無視され、欠落してしまうのです。「UXの為のUI」という考え方には、そういった問題点があるのです。

私はニコニコプレーヤーリニューアル時のUI開発者のコメントを聞きましたが、機能的合理性の追求によるユーザビリティ向上を語っており、まさにこの「UXはUIの結果として存在する」解釈によって作られたものなのだという事を確信しました。

「動画を見たい」というシンプルなユーザーの欲求を理解せずに、客観的に見て合理的な形へと変えてしまう。こういった開発者側が考えている「ユーザビリティ」と、ユーザー側が考えている「ユーザビリティ」に乖離が起こってしまった事が、ニコニコプレーヤーリニューアル失敗の最大の要因なのではないでしょうか。

本当の意味でのユーザビリティとは

「UXの為のUI」の様な機能的合理性の考え方では、過去と未来が無視されてしまってユーザビリティの中の「主観的満足度」が低下するという事を書きましたが、これは行動経済学の分野ではプロスペクト理論というもので証明されています。

プロスペクト理論とは、人間の損得に対する感じ方は参照点の在処によって異なる（の他にも色々あるのですが小難しくなるのでここでは割愛します…）という理論で、特に得の部分より損の部分を過大に捉えてしまうという特性を備えています。ニコニコプレーヤーの例で言うと、それまでのUIで「出来ていた」というのがユーザーの参照点。ユーザーは「あれに比べて今回はどうだったか」という視点でUIに対する判断を下すので、前出来ていたスムーズな動画視聴が出来なくなったという「損」に対して非常に大きなストレスを感じてしまい、結果として酷評に至ったという現象が起こったのです。

もし、あのUIが出来たばかりの新サービスの動画プレーヤーの設計であれば、恐らくあそこまで極端な批判は起こらなかったのではないかと思います。重すぎて動かなかったのは論外ですが、基本的な設計理念としては非常に優れた発想によって作り込まれたUIであったと言えます。

ただ、既存ユーザーにとっては操作性に優れているかという事よりも、前のものより使いやすいかどうかという方が重要であるという心理的な要因を無視してしまった事だけが問題でした。本当の意味でのユーザビリティとは、ニールセン博士が提唱した最後の項目「システムは、ユーザが個人的に満足できるよう、また好きになるよう楽しく利用できるようにしなければならない。」ここに尽きるのでは無いでしょうか。これが満たせていないのであれば、他の全ての項目が満点であっても、ユーザーにとっては「使いにくい」ものと判断されてしまうのだと思います。

まとめ

• アフォーダンスは設計の基礎ではなく、仕上げのスパイス
• UXは「点」ではなく、過去や未来を含めた「線」で満足させなくてはならない
• ユーザーは得よりも損を大きく捉える

今回は情報アーキテクチャから少し離れて、UIとUXに行動経済学の観点を混ぜてケーススタディーをしてみました。情報アーキテクチャも誰にとって使いやすくまとめるかが大事という事を以前の記事で書きましたが、UIの設計においてはその観点が更に重要になってきます。逆にUIの設計がしっかり出来るWEBクリエイターであれば、情報アーキテクチャの考え方は特別意識せずとも出来ているのだと思っています。とはいえ、情報アーキテクチャはUI設計の上流工程な訳ですから、ここをスキップしてWEBサイト・サービスの設計は成し得ません。可能であれば実案件で生のユーザーや生のビジネスニーズを感じた上でスキルを磨いていくのがベストなのだと思いますが、なかなかそういう案件は転がってないですよね・・・。転がってこないかな（ﾁﾗｯ