人間の認知から、HIG の作法、フォームの一行まで ── 設計が依って立つ根を、十二章で辿り直す
UX という言葉が氾濫した時代に、もう一度根を掘り直す
UX という言葉は、すっかり安くなった。求人票に「UX 重視」と書かれ、スライドの隅に「UX ファースト」と添えられ、ボタンの色を変える会議が「UX 改善」と呼ばれる。言葉が広まると、語の真ん中にあった重みが薄まる ── これは、どの分野でも起きる病だ。
本書は、その重みを取り戻す試みである。User eXperience という言葉を 1990 年代の Apple に持ち込んだ Donald Norman は、それを「製品を作る側」の概念としてではなく、使う人の世界の側から発想する態度として用いた。パッケージを開ける指の感触、初めて画面を見たときの戸惑い、エラーが出たときの落胆、半年後に思い出される最初の体験 ── そのすべてが「ユーザの経験」であって、画面の中の話に限らない。
UX とは画面の話ではなく、使い手の世界がどう動くかの話である。だから本書は、ボタンの色や角丸の半径から始めない。人間の目はどこを見て、頭は何を覚え、何を忘れるのか ── そこから始める。表層は最後に乗る。
本書の構成は五段だ。第一部 (1〜4章) は根源。UX という言葉の出自と、人間という生き物の制約、頭の中の地図、モノに対する読み取り。第二部 (5〜7章) は原則。Jakob・Fitts・Hick らの法則群と、Nielsen の検査表、情報設計とフロー。第三部 (8〜9章) はプラットフォーム。iOS と Web、それぞれの土地の方言。第四部 (10〜11章) は細部。状態・モーション・フォーム・アクセシビリティ。最後の第五部 (12章) は検証。作った後にどう確かめ続けるか。
UX を学ぶ上で最初に外してほしい補助輪が、「ユーザ」という抽象である。ユーザはペルソナの紙の上にいるわけでも、アナリティクスのグラフの中にいるわけでもない。目の前の他者として、自分とは違う頭・違う指・違う事情で画面を触る、たった一人の人間だ。設計の問いはいつも「この一人にとって、どう動くか」に着地する。
本書のタイトルを目の前の他者としたのはそのためだ。設計とは、自分とは別の頭の中の地図を借りて、その地図の上で道筋を立て直すことだ。借り物の地図のままでは何も作れないが、自分の地図だけで作ったものは誰にも届かない。コーヒーを淹れて、はじめよう。
言葉の出自を辿ると、UI との切り分けがはっきりする
1993 年、Apple に在籍していた Don Norman は、自分の役職名を「User Experience Architect」と命名した。それまで「Human Interface」「Usability Engineering」と呼ばれていた領域を、もっと広く ── 製品を箱から取り出す前から、買って一年後にサポートに電話する瞬間まで ── 含む語が必要だった。彼は後にこう語っている。「私は experience という語を、人々が製品やサービスと接触するすべての側面を包む傘として使いたかった」。
つまり、UX という言葉が生まれたときからずっと、それは画面の中だけの話ではなかった。にもかかわらず、現代では「UX = 画面の使いやすさ」と狭く理解されることが多い。これは語の出自を取り違えている。
UI (User Interface) は表層だ。ボタン、色、文字、間隔、アイコン ── 目に見えて、指で触れる部分。UX (User Experience) は経験全体だ。広告でその名を初めて聞いた瞬間、ダウンロードボタンを押したとき、初回起動の戸惑い、毎日使う中での慣れ、解約しようとしたときの摩擦 ── 表層も含むが、それより遥かに広い。
線引きは単純だ。「画面の中で起きること」が UI、「画面の前後で起きることまで含めた、人の経験」が UX。だから UI デザイナーが UX を語るとき、それは経験のごく一部 ── 表層 ── を語っている。表層は重要だが、それで全部ではない。
UI は画面の構造。UX は人の経験の構造。よく出来た UI は良い UX に貢献するが、良い UI だけでは UX は完成しない。経験は、画面の前と後ろにも続いている。
Norman は『Emotional Design』(2004) で、人がモノを経験する際の三つの相を整理した。設計者にとって、この三相は設計の力点をどこに置くかの地図になる。
本能は最初の 0.5 秒で勝負がつく。行動は使うたびに積み重なる。内省は体験の終わり方で大きく上下する (これは第5章の Peak-End Rule で詳しく扱う)。三つは独立ではなく、互いに影響する。本能で減点された製品は、行動が多少優れていても挽回しにくい。
UX デザイナーという肩書きが氾濫した時代、職能としての境界は曖昧になった。リサーチャー寄り、IA 寄り、UI 寄り、プロトタイプ寄り、ライティング寄り。会社によって意味が違う。だが本書では、肩書きの話はしない。誰が何を担当するかではなく、製品を作る者は全員、目の前の他者の側に立つ責任があるという前提で書いている。
エンジニアが「UX は別の人の仕事だ」と言ってバリデーションのエラー文言を雑に書くなら、それは UX を狭く誤解している。デザイナーが「実装の話は別だ」と言ってロード時間を考えずに作るなら、それも同じく狭い。経験は分担できないからだ。
ユーザは賢くないのではない。ユーザは余裕がない
設計の出発点は、人間という生き物の性能仕様を知ることだ。視覚系の解像度、注意の幅、短期記憶の長さ ── これらは個体差はあるが、種としての上限が決まっている。設計者がいくら派手な情報を投げても、人間の側で処理できる量には限界がある。
目の前の一点を見たとき、はっきり見えている範囲 (中心視野・fovea) はわずか視角 2°程度だ。腕を伸ばした距離で親指の爪一つぶん。それより外側は急速にぼやけ、視野の端 (周辺視野) では色も形もほとんど判別できない。我々が「全体を見ている」と感じるのは、目玉が高速に飛び回って (サッカード運動) 中心視野を継ぎ接ぎしているからだ。
この事実は、画面設計に二つの重要な含意を持つ。一つは、同時に視認できる要素はごく少ないこと。一つの画面に並んだ十個のボタンは「並んで見える」が、実際にはユーザは順番に視線を移して読んでいる。もう一つは、周辺視野は動きと色には敏感であること。だからトーストや通知バッジが端で点滅すると、それだけで集中が切れる。
人が一瞬で「見えている」と思う範囲は、視角 2°、画面で言えば数センチ四方しかない。情報を並べるとき、設計者は「ユーザの目の動線」を設計している。目は思っているより一点しか見ていない。
「マジカルナンバー 7 ± 2」(Miller, 1956) という言葉を聞いたことがあるかもしれない。短期記憶は 7 個前後の項目を保持できる、という有名な研究だ。だが Cowan (2001) はこれを更新し、実用的な記憶容量は4 ± 1に近いと示した。リハーサル (頭の中で反復) や記憶術なしで保持できるのは、せいぜい三〜五個。
これは設計に直接効く。ナビゲーションの一階層に並べる項目数、ウィザードのステップ数、エラーメッセージ内の指示の数 ── どれも 4 ± 1 を意識すべきだ。それを超えると、ユーザは項目を確認するために何度も目を行き来させる (チャンクの再構築) ことになり、認知負荷が跳ね上がる。
Sweller の認知負荷理論は、画面を見たユーザが何で疲れているかを三つに分ける。設計者は、無くせるものを無くし、残すべきものを守る。
悪い UI を見たとき、それが外在的負荷を作っているかどうかを問う。「これはタスクが難しいのか、それとも私が悪いのか」── 後者なら、設計者の責任で減らせる。
注意 (attention) は、燃料タンクのように連続的に減っていく資源ではない。むしろスイッチに近い。ある対象に注意を向けると、他のことは見えなくなる (inattentional blindness)。ゴリラが画面の真ん中を歩いていても、別のことに注意していると見えない ── という古典的な実験 (Simons & Chabris, 1999) はこの現象を示している。
この事実から、設計者が引き出すべき結論は二つだ。第一に、重要な情報を周辺に置かない。ユーザの注意が中心に集まっているとき、画面の隅にあるバナーや警告は本当に見えていない。第二に、注意を切り替えさせるコストを軽くしない。確認ダイアログを乱発すると、ユーザは「考えずに OK を押す」モードに入る。これがチェック機能を無意味化する。
ユーザは賢くないのではない。ユーザは余裕がないのだ。料理しながら、子どもをあやしながら、電車に揺られながら、本書のアプリを開いている。設計者はその余裕の少なさを前提に組まなくてはならない。
期待を裏切らないとは、最初の3秒で勝負がついている
ユーザは画面を見る前から、頭の中にこれがどう動くべきかのモデルを持っている。冷蔵庫を開ければ庫内灯が点く、ドアハンドルを下げればドアが開く、ボタンを押せば何かが起こる ── そういう期待の網だ。Norman はこれをユーザのメンタルモデルと呼んだ。設計者の仕事は、このモデルと製品の振る舞いを揃えることに尽きる。
同じ製品をめぐって、三つのモデルが存在する。
ユーザがデザイナーと直接話すことはない。両者をつなぐのはシステムイメージだけだ。だから設計が失敗するのは、たいてい「デザイナーのモデルとシステムイメージがずれている」か、「システムイメージから誤ったユーザモデルが組み上がる」かのどちらかである。
設計とは、システムイメージを通じて、ユーザのメンタルモデルを誘導する営みである。ユーザに直接「こう動きます」と説明する機会は (チュートリアル以外) 与えられない。製品の見た目と振る舞いが、自ずから物語を語らねばならない。
Norman は『誰のためのデザイン?』で、コンロのつまみと火口の対応 (mapping) を繰り返し例に挙げる。四つのつまみが横一列に並んでいて、四つの火口が田の字に配置されているコンロ ── どのつまみがどの火口かを記憶する必要があり、しょっちゅう間違える。一方、つまみと火口を同じ田の字で配置したコンロは、見た瞬間にどれがどれか分かる。
これがマッピングだ。操作と結果の対応関係が、空間的・自然的に分かること。良いマッピングは説明を要さない。スライダーを右に動かせば音量が上がる (左下がデフォルト → 右上が大きい、という空間メタファ)、画面を下にスワイプすれば上のコンテンツが見える (物理的に紙を引き下げる感覚) ── これらは強いマッピングである。
悪い例も身近にある。エレベーターの「開く / 閉じる」ボタン。記号 ▶◀ と ◀▶ は、慣れていないと一瞬迷う。プリンタの「印刷面が上か下か」も、機種によって違いマッピングが弱い。設計者は、操作と結果のあいだに自然な対応を作れるかを、まず問うべきだ。
デスクトップ・メタファ ── ファイル・フォルダ・ゴミ箱 ── は、現代でもっとも成功した UX 暗喩だ。物理オフィスに馴染んだユーザに、コンピュータの操作を即座に理解させた。だが暗喩はいずれ古びる。今や紙のフォルダを触ったことのない世代が現れた。ゴミ箱という形象が、画面の中にだけ存在する記号になりつつある。
iOS でフォルダ階層が表に出てこないのも、これに通じる。ファイルを管理するという発想自体が、新しい世代には自然ではない。アプリが自分の領域を管理し、ユーザは「写真を撮った → 写真アプリで見る」という流れで動く。フォルダはアプリの中に隠れている。
ユーザが初めて画面を開いてから、メンタルモデルが組み上がるのに要する時間はごく短い。研究によれば、ユーザは数秒以内に「このサービスは何で、自分はここで何ができるか」を判断する。それより遅い理解は、たいてい既に離脱した後だ。
だから初回画面は、自己紹介より見た瞬間の物語に賭けたほうがいい。長いオンボーディング・チュートリアル・ようこそページは、開発者には親切に思えるが、ユーザにとっては「邪魔」である ── ユーザは触りたい、見たい、結果を確かめたい。説明を読みたくない。
強いプロダクトは、画面を見た瞬間に役割が伝わる。検索バーが中央にある → 検索するんだな。地図が広がっている → 地図を使うんだな。チャット欄が下にある → 話すんだな。ここに不要な装飾や挨拶を被せると、最初の3秒が霞む。
フラットデザインが奪ったものと、Liquid Glass が取り戻したもの
椅子は「座る」をアフォードし、ドアハンドルは「握って引く」をアフォードする。Gibson が生態心理学から持ち込んだこの概念を、Norman は設計の語彙として使い直した ── そして自分でも何度か定義を更新した。本書では、現代の Norman 定義に沿って区別する。
アフォーダンス (affordance) は、モノとユーザのあいだに存在する関係である。コップは大人の手にとっては「掴む」をアフォードするが、生後数ヶ月の赤ちゃんには違うアフォーダンスを持つ。関係であって、モノの属性ではない。
一方、シグニファイア (signifier) は、そこに何のアフォーダンスがあるかを知らせる手がかりだ。ドアの取っ手の形は「握れる」を知らせる。Web のボタンに付いた影は「押せる」を知らせる。テキストの下線は「リンクである」を知らせる。シグニファイアは、アフォーダンスを視認可能にする装置である。
設計者が触れるのは、ほとんどシグニファイアの方だ。アフォーダンスはユーザとモノの関係なので、設計者が直接いじれない (大人向けにしか作らない、と決めることはできる)。だがシグニファイアは、設計者が選んで配置するものだ。良い設計とは、適切なアフォーダンスに、適切なシグニファイアを乗せることである。
アフォーダンス = モノとユーザの関係 (押せる・掴める・読める)。シグニファイア = その関係を知らせる手がかり (影・色・形・テキスト)。設計者は、後者を選んで配置する。
iOS 7 (2013) で Apple がフラットデザインへ大転換したとき、UI 界には激しい議論が起こった。それまでの skeuomorphic (擬物的) デザイン ── 革のテクスチャ、紙のメモ帳、影のついたボタン ── は「ダサい」と片付けられ、フラットで影のない、軽快な見た目が支配的になった。
美学的には大きな前進だった。だが UX 的にはシグニファイアを多く失った。影が消えると、ボタンがボタンに見えなくなる。下線が消えると、リンクが本文と区別できなくなる。「これは押せるのか?」をユーザが判断する手がかりが減った。結果、最初の数年は「タップできる場所が分からない」「読み物なのか操作なのか分からない」という UX 上の事故が頻発した。
この十年で、業界は徐々に補正してきた。色での区別、わずかな影、状態 (hover, active) でのフィードバック、輪郭線 ── シグニファイアが、フラットデザインの中で再発明されていった。iOS 26 の Liquid Glass はその到達点の一つだ。触れる感覚を、影と擬物に頼らず、光と動きで表現する方向。
悪いシグニファイアには二種類ある。
第一は偽のシグニファイア ── 押せそうな見た目なのに押せない要素。文字に下線が引かれていてリンクに見えるが、ただの強調だった、というケース。ボタンのようなボックスを並べたが、実はラベルにすぎなかったというケース。ユーザはタップして、何も起こらず、混乱する。
第二は欠けたシグニファイア ── 機能はあるのに、それを示す手がかりがない。スワイプで削除できるのに、その示唆が画面上にない。長押しでメニューが出るのに、初見では分からない。これは隠し機能 (パワーユーザ向け) としては有効だが、デフォルトの操作にはしてはいけない。
原則は明快だ。押せるものは押せそうに見せ、押せないものは押せそうに見せない。当たり前に聞こえるが、フラットデザイン以降、この原則を見失った UI は今も多い。
2026 年現在、UI 設計のトレンドは「触れる感覚」を取り戻す方向にある。Liquid Glass、Material Design 3 の Expressive、Web の glassmorphism と subtle motion ── どれも共通して、表面に物質感を与え、操作に重みを乗せる。これはフラット時代への揺り戻しというより、シグニファイアを十分に持ったまま、軽快に見える方向を、業界が長年模索してきた結果だ。
設計者にとっての教訓はこうだ。流行のスタイルに合わせる前に、自分のボタンが「押せる」を伝えているかを毎回問う。色だけに頼っているなら色覚多様性で破綻するし、影だけに頼っているなら暗背景で破綻する。複数のシグニファイア (色 + 形 + 状態変化) を重ねて、頑健に作る。
経験則ではなく、定量的な根を持った設計の物差し
UX 領域には、いくつか「法則」と呼ばれる定量的な原則がある。経験則と区別したいのは、これらの多くが心理学・人間工学の実験に根を持ち、数式で表現できる点だ。設計の場で「なんとなく」を超えて議論したいとき、これらの法則は共通言語になる。
Jakob Nielsen の定理は身も蓋もない。「ユーザは、あなたのサイトより、他のサイトで圧倒的に長い時間を過ごしている。だからあなたのサイトも、他と同じように動くと期待する」。
これは「独自性を捨てろ」という話ではなく、独自性をどこに使うかを選べという話だ。検索バーは右上か中央、カートアイコンは右上、メニューは左上 ── これらの「だいたい同じ位置」を破っても、ユーザは混乱するだけで、ブランドの記憶には残らない。独自性は商品そのものに使うべきで、ナビゲーション位置に使ってはならない。
ユーザは他のサイトで時間を過ごしている。あなたのサイトもそれと同じように動くことを期待している。慣習に従うのは敗北ではなく、ユーザの認知容量を浪費しない選択。
Paul Fitts (1954) が人間工学から導いた式は、現代の UI 設計の物差しのまま生きている。ターゲットに到達するまでの時間は、距離が遠いほど長く、ターゲットが小さいほど長い。式で書けば
T = a + b·log₂(D/W + 1)
D は現在位置からターゲットまでの距離、W はターゲットの幅。対数的に効いてくるのがポイント。ターゲットが小さくなるほど、到達時間は急に伸びる。
含意:
選択肢が増えると、判断時間は対数的に伸びる ── Hick (1952) の法則。具体的には
RT = a + b·log₂(n + 1)
n が選択肢の数。注意すべきは、ここでも対数であって線形ではないこと。選択肢を 2 から 4 に増やすより、4 から 8 に増やすほうが、追加コストは大きい。
含意は明快。最初に見せる選択肢は少なく、必要に応じて段階的に開く。ハンバーガーメニューが嫌われるのは、「すべての選択肢を一段で隠す」ことで Hick's Law を回避しているように見えて、実は「メニューを開くという余分な一手」が発生しているから。タブとの使い分けは、選択肢の数と頻度を見る。日常的に使う 3〜5 個ならタブ、それ以上の選択肢で頻度が低いならメニューに格納。
IBM の Doherty らが 1982 年に示した閾値は、応答時間が 400ms を切ると、ユーザの生産性とエンゲージメントが非線形に向上するというものだった。これより速いと、ユーザはシステムと一体化し、思考の流れが途切れない。これより遅いと、待ち時間に他のことを考え始め、流れが切れる。
2026 年の Web では、Core Web Vitals の INP (Interaction to Next Paint) が 200ms 以下を推奨している。Apple の HIG でも、即座のフィードバックは 100ms 以内に出すように指示される。これらはすべて Doherty Threshold の現代版だ。
日立デザインセンターの黒須・鹿志村 (1995) が示した現象。同じ機能のシステムでも、見た目が美しいものほど、ユーザは「使いやすい」と評価する。これは錯覚ではなく、美的な印象が認知的な余裕を生み、実際に学習やエラー耐性が向上する効果が含まれる。
含意は二重だ。第一に、美しさは UX に貢献する ── 機能要件だけで設計すべきではない。第二に、美しさはユーザの目を曇らせる ── 美しいプロトタイプを見せると、テスターは粗を見落とす。だからユーザビリティテストは、必ず装飾を剥がした状態で一度は行う。
Daniel Kahneman の心理学から来る原則。人は経験を、その平均ではなく、最も強い瞬間 (頂点) と終わり方で記憶する。長いプロセスのうち、九割が平凡でも、頂点と終わりが良ければ全体が「良かった」と記憶される。逆もまた然り。
これは UX 設計に強い指針を与える。リソースが限られているなら、最も感情が動く瞬間と、終わり際に投資する。チェックアウトの「ありがとう」画面、エラーからの復帰画面、退会後のメッセージ ── ここを丁寧に作る価値は、平均的な画面の十倍ある。
これらの法則は絶対のルールではなく、根を持った物差しである。会議で「ボタンを大きくすべき?」と問われたとき、Fitts's Law を共通言語に持ち出せれば、議論は格段に速い。
古い割に錆びない、UI を点検する十項目
Jakob Nielsen が 1990 年に提案し、1994 年に整理した十のヒューリスティックは、いまも世界中の UX 評価で使われる検査表である。三十年以上経って色褪せないのは、これが表層のスタイルに依存しない、ユーザの認知の側に立った原則だからだ。本書では十項目を順に見ていく。新しい技術の話ではなく、何度でも参照できる物差しとして読んでほしい。
システムは今、何をしているのかを、適切な時間内にフィードバックする。ファイルが保存されている、メッセージが送信中である、検索が走っている ── これらをユーザが推測する必要がないように。スピナー、進捗バー、トースト、ステータスバー、保存済みアイコンの色変化 ── すべてこの原則の現れ。
ユーザが知っている言葉と概念で語る。専門用語、内部の実装語彙、デザイナーの符丁を、UI に持ち込まない。「セッションが失効しました」より「ログインし直してください」、「Null reference exception」ではなく「データが見つかりませんでした」。情報の並び順も、自然な順序 (日付順、重要度順、ABC 順) に合わせる。
誤って入った状態から、簡単に抜け出せる。元に戻す (Undo)・やり直す (Redo)、ダイアログのキャンセル、モーダルの ✕、ブラウザの戻るボタン ── ユーザが「ここから出たい」と思ったときに、出口がすぐ見えること。設計者は時に、ユーザを罠にはめたくなる (退会フローを面倒にする等) が、これは長期信頼を裏切る。
同じ意味のものは、同じ見た目にする。同じ場所に、同じ言葉で。一つのアプリ内で、同じアクションが場所によって違うラベルだったり、違う位置にあったりすると、ユーザは毎回学び直す。一貫性は社内 (このアプリ内) と社外 (プラットフォーム標準) の二重で守る ── 詳細は第8章 (iOS) と第9章 (Web) で扱う。
エラーメッセージで対処するより、そもそもエラーが起きないように設計する。これがヒューリスティックの中で最も上流の項目だ。日付ピッカーは未来の日付を選べないようにする、削除ボタンは確認を求める、入力フォーマットは入力中に変換する ── ユーザがエラーに至る前に道を整える。
ユーザに思い出させない。代わりに、目の前で認識させる。コマンドを覚えてもらうのではなく、メニューに並べる。前回入力した値を、フォームに残しておく。タブの名前を、アイコンだけでなくラベルでも示す。記憶は脆い、認識は強い── これは第2章の認知容量の話と直結する。
ユーザに何かを「思い出させる」設計は、それ自体が認知負荷である。目の前に並べておく、選んでもらう方が、ほぼ常に良い。アイコンだけのナビゲーションが嫌われるのは、これに反するから。
初心者には分かりやすく、熟練者には素早く。ショートカット、ジェスチャ、コマンドパレット、テンプレート ── ユーザが慣れてくれば、より速い経路を選べるように。すべてのユーザを初心者として扱うのは親切に見えて、長く使ってくれるユーザを置き去りにする。
ダイアログに、その瞬間に必要でない情報を入れない。必要な情報の隣に立った無関係な情報は、必要な情報の視認性を下げる。これは Aesthetic-Usability Effect とは別の話だ ── 美しさを追求するのではなく、不要なものを削るほうの原則。
エラーメッセージは、(a) 何が起きたかを平易に伝え、(b) なぜ起きたかを示し、(c) 次に何をすればよいかを提示する。エラーコードだけ、技術用語だけのメッセージは、ユーザを途方に暮れさせる。「ファイルが見つかりません」より「指定されたファイル report.pdf が見つかりません。削除されたか、移動された可能性があります。最近のファイル一覧から探してみてください」。
理想は、ヘルプが要らない設計。だが現実には、複雑な機能、稀な操作、トラブルシューティングに対する説明は必要。それらは検索しやすく、タスク指向で書かれ、具体的な手順に分解されているべき。FAQ をだらだら書き連ねるのではなく、ユーザが今どこで詰まっているかに応じて、適切な箇所を提示する。
1994 年の原則が 2026 年でも生きるのは、これらが技術ではなく人間に基づいているからだ。表層の流行はめまぐるしく変わる ── skeuomorphic、フラット、ニューモーフィズム、グラスモーフィズム、Liquid Glass ── が、ユーザの認知の容量・記憶の脆さ・エラーへの恐れは変わらない。Nielsen のリストは、その不変の土壌に立っている。
本書を閉じて、机に置いてある自分のプロジェクトをこの十項目で点検してみてほしい。たいてい、二つ三つは引っかかる。それが現在地だ。
中断耐性のあるタスクフローを組む
個々の画面が美しくても、画面と画面のつながりが崩れていれば、製品は使えない。情報設計 (Information Architecture, IA) とタスクフロー設計は、画面を超えた UX の骨格だ。本章ではこの骨格をどう組むかを扱う。
情報を整理するとき、設計者は二つの軸で迷う ── 階層を深くするか、横に広く並べるか。経験則として、深さより広さを選んだほうが、ユーザは迷わない。一階層に並ぶ項目数を 7〜10 個に抑え、階層は 3〜4 段まで。それを超えると、ユーザは「自分が今どこにいるか」を見失う。
これは Hick's Law の素直な適用ではない。確かに項目を増やすと判断時間は伸びるが、階層を深くすると戻る・進むのコストと現在地把握の負荷が積み上がる。深い階層を一歩ずつ進むより、広い一覧をスキャンするほうが、たいてい速い。Nielsen の Web 研究でも、F 字パターンでざっとスキャンするユーザの行動が繰り返し示されている。
情報のグループ分けと優先順位を決める古典的手法が、カードソート (card sorting) だ。ユーザに項目を書いたカードを並べてもらい、似たもの同士をまとめてもらう。設計者の頭の中の整理と、ユーザの頭の中の整理が違うことが、これでよく分かる。
結果から得るのは三つだ。(1) 同じグループに入りやすい項目 ── ナビゲーションのまとまり。(2) 名前のつけ方 ── ユーザが自然に使うラベル。(3) どこにも入りにくい項目 ── 単独のセクションが要る、あるいは廃止候補。
本格的にやらなくてもいい。5〜8 人にざっとやってもらうだけで、多くは見える。完璧主義より、早く・粗く回すこと。
サイト・アプリのナビゲーションは、おおむね三系統に整理できる。
三系統を混ぜないことが鍵だ。グローバルに「カートに入れる」が混ざると、ユーザは何が常に存在し、何が文脈依存かを判断できなくなる。
機能を作るとき、最初に書きたくなるのは Happy Path (理想経路) だ。ユーザがフォームに正しく入力し、ボタンを押し、成功する。だがリリース後、ユーザの大半はこの経路を通らない。
真剣に作るべきは、Happy Path から逸れたあとの経路だ。
これらは仕様書から漏れがちだが、ユーザの記憶を作る (Peak-End Rule)。「失敗したときに優しかった」ことが、長期信頼を作る。
Happy Path は最低限の動作確認に過ぎない。UX の差は、Happy Path から外れたあとの経路で決まる。中断・エラー・キャンセル・再開 ── これらを主タスクと同等以上に設計する。
ユーザはあなたの製品に集中していない。電車に揺られ、他のアプリの通知に気を取られ、子どもに呼ばれ、上司に話しかけられる。中断は標準であって、例外ではない。
だからフローは中断耐性 (resilience to interruption) を持って設計する。具体的には:
これは技術的にはセッション管理、フォーム状態の永続化、URL ベースのステート表現 ── と地味な仕事の集積だが、ユーザ体験への効きは大きい。
片手で、屋外で、通知に割り込まれながら使われる
iOS というプラットフォームを設計するとき、Apple の Human Interface Guidelines (HIG) は教典であり、地図でもある。だが HIG の項目を一つずつ覚えるより、まずはHIG が何を前提にしているかを理解するほうが、応用が効く。本章では HIG の背骨にある思想と、Liquid Glass 時代の判断軸を扱う。
iOS の HIG は、ユーザが以下の状況にあることを暗黙の前提にしている。
HIG の細則 (タブの順序、戻るボタンの位置、ジェスチャの予約) は、この三つの前提から導かれている。前提を理解せずに細則だけ守ろうとすると、新しい画面サイズ (折りたたみ・iPad・Vision Pro) で混乱する。前提に立ち返れば、自分で判断できる。
HIG の項目を暗記するより、Apple がユーザに対してどんな状況を想定しているかを読む。片手・屋外・割り込まれる ── この三つを意識すれば、HIG にない場面でも合理的な判断ができる。
iOS のナビゲーションは、おおむね四つのパターンで構成される。これらを混ぜずに使い分ける。
誤用の典型は、モーダルで階層を作ること。モーダルの中でナビゲーションスタックを積むと、ユーザは「自分がどこにいるか」を見失う。モーダルは一段で完結するのが原則。複数ステップが要るなら、それは新しい画面遷移にすべきかどうかを問い直す。
iOS は端末側で多くのジェスチャを予約している。アプリが独自のジェスチャを定義するとき、それらと衝突してはならない。
これらの近くに独自ジェスチャを置くと、誤発火が頻発する。たとえばカスタムの「左端からスワイプして削除」は、システムの「戻る」と衝突する。ジェスチャは便利だが、シグニファイアがない (画面に見える手がかりがない) という弱点があるので、主タスクには使わない ── ボタンを残したうえで、熟練者向けのショートカットとして付ける。
iPhone のノッチ、Dynamic Island、ホームインジケータ ── 物理的な制約は画面の縁を侵食する。SwiftUI の safeAreaInset、UIKit の safeAreaLayoutGuide を使い、コンテンツがこれらに被らないようにする。
Dynamic Island はとくに、アプリのライブ・アクティビティを表示する場として 2022 年以降存在感を増している。タイマー、配達状況、音楽プレイヤー ── アプリを開いていなくてもステータスが分かる、第二の画面のような位置づけ。ライブ・アクティビティは「アプリを開かせる」より「アプリを開かずに済ませる」設計だ ── ユーザに優しいが、設計者には自社のエンゲージメント指標との折り合いが要る。
2025〜2026 年、Apple は Liquid Glass という素材表現を OS 全体に展開した。半透明、屈折、反射、深度を持つ「素材」が、UI コンポーネントの上に薄く敷かれる。技術的には Metal シェーダによる動的なぼかし・屈折で、視覚的には触れる感覚が戻ってきた。
サードパーティアプリにとっての判断軸は二つだ。第一に、システムが提供する素材を使うこと。.material や .ultraThinMaterial の標準値で十分に統一感が出る。独自に半透明を作り込むと、システムの素材と微妙にずれて気持ち悪くなる。第二に、素材の使い過ぎを避けること。Liquid Glass は背景・サイドバー・浮いた要素に限定し、本文のテキスト面には乗せない。
プッシュ通知は、もっとも乱用されている UX 機構の一つだ。アプリが許可を求める瞬間、ユーザは強く警戒する ── これまでの経験上、許可するとうるさいことが多いから。
原則:
通知は「ユーザを起こす権限」を製品に貸し出してもらっているという感覚で扱う。乱用は信頼の損失で支払うことになる。
ブラウザという他人の家で、どう振る舞うか
Web は iOS と違って、自分の領地を持たない。ブラウザという他人の家に間借りして、URL バー・タブ・戻るボタン・ブックマーク・拡張機能 ── すべての隣人と共存する。この前提が、Web の UX 設計を iOS と区別する根本だ。
Web の UI は、ブラウザという入れ物の中にある。だから:
この前提を忘れて「アプリのような Web」を作ろうとすると、URL を捨て、戻るボタンを壊し、シェアできない画面を量産することになる。SPA 時代の悪い癖だ。
Web は他人の家であって、自分の領地ではない。URL・戻る・履歴・ブックマーク ── ブラウザが提供する機構と仲良くするほど、UX は強くなる。これらを敵に回した瞬間、Web の良さが消える。
Web は画面サイズが連続的に変わる。だが現実には、デバイスの分布は離散的だ。設計と検証は、五つのブレークポイントを基準にする。
モバイルファーストで作る、というのはこの順番で設計するという意味だ。320px で動くものを作り、画面が広くなるごとに余裕を活かす要素を足す。逆方向 (デスクトップで作って、モバイルで削る) は、たいてい失敗する。
Web のユーザは、四種類の入力デバイスを使う。設計はこの四つすべてで成立する必要がある。
注意したいのは、hover に依存しないこと。タッチデバイスには hover がない (タップしないと出ない)。重要な情報を hover の中にだけ置くと、モバイルで見えない。hover はあくまで補助、本来の情報は clickable な状態で見えていなくてはならない。
2026 年の Web パフォーマンスは、Core Web Vitals の三指標で測られる。これらは Doherty Threshold の現代版だ。
これらは検索ランキングにも影響するため、ビジネス指標としても直接的だ。とくに CLS ── 読み込み中に要素が後から飛び込んできて、押そうとしたボタンが別のものになる現象 ── は、UX 上もっとも嫌われる挙動の一つ。画像と広告に明示的な幅・高さを指定し、フォントの読み込みでテキストが置き換わるときの揺れを最小化する。
Web のテキストは、本のように長く読まれる。タイポグラフィは UX に直接効く。
Web フォントは便利だが、読み込みが遅いとテキストが消えたり、フォントが切り替わって行長が変わったりする。font-display: swap と、フォールバックフォントの選択で、揺れを最小化する。
Web 特有の二つの作法に触れておく。
第一、戻るボタンを尊重する。SPA でも history API を使い、論理的な戻る・進むが正しく動くようにする。ユーザは「戻る」を Undo として使う ── モーダルを閉じる、フィルターを解除する、検索結果に戻る。これが壊れていると、操作を取り消したいたびにページ全体を再ロードさせることになる。
第二、URL に状態を載せる。検索クエリ、フィルター、ソート、ページ番号 ── これらを URL のクエリパラメータに乗せると、ユーザはその状態を共有・ブックマークできる。「あの検索結果の3ページ目」を URL でシェアできるサイトと、できないサイトでは、ユーザの再訪率が大きく違う。
マイクロインタラクションが、製品の手触りを決める
機能を作るとき、設計者は「何かがある」状態に注目しがちだ。データがある、操作が成功した、画面が満たされている。だが UX の質を決めるのは、しばしば「何かがない」状態のほうである。空っぽの画面、読み込み中の画面、エラーで失敗した画面 ── この三つの「ない」を、本章では一つずつ扱う。
空状態 (empty state) は、ユーザがまだデータを持っていないときに表示する画面だ。初めてアプリを開いたとき、ToDo リストにまだ何もないとき、検索結果が 0 件だったとき ── これらは別物だが、共通する設計原則がある。
悪い空状態の典型は、真っ白の画面に「何もありません」とだけ書くこと。これはユーザに「何をすればいいか」を伝えていない。良い空状態は、(a) 今が空である理由を簡潔に説明し、(b) 次に取るべきアクションを提示し、(c) 必要なら画面の意義を伝える ── という三要素を持つ。
たとえば「タスクがまだありません」より、「最初のタスクを作って、今日の予定を整えましょう」と書いたうえに「タスクを追加」ボタンを置く。Slack の空チャンネルが「最初のメッセージを書きましょう」と促すのも同じ構造だ。
(1) 今が空である理由、(2) 次に取るべきアクション、(3) この画面の意義。空状態は「機能の入口」であり、ここを丁寧に作るかどうかで、新規ユーザの定着率が変わる。
データを取得中のフィードバックには、いくつかの選択肢がある。それぞれ向き不向きがある。
1 秒以下なら、何も出さないことすら選択肢に入る。スピナーが一瞬光って消えるのは、かえって視覚的なノイズだ。100ms 以下なら無、100〜1000ms ならスケルトンか何も、1秒以上ならスピナーかプログレスバー ── このあたりを目安に。
エラー画面の出来は、UX の評価を最も大きく左右する。Peak-End Rule で言えば、エラーは「最も感情が動く瞬間」の代表だ。ここを雑に書くと、それまでの良い体験が一発で台無しになる。
エラーメッセージの構造は、Nielsen の第 9 ヒューリスティックに沿う。
悪いエラー画面の例: 「エラーが発生しました。しばらく経ってからもう一度お試しください」。これは三要素すべてが欠けている。何が起きたかも、なぜも、何をすればよいかも分からない。「しばらく」が何分なのかも示されない。
逆に、システム側で自動的に解決できるエラーは、ユーザに見せずに済ませる。ネットワークが一瞬切れただけなら、リトライしてから再表示。バックグラウンドで再接続。エラーは出さずに済むなら、それが最善だ。
Dan Saffer は『Microinteractions』(2013) で、小さな相互作用を四つの構造に分解した。これは個々のボタンの押下感、トグル、いいね、リフレッシュ ── すべてに適用できる。
たとえば「いいね」ボタンのマイクロインタラクションを分解すると、トリガーはタップ、ルールはサーバへのリクエストとローカル状態の更新、フィードバックはハートアイコンの色変化・小さなアニメーション・haptic、ループは長押しでお気に入りリストに加わる、など。これを意識して作ると、何気ない要素も「気持ちいい」に変わる。
アニメーションの良し悪しは、物理に従っているかで決まる。現実の物体は瞬時に動き始めず、瞬時に止まらない。慣性があり、摩擦があり、跳ね返りがある。Disney の『The Illusion of Life』が定式化した 12 原則 (Squash and Stretch、Anticipation、Slow In Slow Out、等) は、いまも UI モーションの土台だ。
UI 設計での実用的な指針:
一部のユーザは、過剰なアニメーションで気分が悪くなる (motion sickness)。前庭系の感度が高い人、特定の神経疾患の人、単に集中を切らされたくない人 ── 理由はさまざまだ。OS にはアニメーション削減の設定があり、Web では prefers-reduced-motion メディアクエリで検出できる。
このフラグが立っているとき、装飾的な動きは瞬時に置き換え、機能的な動き (進捗、状態変化) は最小限に。すべてを止めるのではなく、必要なものは残す。これはアクセシビリティ (第11章) の一部でもあり、すべてのユーザに優しい設計の延長線上にある。
入力フィールドの一行と、すべてのユーザに届けるという覚悟
UI の中で、ユーザに最も嫌われている要素はフォームだ。会員登録、ログイン、住所入力、決済 ── これらの離脱率は、製品の他のどの画面より高い。本章ではフォームを丁寧に作る作法と、フォームから連続する話題としてアクセシビリティを扱う。両者は別の話題に見えるが、根本は同じ ── すべてのユーザに届けるための実装である。
長年の研究と実装で確立した、フォーム設計の基本則は次の通り。
type="number"、メールなら type="email"、電話なら type="tel"。スマホでは適切なキーボードが出る。autocomplete="email"、autocomplete="given-name" など。ブラウザ・OS が記憶した情報を自動入力できる。バリデーションは、いつ表示するかでほぼ評価が決まる。
悪い例 1: 入力中にずっと赤いエラー。メールアドレスを途中まで打っているだけで「無効です」と出続けると、ユーザは追い詰められる。
悪い例 2: 送信ボタンを押してから初めて、全エラーを一気に出す。十項目入れたのに、上から三つ目で間違えて、すべてやり直し ── という体験。離脱の最大原因。
良い例: フィールドを離れた瞬間 (blur イベント) にバリデーション。打ち終わって次のフィールドへ移ろうとした瞬間に、そのフィールドだけを評価する。エラーがあれば、その場で示し、修正方法を併記する。
ただし、リアルタイムで意味があるバリデーションもある ── パスワードの強度、確認パスワードとの一致、ユーザ名の重複チェック (デバウンス込み)。これらは入力中に出すことで「あと一歩」を知らせる役割を果たす。確認のためのリアルタイムと、叱責のためのリアルタイムを区別する。
入力中はできるだけ静かに。フィールドから離れた瞬間に、そのフィールドだけを評価。送信時にまとめてエラーを並べるのは最悪。リアルタイムは「合格を知らせる」場合にのみ使う。
最も効くフォーム最適化は、項目を消すこと。会員登録に名前・住所・性別・生年月日を全部聞いていないか? 本当にいま要るのか? 後で聞けないか?
原則として、新規登録ではメール (またはソーシャル) + パスワードだけにする。残りは使い始めた後で、文脈に応じて少しずつ聞く ── プロフィール画面で名前、配送時に住所、興味分析で性別 (要るなら) ── 段階的な開示 (progressive disclosure) と呼ぶ。これだけでコンバージョン率が二倍三倍と変わる。
アクセシビリティ (accessibility, a11y) は、しばしば「対応すべき特殊なユーザがいる」という文脈で語られる。これは順序が逆だ。あらゆる人が、いつかは何らかの障害を持つ ── 一時的に (腕を骨折)、状況的に (赤ちゃんを抱えて片手)、永続的に (視覚障害) ── そう考えれば、アクセシブルな設計は全員のための設計だ。
WCAG (Web Content Accessibility Guidelines) は三段階に分かれる。A は最低限、AA は標準的な目標、AAA は最高水準。多くの企業の合理的な目標は AA。日本でも JIS X 8341-3 という形で同等の基準がある。
アクセシブルな設計は「例外への対応」ではなく、「すべてのユーザのための設計」の延長。一時的・状況的・永続的 ── 障害は誰にも訪れる。最初から組み込まれていれば、後から「対応」する必要がない。
WCAG は四つの原則 (Perceivable, Operable, Understandable, Robust) で組まれている。それぞれの実装上の要点を挙げる。
lang) を正しく、エラーの修正方法を示す、ナビゲーションが一貫している、フォームに説明がある。アクセシビリティの八割は、正しい HTML を書くことで自動的に得られる。<div onclick> でなく <button> を使う、見出しは <h1>〜<h6> で階層を作る、フォーム要素には <label> を関連付ける、リストは <ul> や <ol> を使う ── これだけで、スクリーンリーダーはまっとうに動く。
ARIA (Accessible Rich Internet Applications) は、ネイティブの HTML 要素で表現できない場合の補助である。ARIA を多用しなければならない時点で、HTML 構造を疑うほうがいい。原則は「使わずに済むなら使わない」 ── First Rule of ARIA Use と呼ばれる。
実装が正しいかは、実際に試すことで分かる。設計の最後、リリース前に必ず:
この四つの検査を全画面でやるだけで、a11y の重大欠陥はほぼ拾える。完璧でなくていい ── やらないより遥かにマシ、というレベルで踏み出すこと。
デザインは決まるのではなく、決め続けるもの
これまでの十一章は、ものを作る前と作っている最中の話だった。最後の一章は、作った後の話である。リリースは終わりではなく、長い検証と修正の始まりにすぎない。本章ではユーザビリティテスト、アナリティクス、A/B テスト、そして UX を継続するという態度を扱う。
Nielsen が 1993 年に示した「5 人で 85% の問題が発見できる」という研究は、いまも有効だ。完璧な統計を求めて 50 人集めるより、5 人を 3 回繰り返すほうが、ずっと多くの問題が見える ── そして安く済む。
ユーザビリティテストの最小構成:
テスト結果のうち、同じ場所でつまずいた人が複数いた項目から修正する。一人だけの問題は、優先度を下げる (ただし完全に無視はしない)。
5 人の小さなテストを何度も回すのが、最も費用対効果が高い。リリース前に 1 回、リリース後の主要更新ごとに 1 回。完璧な検証を一度行うより、不完全な検証を繰り返す。
定量データは、定性データ (ユーザビリティテスト) を補完する。両者は別の質問に答える:
UX 視点で測りたいのは、おおむね以下:
アナリティクスは設計者にとって便利だが、誤読しやすい。「ボタンの色を変えたらクリック率が上がった」と喜ぶ前に、その下流のコンバージョン率が変わっていないか確かめる ── クリック数を増やすだけなら、誤クリックを誘うだけの設計でも達成できる。
A/B テストは UX 改善の強力な武器だ。だが乱用される。コピーの一語、色相の 5°、ボタン位置の 10px ── 統計的有意性が出るまで回し続けることに、本当に意味があるかを問う。
良い A/B テストは、仮説から始まる。「決済画面が複雑すぎて離脱率が高い → ステップを統合すれば離脱が減るはず」── これに基づいた変更なら、結果がどちらに転んでも学びがある。仮説のないテスト (「とりあえず青と緑どっち?」) は、たいてい小さな差で終わり、何も学ばない。
注意したいのは、長期効果と短期効果のずれだ。クリックベイトな見出しは、短期のクリック率は上げるが、長期のリテンションを下げる。A/B テストの観測期間は、その効果が本当に持続するかが見える長さに取る。
技術負債という言葉が定着したのと並行して、UX 負債という考え方が広まりつつある。短期の納期で雑に作った画面、後で直すつもりだったエラー文言、一時的な対処として入れたモーダル ── これらは積み上がると、製品全体の体験を腐らせる。
UX 負債は、技術負債と違って計測しにくい。コンパイラが警告を出してくれないし、テストも通ってしまう。だが負債は確実に存在し、利息を取り続ける ── ユーザの不満、サポートチケット、解約。
対処は技術負債と同じだ。リストに書き出す (UX バックログ)、定期的に返済の時間を取る、新しい機能のスプリントごとに少しずつ片付ける。「リファクタリング」の語彙を UX にも持ち込む。
UX は、リリースのときに「完成」するものではない。ユーザは変わり、競合は動き、プラットフォームは更新され、社会の前提が変わる。三年前に正解だった設計が、今は古びる。新しい iOS のバージョンが出れば、それに合わせた作法が増える。Web フォントの読み込みが速くなれば、待ち時間の許容ラインが下がる。
だから設計者は、決め続ける。リリース後にも観察を続け、修正を続け、新しい問いに答え続ける。製品が生きている限り、UX も生きている。
本書を閉じて、机に置いてある自分のプロダクトに向き直ったとき、最初にすべきは大改革ではなく、小さく一つを直すことだ。空状態の文言を書き直す、エラー文言に次のアクションを加える、Tab 順序を試してみる ── 一つの章の一つの教えを、月曜日の朝に一つ適用する。それを繰り返す。これが、UX の継続だ。
「ユーザ」という抽象に戻らないために
本書を書きながら、何度も書き直した一文がある ── 「ユーザは賢くないのではない、ユーザは余裕がないのだ」。これは第2章に置いた言葉だが、本書全体の通奏低音だと、自分でも気付いた。
UX の議論は、しばしば「賢いユーザ vs 賢くないユーザ」という構図に滑り落ちる。「これくらい分かるはず」「これは説明しないと分からない」「上級者向け」「初心者向け」── こうした言葉で人を分類することで、設計者は自分の世界に閉じこもる。だが現実のユーザは、賢いか賢くないかの二択ではない。その瞬間に、どれだけ余裕があるかで振る舞いが変わる、流動的な存在だ。
同じユーザが、朝の通勤電車で見るアプリと、夜にソファで見るアプリでは、別人のように振る舞う。集中している時と、子どもをあやしながらの時では、画面の読み取り方が違う。設計者の仕事は、ユーザの余裕の少なさを恒常的に想定し、その上で動くものを作ることだ。
本書を閉じる前に、自分の画面に対してもう一度問う ── 「この画面を、今もっとも余裕のないユーザが見たらどうなるか?」。設計の善し悪しは、しばしばこの一問でほぼ判定できる。
UX という言葉は、これからもしばらく軽く使われ続けるだろう。求人票に書かれ、スライドに添えられ、会議で消費される。だがその言葉の根に Don Norman の問題提起 ── 使い手の側から発想する ── があったことを忘れずにいれば、自分の仕事は錆びない。
本書の十二章は、根源から細部まで一筆書きで辿ったつもりだが、これで完結したわけではない。各章はそれぞれ、その先に厚い本が一冊立っている領域だ。Don Norman、Jakob Nielsen、Steve Krug、Erika Hall、Dan Saffer ── 巻末の参考文献から、自分の興味の方向に深く潜ってほしい。本書はその入口を示しただけだ。
そして何より、本を閉じたあとに、目の前の他者に向き直ること。ユーザではなく、抽象でもなく、たった一人の人間として、画面の向こうに座っているその人に。設計とは、結局のところ、その人の世界を借りる試みなのだ。
── 終 ──
本書の根を辿るための、主要な書物と論文