yuheijotaki.com

【読書メモ】UXデザインの法則 ―最高のプロダクトとサービスを支える心理学

目次・概要

  • CHAPTER1 ヤコブの法則
  • CHAPTER2 フィッツの法則
  • CHAPTER3 ヒックの法則
  • CHAPTER4 ミラーの法則
  • CHAPTER5 ポステルの法則
  • CHAPTER6 ピークエンドの法則
  • CHAPTER7 美的ユーザビリティ効果
  • CHAPTER8 フォン・レストルフ効果
  • CHAPTER9 テスラーの法則
  • CHAPTER10 ドハティのしきい値

著者である Jon Yablonski さんの Laws of UX というWebサイトから10の法則を紹介している本です。

「UXデザインの法則」という本ですが、実際にはUIやユーザビリティに関するTips集といった所感。
同じ類の書籍はオライリーから出ていますが、インタフェースデザインの心理学 シリーズや 「インタフェースデザインのお約束」 よりは広義のUI(UX)について書かれています。

原書 のカバーのほうがおしゃれです。

ポイント

CHAPTER1 ヤコブの法則

ユーザーは他のサイトで多くの時間を費やしているので、あなたのサイトにもそれらと同じ挙動をするように期待している。 - ユーザーが慣れ親しんだプロダクトと見た目が似ていれば、同じように動くことを期待される。 - すでにあるメンタルモデルを活かせば、ユーザーは新たなメンタルモデルの学習なしにタスクに集中でき、ユーザー体験の質が高まる。 - 変更時の違和感を最小限にとどめるためには、慣れ親しんだバージョンを使い続けられる移行期間を設けよう。

Jakob Nielsen さんが2000年に提唱した法則。

  • ページの構成や定番の要素(ナビゲーションや検索)の配置に、普及したデザインパターンや慣例を活用する。
  • ユーザーは他のウェブサイトでの経験の積み重ねを通じて「デザインはこうあるべき」という期待を築き上げる傾向がある。
    • その要因の根源には、メンタルモデル という心理学の概念がある。
      • メンタルモデルとは、システム、特にそのふるまいについて、わたしたち自身がどう理解しているかという概念のこと。
  • 大規模なリデザインを行う場合はGoogleのサービス(Googleカレンダー、YouTube、Gmail)のように、ユーザーが新たなバージョンを使うか選択できるようにしましょう。

Gmail最近新デザイン展開されてましたが、自分はすぐに試す派です。 - Gmailの新デザインの展開が個人アカウントに対しても開始 | ソフトアンテナ

どこまで他のサイトのレイアウトや動きを活用するかは難しいところではあるなと感じます。
ただ本の中でも触れられていますが、このような「同質化」の多くはデザインの慣例に従っているまでで、レイアウト、ナビゲーション、スタイル、検索機能の場所などすべてがバラバラだとすると、ユーザーは以前の経験に頼ることができなく腰砕けになってしまう。
デザイナーは独創的である前に、ユーザーのニーズや文脈、それと技術的な制約を常に考えて最適な方法を選び抜かないといけない、と記されています。

CHAPTER2 フィッツの法則

ターゲットに至るまでの時間は、ターゲットの大きさと近さで決まる。 - タッチターゲットには、ユーザーが正確に押せるために十分な大きさが必要だ。 - タッチターゲット同士は、十分な間隔が空いていなければいけない。 - タッチターゲットは、インターフェース内で、ユーザーが簡単に到達できる場所に置かれてなければいけない。

Paul Fitts さんが1954年から予測、提唱した法則。

  • ユーザーが対象に到達するのにかかる時間は対象の大きさと近さに反比例する
  • モバイルインターフェースでは、画面の中でタッチできる範囲が限られているため、とりわけこの法則が重要になる。

タッチターゲットの推奨最小サイズ

企業・組織サイズ
ヒューマンインターフェースガイドライン(Apple)44 x 44 pt
マテリアルデザインガイドライン(Google)48 x 48 dp
ウェブコンテンツアクセシビリティガイドライン(WCAG)44 x 44 CSS px
Nielsen Norman Group1 x 1 cm

タッチターゲットの要素の間隔 Googleのマテリアルデザインガイドラインでは「8dp以上の余白を空けること」とされている。

タッチターゲットの位置 デスクトップでは一般的に左上から右下に目を走らせる。 スマートフォンでは画面中心部に焦点が寄りやすい。

どこに焦点が当たりやすいかと、どこに届くか、も考えなきゃですね。 - Mobile UX Design in 2022: A Complete Guide | Net Solutions

