UXデザインの法則を読んで感銘を受けたのでまとめた

本の概要

会社の人に勧められて読んでみたところ、とても良かったです。 行動心理学の側面でユーザーにとって良いUXについて書かれています。

150ページ程度の本ですが、10の法則について、端的にまとまっており、事例もあるため、非常にわかりやすく、読んでいて納得感があります。

各法則を簡単に紹介したいと思います。

1. ヤコブの法則

ヤコブといえば、ユーザービリティエンジニア原論ですかね。 この法則は、「慣れ親しんだ見た目であれば同じように動くと、ユーザーは期待する」というものです。

どんな話かといえば、ドアノブのついたドアが、引き戸だったら、戸惑いますよね。そういう話です。 ドアノブがあれば、回してから、押すなり引くなりするのを想定するのが普通です。

新しく何かを作る場合でも、世の中にあるものを踏襲したほうがユーザーはわかりやすいです。 また、既存のものを大きく変えたい場合は、古いものも使えるようにしておかないと、ユーザーは離れていってしまう。

GoogleとかAWSとかコンソールのUIをちょいちょい変えますが、旧バージョンを使えるようにしていますね。

↑ AWSのEC2のコンソール。UIを切り替えることができます。

2. フィッツの法則

「クリックさせたいとか、タップさせたいとかいう、ターゲットについて、十分に大きく、他のターゲットと十分に離れていて、簡単に届かないといけない」というものです。

スマホのソフトウェアキーボードとか、キー同士が十分に離れてないと押し間違えてしまいます。ただ、離れすぎていても使い勝手は悪いです。 OKとキャンセルが近接していて、十分に間隔が開いていなければ押し間違えてしまいます。よく使うターゲットがスマホの右上とか左上とかにあると、押しにくい...とかそういうことですね。

ラベルとフォームが並んでいるときに、ラベルをタップしたら、フォームにフォーカスが当たるというのも、この法則に則っています。

3. ヒックの法則

「意思決定をさせたいなら選択肢は少ないほうが良い」というものです。

例えば、有料プランが10種類もあると、ユーザーは何を選択したらいいか比較検討するものが多すぎるし、意思決定がなかなかできない。 なので、たいていサービスで有料プランは３つ程度に抑えられているし、さらに、おすすめのプランみたいな表示をして、ユーザーが意思決定にかける負担を減らしています。

↑ tandem.chat の pricing のページ

↑ Google Workspace の pricing のページ

もし複雑な意思決定が必要だったとしても、細かく分解して、それぞれの意思決定を小さくすればユーザーの負荷も減ります。

人間も、コンピュータ同様ワーキングメモリがあって、情報が多すぎるとワーキングメモリから溢れてしまう。 そうすると、見るべき情報が落ちてしまったり、イライラしてやめてしまったりする。

タスクいっぱい詰め込んでると、見落としが多くなったりしますね。わかりみが激しい...。

意思決定だけではなくて、ナビゲーションが多すぎるメニューや、機能が多すぎるリモコンなど、ユーザーが選択するのに、必要な情報が多すぎると、処理できなくなって諦めてしまう。

ただ、逆に単純化しすぎて、アイコンだけみたいになってしまっても、アイコンの意味を推測したりするのに負荷がかかっても良くないので、アイコンはラベルと一緒にしたほうが良いとか紹介されていました。

4. ミラーの法則

「人間が短期的に記憶できるのは、7(±2)まで」というものです。

これは誤解が多いというように紹介されていますが、7(±2)の文字数にしないといけないのではなく、ある程度の塊にチャンク化すれば良いということです。 携帯電話番号は11桁ですが、3-4-4の桁数で3つにチャンク化されているので、読みやすいし、覚えやすい。

チャンク自体の大きさが…という話でもなく、例えば、長い文章をだらだら書くのではなく、階層化や構造化する。 ちゃんと分類して、他と区別が付くようなチャンクにするということが重要とのことです。

5. ポステルの法則

「入力については寛容に扱い、出力については厳密に扱うべき」というものです。

住所は全角のみで入力しないといけない...というようなサイトがありますが、典型的な悪い例です。 全角・半角だろうが入力はどちらも許して、内部で正規化してやればいいだけです。

また、昨今ではいろいろなデバイスからアクセスされることがあります。PCだけしか、スマホだけとか、じゃなくて、両方から入力できるようにするほうが良いし、なんなら、ウエアラブルデバイスとかTVとかゲーム機とかVR機器から入力される場合もありえます。

サービスによっては、色んな言語を使う人からアクセスされる場合もありますので、言語によって単語の長さも異なります。 それに合わせてメニューを多少削ったりする必要もあるということにも言及されています。

6. ピークエンドの法則

「人間の記憶に残るのは、感情のピークのとき(ポジティブでもネガティブでも)と、最後に近いところ。また、人はネガティブな感情のところの方を思い出しやすい」というものです。

