読者です 読者をやめる 読者になる 読者になる

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

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

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

シグニファイアとは?UXデザイン型人間中心設計のススメ

UI UX デザイン全般 考え方 シグニファイア IA 人間中心設計

f:id:information_architecture:20141125000053j:plain

どうもこんにちは。最近本格的に自分がデザイナーなのかプランナーなのか分からなくなってきた、おりです。今日のお題は「シグニファイア」です。聞いたことが無い?安心してください。私も今朝知りました。

どこで知ったかというと、「UI/UXなUXのお話」こちらのスライドを拝見した際に知ったのですが、大変共感できる内容が書かれていましたので今回はシグニファイアと人間中心設計の関係性について考えたいと思います。

目次

アフォーダンスという言葉

皆さんは「アフォーダンス」という言葉を聞いたことがありますか?これは認知心理学の分野で古くから使われてきた造語で、小難しい定義を抜きにして平たく言うと「椅子は座るというアフォーダンス(可能性の提示)を持っている。」といった具合に利用します。

アフォーダンスの概念は、UIデザインを嗜む諸兄なら一度は聞いたことがあるでしょうD.A.ノーマン氏によって世界に広められた事で有名なのですが、しかし!どうやらこの言葉の使い方が本来の「アフォーダンス」の意味と乖離していたようなのです。今までずっとアフォーダンスという言葉を得意げに使っていたのでちょっと恥ずかしい思いで一杯なのですが、これを読んでいる皆様はもう大丈夫。明日からは赤っ恥をかかずにすみます。

シグニファイアの概念

f:id:information_architecture:20141125000141j:plain

では、本来のアフォーダンスって何なのさ?シグニファイアってどっから出てきたの?という事を説明したいのですが、いかんせん小難しい理論に満ち溢れているのでイラストで説明します。

ここに1本の道と歩く人が居ます。この図において道は、人はじめとした生物が沿って歩く事をアフォード(アフォーダンスの語源)しています。では、この先の二股で右に行かせたいと思った時、あなたはどうしますか?

f:id:information_architecture:20141125000206j:plain

白線を引く、標識を立てるなど、答えは色々考えられますが、どの答えにしろ、道もしくはその周辺に何らかの意図を持った要素を追加して人を誘導しようとしませんでしたか?その意図を持ったアフォーダンスこそがシグニファイアと呼ばれる概念なのです。

つまり何が言いたいかというと、凡そ全てのデザインと呼ばれるものに使われているのは、実はアフォーダンスではなくシグニファイアだったのです!これはびっくりだ!

ちなみにこの「シグニファイア」という言葉は、他でもないアフォーダンスの誤用を世界に広めたD.A.ノーマン氏自身によって提唱されている言葉です。

念のため断っておきますが、私はノーマン氏の本を読んでアフォーダンスを誤用していたわけではなく、本来の意味のアフォーダンスの概念を知ってからずっと「これこそアフォーダンスに違いない!」と思い込んで知覚されたアフォーダンス(=シグニファイア)をアフォーダンスとして勝手にUIデザインに応用して使っていました。要するにノーマン先生と同じ事してました・・・。

シグニファイアからUXデザインへ

さて、シグニファイアの概念が分かった所でこれをUIデザインに実際に活かして行きたいわけなのですが、私がシグニファイアという言葉を知ることになった冒頭で紹介したこちらのスライドの後半部分でとても良い事を言っています。

開発者は道具の機能や中身を知ってしまっているためUIの操作(利用手順)を中心にデザインしがち。本来重要なのは「ユーザーの頭の中」を中心にデザインすること。

要約すると、UIとはユーザーのやりたいこと(ニーズ)を満たす為に提供すべきものであり、決してその操作を完遂する為に提供するのではない。という事です。認識違ってたらゴメンナサイ。

ニコニコプレーヤーの失敗から学ぶ「UXの為のUI」の問題点とは - とあるWEBデザイナーの情報設計(インフォメーション・アーキテクチャ)

以前の記事で取り上げたニコニコプレーヤーの失敗を例に挙げるならば、プレーヤーは「動画を見たい」というユーザーのやりたいことを満たす為に提供すべきであり、他人へのレコメンドのしやすさ、コメント編集のしやすさ、マイリスト登録のしやすさ等々の機能的な操作を如何にスムーズに行えるかについて突き詰めるのは間違っている。という事になります。あの例では機能面強化によるプレーヤーの負荷増大によって、実際そういったユーザーの反発事例がありましたね。ユーザーにとって「コメントがしやすい」と「動画が視聴しやすい」は別次元の欲求の為、開発者が考える「コメント機能が充実したから多少重くなるのは当然」は全く通用しないのです。