タッチターゲットのサイズについては所属の会社の仕事の場合、例えばハンバーガーメニューのタップ範囲についてデザイナーさんから「タップエリアはここからここまで」という指示があるのは稀なので、マークアップエンジニアのさじ加減でやっている感じです。

CHAPTER3 ヒックの法則

意思決定にかかる時間は、とりうる選択肢の数と複雑さで決まる。 - 応答に時間がかかって意思決定が遅くなっているときは、選択肢を最小限にまで減らそう。 - タスクが複雑なら、小さなステップに分解して認知負荷を減らそう。 - ユーザーが情報量に圧倒されないように、おいすすめの選択肢を目立たせよう。 - 段階的なオンボーディングを採用し、新規ユーザーの認知不可を最小限にしよう。 - 単純化によって抽象的になりすぎないように注意しよう。

W. E. Hick さんと Ray Hyman さんによって1952年に定式化された法則。

  • インターフェイス上であまりに多くの選択肢があると、効率も優雅さも失われてしまう。
  • プロセスで面でも、わかりやすく目に入る行動喚起要素がない、情報設計が曖昧、ステップに無駄がある、選択肢が多すぎる、情報を盛り込みすぎる・・・、これらすべてがタスクを実行しようとするユーザーの妨げになる。
  • オンボーディングはSlackbotのようにメッセージでユーザーが学習し終えてから段階的に追加機能の説明が始まるのが有効となる。

悪い/良いナビゲーション構造 - Hick’s Law: Making the choice easier for users | Interaction Design Foundation (IxDF)

本のなかでは認知負荷についても触れていますが、ユーザーが最終的に達成したい目的が合った上で

  • UIがどのように動くか
  • 目的のものをどのように探さないといけないか

に対してメンタルリソースが求められ、しかも「そもそも何をしたかったのか」を覚えておく必要がある、というのは大事なポイントだと感じました。
どうしても作っていると「UIがどのように動くか」のみに囚われがちなため。

CHAPTER4 ミラーの法則

普通の人が短期記憶に保持できるのは、7(±2)個まで。 - 「マジカルナンバー7」の数字に惑わされて無用なデザイン制約を作ってはいけない。 - コンテンツを小さなチャンク(かたまり)に分けることで、ユーザーがその情報を扱い、理解し、記憶しやすくできる。 - 短期記憶の容量は、個々人が持っている知識や状況、文脈によって大きく幅があることを覚えておこう。

George Armitage Miller - Wikipedia さんが1956年に発表した論文に由来。

  • ミラーの発見の中心は、制約のある短期記憶を最大限有効活用するために、情報の断片をいかに意味のあるチャンクに整理するかということである。
    • 保存できるチャンク数の上限は、その情報に関する個々人の前提条件によって異なっている。
    • 例えば、ナビゲーションの選択肢は常に見えているもので、適切にカテゴリ分けをしていれば7個以上でも成立する。
  • チャンク化の最も単純な例は、電話番号の書式
    • 4408675309
    • (440) 867-5309
  • もう少し複雑な例は階層性や書式が全くないこと。

✕のほうは「文字の壁(wall of text)」と呼ばれるらしい。 - ウェブ・ユーザビリティの簡単9原則 | knowledge / baigie

主に情報設計やデザイン領域の話になるので、エンジニアは意図を汲み取ってスタイリングすることが大事そうです。

CHAPTER5 ポステルの法則

出力は厳密に、入力は寛容に。 - ユーザーがとりうるアクションや、入力しうる情報すべてに対して理解を示し、柔軟に対応し、寛容であろう。 - 信頼性高くアクセス可能なインターフェースを提供しながら、入力、アクセス、および機能の面で実際に起こりうるあらゆることを予測しよう。 - 予測・対応できることが多ければ多いほど、デザインはより柔軟になる。 - ユーザーからの多様な入力を受け入れ、それを要件に合わせて変換し、入力の境界線を定義し、ユーザーに明確なフィードバックを提供しよう。

Jon Postel さんがTCPの初期実装の際に「ロバストネスの原則」と呼ばれる考え方を導入。もともとはコンピュータネットワーク間のデータ転送を意図したものだったが、ユーザー体験のデザインにも応用されている。

  • ユーザーにとって良い体験をデザインすることということは、人間にとって良い体験をデザインするということ。
    • わたしたちは、プロダクトやサービスが自分のことを直感的に理解してくれていて、寛容であることを期待している。
    • また、常に自分がコントロールできていると感じたがり、必要以上の情報を求められるとイライラしてしまう。
  • ユーザーが、どのような環境で、どの程度のスキルがあるのかについて、実際に起こりうるあらゆるパターンを予測した上で、信頼性やアクセシビリティが担保されたインターフェースを提供すべき、という考え方。
    • 例として、Apple の Face ID、レスポンシブウェブデザイン、プログレッシブエンハンスメントなど。