客観的、全体を平均的に見れば「良い」と判断できる事象でも、最後にネガティブな感情になると、それが非常に強く残るというものです。 遊園地に行って楽しかったけど、後半は雨に振られてびしょぬれになって散々だったとか。楽しかった記憶よりも、後半の悲惨な記憶のほうが残りやすい、みたいな感じです。

事例として、MailChimpというサービスでは、ユーザーがメールを初めて送ったらハイファイブする画像とメッセージがでるそうです(この話はProduct Led Growth)でも例にあがっていました。 Slackとかでも、all unread の未読をなくしたら、楽しげな画像がでたりしますね。

↑ Slackの all unread を全部読んだときの表示(The world is oyster については、こちらに解説がありました)

twitterのクジラ、Githubの404、Googleで検索結果が見つからなかった時に表示しているページがちょっと楽しい感じになっているのは、ネガティブピークを、ネガティブなもので無くす役目があるようです。

↑ Googleで検索結果が見つからなかった時のページ(ちなみにクリックするとなにか釣れます)。

7. 美的ユーザビリティ効果

「デザインが美しいと、使い勝手が良いと思ってしまう」というものです。

明らかに使い勝手がわるいUIでも、デザインが美しいと、使いやすいと思ってしまう。

もし、本当にユーザビリティだけをテストをしたいなら、簡素なデザインでテストしたほうが良さそうです。

でも、本番ではデザインが美しければ、ユーザビリティの不備をごまかすことができるかもしれません。　

8. フォン・レストフル効果

「似たものが並んでいると、その中で異なるものが記憶に残りやすい」というものです。 逆に言うと、全部同じような感じだと記憶には残らないということですかね。

重要なアクションや情報は、色を変えるとかコントラストを変えるなどで注意を引くようにすると良いというものです。

フィッツの法則のところにあった、料金のところで、目立たせるというのは、これにも関連しそうですね。

ただ、コントラストの差も多用しすぎると逆に目立たなくなります。また、色覚障害の人(日本国内で320万人、男性は20人に1人が色覚に障害があるとのことです)にも考慮しないと、色を変えても一部の人には意味がないことになりそうです。

9. テスラーの法則

「どんなシステムでも、それ以上複雑さを減らすことができない、複雑性保存の法則というものがある」というものです。 本に挙げられている例ですと、メールを送る場合、From, To, Subject, Body というのが必須の複雑性としてあります。

この複雑性の負荷をシステムかユーザーが請け負う必要があります。

• Fromは、ユーザー自身ですので自動的にシステムで決定できます。
• Toは、ユーザーが入力することができますが、部分入力で推測等はシステムでできます。
• Subject, Body は、ユーザーが書く必要があります(Bodyは、Gmail だと、アシストしてくれたりしますね)。

ECサイトの住所入力で、郵便番号を入力すれば住所を補完してくれるのも、システムがユーザーの代わりに請け負っているということです。

自分たちの作るシステムの複雑性を考慮して、システムに任せることができるなら、できる限りシステムにやらせるようにすれば、システムの複雑性に対するユーザーの負荷は減りますね。

10. ドハティのしきい値

「0.4秒未満でレスポンスを返すべき」というものです。

• 0.1秒未満の遅延 ... ユーザーは気づかない
• 0.1-0.3秒の遅延 ... ユーザーが気づき始める
• 1秒以上の遅延 ... ユーザーは他のことを考え始める

最近のコンテンツ量の増大(昔(20年以上前)は100KB未満にしろとか書いてたな)とか、スマホのレイテンシとかを考えると、すべてを0.4秒未満に返すことはなかなか難しいと思いますが、

• 0.4秒未満でガワだけ出しておいて、画像等を遅延ローディングする
• ロード中を表す画像を表示する
• プログレスバーを表示する(不正確でもOK)

といったことを行うことで、ユーザーに速くレスポンスを返す、動いているということを伝える、ということが重要とのことです。 プログレスバーは不正確でも良いとありますが、ファイルを大量コピーするときのプログレスバーは明らかに嘘やろ...という気分にしかなりませんが。

一方で面白いことが書いてありました。人が想像するよりも、あまりに速すぎると、逆にちゃんと動いているのか疑ってしまう、ということもあるようです。 例えば、100GBのファイルのアップロードに1秒かからなかったら、嘘でしょと思ってしまうと言った感じです(まぁ、これは嘘でしょが正しいでしょう)。

例えば、1000人のユーザーにメールを送るという処理が、0.1秒で終わったら、本当に終わってんのかな？って思う人もいるかもしれませんね。

終わり

というわけで、10の法則を簡単に説明してみました。実際の書籍には、論拠とかが書いてあったり、例がもっと豊富にあるので、ちゃんと読んでもらったほうが絶対良いと思います。法則以外にデザインシステムの話等にも触れています。

なんらかのサービスや、システムに関わるなら必読書じゃないかな、と思いました。