プロダクトの操作をよりスムーズにする為にユーザーに使いやすいインターフェースを作るという視点。これがD.A.ノーマン氏の説いたシグニファイアを用いた人間中心設計の基本的な考え方であり、ニコニコプレーヤーリニューアル時にも用いられたと思われる方法論なのですが、私は個人的に、上で紹介したスライドで示されているようにプロダクトを通じてユーザーの欲求をスムーズに満たす事の出来るインターフェースを作るという視点。すなわち、UXデザインの思考プロセスによって導き出されたシグニファイアの集合体こそ、真の人間中心設計であると考えています。

【図解】機能合理型のシグニファイアとUXデザイン思考プロセス型のシグニファイアの違い

f:id:information_architecture:20141125000235j:plain

今適当に考えた、機能合理型のシグニファイアと、UXデザイン思考プロセスに寄せた欲求リード型シグニファイアを用いたテレビリモコンの設計図です。

テレビをいち早く点けて番組を見る為のデザインか、番組を見る為にいち早くテレビを点ける為のデザインか。これって実は、同じことをプロダクト側視点かユーザー側視点かで言いかえているだけなのですが、そのわずかな言い換えによって上記図のように最終的なプロダクトやインターフェースに大きな差が生まれます。

ゲームのオートセーブ機能とかも考え方が似てます。所謂「設計思想」というやつが根底から違うので同じ制作プロセスを踏んでも全く違うものが出来上がるのですね。

まとめ

  • デザインの世界ではアフォーダンスではなくシグニファイアを用いるべき
  • 機能を完遂しやすいUIデザインだけが人間中心設計の本質ではない
  • 機能合理型シグニファイアだけでは良いUXは得られない

個人的な雑感ですが、優れたエンジニアは機能合理型のシグニファイアを用いた設計に長けており、優れたデザイナーはUXデザインプロセス型のシグニファイアに長けていると感じます。別にこれらに優劣の関係性はなく、扱うサービスや内容によってその性質を上手くバランス調整する事が肝心なのだと思います。

危うく忘れそうになりますが、このブログが扱っているのは情報アーキテクチャ(IA)の考え方に基づいた諸々の方法論などの考察です。複雑な情報の渦の中からユーザーの「やりたいこと」を素早く発見出来るようにファインダビリティを向上してあげるのもまた、情報アーキテクチャ(IA)の領域です。もしIAやUIデザイナーといった役割でプロジェクトにアサインされる機会があれば、このUXデザインプロセス型のシグニファイアの考え方を意識しながら設計してみては如何でしょうか?きっと、UIというものを部品単位ではなく、操作前や操作後も含む画面全体、さらにはユーザー属性によってどう出しわけるべきかなど、より広い視点で考えられるようになると思います。

私もまだまだこの視点を完璧には使いこなせないので、もっと実地経験を積みながら身に着けていきたいですね。

あ、ちなみにここでちょこちょこ出してる「人間中心設計」というものについて、今度「HCD-人間中心設計推進機構-」の資格試験を受けてみようと思います。個人的には人間中心思考で設計をする事など当然の事だろうと思っているので、わざわざこんな堅苦しい資格制度を設けること自体には反対なのですが、まだまだ世間の認知や啓蒙が追いついていない現状を鑑みて利害が一致していましたので、一員として人間中心設計の考え方を広めていきたいという想いもあり、この度受験を決意しました。

とはいえ、実務経験的な縛りでまだ専門家試験は受けられないのでまずはスペシャリスト試験からになり、受かるかどうかも分からないのですけどね。別に受からなくても勝手に私なりの考え方は広めていきますけどね。

誰のためのデザイン?―認知科学者のデザイン原論 (新曜社認知科学選書)

誰のためのデザイン?―認知科学者のデザイン原論 (新曜社認知科学選書)

 
複雑さと共に暮らす―デザインの挑戦

複雑さと共に暮らす―デザインの挑戦

  • 作者: ドナルド・ノーマン,伊賀聡一郎,岡本明,安村通晃
  • 出版社/メーカー: 新曜社
  • 発売日: 2011/07/28
  • メディア: 単行本
  • 購入: 8人 クリック: 67回
  • この商品を含むブログ (3件) を見る
 

 

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

IA UI WEB 考え方 画面設計 Bootstrap

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サービスの企画およびシステムの設計を裏表どっちもやるトンデモ案件が降ってきてしまってちょっと更新が止まってしまってました・・・。楽しいから良いのですが、フォトショを起動してる時間よりパワポを起動してる時間の方が圧倒的に長いので、そろそろ自分が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 IA 画面設計 考え方

目次

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

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

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

駅から学ぶ導線設計

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

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

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

f:id:information_architecture:20140623075808j:plain

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

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

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

まとめ

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

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

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