閉じタグがなくても表示されるHTMLの例 - ポステルの法則 | UX TIMES

やはり身近なのは入力フォームのバリデーションでしょうか。
全角縛りや予測できないエラーなどはいちユーザーとしても辛いですね。

CHAPTER6 ピークエンドの法則

経験についての評価は、全体の総和や平均ではなく、ピーク時と終了時にどう感じたかで決まる。 - ユーザージャーニーの中で最も重要な瞬間(ピーク)と最後の瞬間(エンド)に細心の注意を払おう。 - エンドユーザーを喜ばせるためには、プロダクトが最も役立つ瞬間、最も価値がある瞬間、あるいは最も楽しい瞬間を見定めてデザインしよう。 - 人はポジティブな経験よりも、ネガティブな経験をより鮮明に思い出すことを心に刻んでおこう。

Daniel Kahneman さんらの1993年の論文ではじめて見い出された法則。

  • わたしたちの記憶は、できごとを完全に正確に記録したものではない。
  • ユーザーは最も感情が高まったときに感じたことと、終わりの時点で感じたことが混ざり合い、それが経験全体に対する評価を大きく評価する。
  • Mailchimpの例
    • 会員向けに書き上げたメールの送信ボタンを押そうとする瞬間が「最も感情が高まるとき」
      • シンプルな確認モーダルにとどまらず、イラスト、アニメーション、ユーモアを通してブランドの個性を吹き込むことで、ストレスの多い瞬間を和らげる。
    • 送信確認画面でリダイレクトされるキャンペーン詳細画面が「終わりの時点で感じたこと」
      • ユーザーの頑張りをねぎらうハイタッチのアニメーションで、やりきった安堵感を与える。

IKEAでのショッピング体験もピークエンドの法則の活用事例として挙げられる - ピークエンドの法則:用語集 | UX TIMES

まずジャーニーマップのような設計をしていることが前提ですが、UXっぽい法則ですね。
メールチャンプはどのUXの書籍でも事例として出てくる印象です。

CHAPTER7 美的ユーザビリティ効果

見た目が美しいデザインはより使いやすいと感じられる - 見た目が美しいデザインは、人の脳にポジティブな反応をもたらし、実際の場面でもよく機能すると受け取られる。 - プロダクトやサービスの見た目が美しければ、人は些細なユーザビリティの問題に対してより寛容になる。 - 見た目が美しいデザインはユーザビリティの問題を覆い隠し、ユーザビリティテスト中に課題を発見しにくくしてしまうこともある。

1995年に日立デザインセンターの 黒須正明 さんと鹿志村香 さんが実施した研究が起源となる効果。

  • 見た目が美しいデザインは、ポジティブな感情的反応を生み出すとともに認知能力を拡張しユーザビリティがよいと感じやすくする、且つ信頼性を高める。
  • Braun や そのデザイン哲学に影響を受けている Apple プロダクトの例。

iPod、iPhone、iMacなどのデバイスは、使いやすさを重視しながらも、Braunの製品群からミニマルな美しさを受け継いでいる - アップル製品と約50年前のブラウン社の家電製品がどれくらい似ているか比べてみた - DNA

iOSの電卓もBraunと似ており、インターフェースにも落とし込んでいるのが面白いですね。
ユーザビリティの問題を覆い隠してしまうところは、例えばユーザーインタビューはモックアップから段階的に行うことが解決策かなと思いました。

CHAPTER8 フォン・レストルフ効果

似たものが並んでいると、その中で他とは異なるものが記憶に残りやすい。 - 重要な情報やアクションを視覚的に目立たせよう。 - 視覚的な要素を強調する際には、互いに競合したり、目立ちすぎて広告だと勘違いされたりしないようにしように抑制をかけよう。 - コントラストを伝えるのを色だけに頼ると、色覚障がい者やロービジョン(弱視者)を排除することにつながる。 - コントラストを伝える上で動きを使用する際には、動きに対し敏感なユーザーに配慮しよう。

Hedwig von Restorff さんの1933年の研究を起源とする効果。

  • 人は周囲へ集中力のキャパシティと持続時間の制約から、関連性のない情報を犠牲にいして関連する情報に集中する。
    • これは認知心理学では「選択的注意」として知られている生存本能
      • 一例としてはバナーブラインドネス(広告だと認識されたものが無視される性向)
  • 実例
    • Googleマテリアルデザインのフローティングアクション
    • iOSのアプリの通知マーク
    • ウェブサービスのプランのプライスリストで強調されるプラン

周囲のパターンと似通っていると□や赤丸と違って特異性があると認識しづらい - レストルフ効果 | UX TIMES

デザイン4大原則の「強弱」や、先ほどのミラーの法則にもつながるところかと思います。
逆にあまり立たせ過ぎたり、その量を増やすと力が薄れ、他の要素に埋もれやすくなるのでデザイナーさんの腕の見せどころといった印象です。

CHAPTER9 テスラーの法則

どんなシステムにも、それ以上減らすことのできない複雑さがある。複雑性保存の法則ともいう。 - どんなプロセスも、その核となる部分にはデザインの工夫をもってしても取り除くことのできない複雑性を抱えている。この複雑性による負荷を負うのは、システムかユーザーだ。 - この固有の複雑性をデザインと開発の過程でどうにかしながら、できる限りユーザーの負荷を減らそう。 - シンプルにしすぎてインターフェースが抽象的になりすぎていないかを気にしよう。

Larry Tesler さんがDTP開発の鍵となる対話型システム言語の開発に携わっていたときに発見した法則。

  • どんなプロセスにも固有の複雑性というものがあり、これ以上減らせずどこかにしわ寄せするしかなくなるときが必ずやってくる。
    • つまり、ユーザーインターフェースが複雑になるか、デザイナーやエンジニアの仕事が複雑になるか、のどちらかである。
  • 例としてEメール送信では、差出人と宛先の2つの情報が必要だが、最近のメールアプリでは2つのことが行われている。
    • 差出人を事前に入力しておくことと、宛先の入力開始時に候補をサジェストすること。

優れたデザインは、複雑さの負担がユーザーではなくサービス側で処理する必要がある。 - UXデザイナーなら知っておきたいデザインに関する10の法則 デザイン会社 ビートラックス: ブログ

後から追加で出てくる仕様のようなことではなく、サービスを提供するにあたって本質的に必要なプロセスでも複雑性は介在する、といった内容と理解しました。
現場の立場からすると、どこにしわ寄せがいってるかを対処する人以外が把握できているかも大事な気がします。

CHAPTER10 ドハティのしきい値

応答が0.4秒以内のとき、コンピューターとユーザーの双方がもっとも生産的になる。 - 0.4秒以内にフィードバックを行うことで、ユーザーの注意を引きつけ、生産性を高めよう。 - 体感性能を改善し、感じられる待ち時間を減らそう。 - アニメーションをいれることで、バックグラウンドで読み込みや処理が行われている間も、ユーザーをつなぎとめられる。 - プログレスバーは、正確であってもなくても待ち時間へのいらだちを和らげる。 - ほとんど処理時間がかかっていない場合でも、意図的に遅延させることで体感性能が改善して信頼感の醸成につながる。

IBM社員のWalter J. Doherty さんと Ahrvind J. Thadani さんによって提唱された基準。

  • 人は0.1秒程度の応答時間であればほとんど気づかない。しかし、0.1〜0.3秒の遅延になると目につくようになり、同時にタスクをコントロールできないと感じ始める。
  • 規定時間を短縮できない場合、何かしらフィードバックを返すことが有用。
    • スケルトンスクリーンを表示
    • ブラーアップ(画像を初期はぼかし表示)の利用
      • Mediumの例
    • プログレスバーの表示
      • Gmai、AppleのOSアップデートの例
    • 楽観的UI(処理完了前に楽観的なフィードバックを提示)
      • Instagramのコメント投稿の例

ローディングプレースホルダーよりもスケルトンスクリーンという方が一般的なよう - UXを向上させる5種類のアニメーションの使い方 | UX MILK

フィードバックの仕方について、フロントエンドの実装では時間がかかればかかるほど、ユーザー体験はよくなりそうな印象でした。( プログレスバーよりもローディングアニメーションのほうが簡単など)

感想

どの法則も言われてみればそうだなと感じる反面、いざ制作や開発をしている際に説得力を持って持って言えるかは、知識的なところも必要なのかなと感じました。
すべてのプロジェクトでこのような話ができない場合もありますが、常に具体例を出して伝えて改善できるように日々ウェブサイトやアプリを見てみようと思いました。