はじめに　「なんか変」を捨てないために

Web 画面を見て、「なんか変だ」と感じたことはありませんか。

余白を変えてみる。色を強くする。ボタンを大きくする。それでも、なぜ変だったのかを説明できない。レビューで「もう少しいい感じに」と言われても、何を観察すればよいか分からない。本書は、その場所から始めます。

本書は Figma の操作手順や CSS Property の一覧ではありません。人間がどのようにまとまりを見つけ、注意を向け、覚え、選び、予測し、操作結果を待つのかを手掛かりに、画面で起きていることを言葉にする本です。

中心に置く命題は二つです。

名前を知ると、次から見つけられる。

名前を知ると、次から疑える。

近接、類同、ワーキングメモリ、フィッツの法則、メンタルモデル、フィードバック。名前を知ると、それまで「なんとなく」だった差を探しやすくなります。しかし、名前は答えではありません。「認知負荷が高い」「ヒックの法則だ」と言うだけでは、画面のどこで何が起きているかを説明していません。

そこで本書は、人間の特性から Web 上の現象へ進み、定石へ接続した後、必ずもう一度疑います。別の概念でも説明できないか。実装上はどうなっているか。実際の人はどう行動するか。理論を権威ではなく、確かめられる仮説を作るために使います。

本書は無料の電子教材です。学校やスクールへ通う余裕がない人も、一人で読み、図を比べ、問いに答え、DevTools で確かめられるように作ります。教員が授業で使うための進行案も付録に用意します。

デザインを学び始めた人だけでなく、画面を実装するフロントエンドエンジニア、レビューを言語化したい人、HCI や UI を教える人にも向けています。専門用語は初出で分野を示し、日常的な説明と、より正確な定義を分けます。数字を普遍ルールにせず、条件と出典を確かめます。

Web は一枚の画像ではありません。幅と内容が変わり、操作と状態があり、通信を待ち、成功も失敗も起こります。だから本書では、画面だけでなく、HTML、CSS、ブラウザ、DevTools、人の行動へ往復します。

読み終えたとき、すべての正解を知る必要はありません。最初には「余白が足りない」とだけ書いた画面に、どの要素間の距離か、何が同じ役割か、どの状態がないか、何を覚えさせているか、どう確かめるかを書けるようになる。それが本書の目指す変化です。

本書の使い方

四つの部

第 I 部では、人間が画面をまとめ、揃え、補い、動きへ注意する仕組みを見ます。
第 II 部では、注意、記憶、判断、操作の制約を見ます。
第 III 部では、経験から生まれる期待、規則、例外、フィードバック、作者との知識差を見ます。
第 IV 部では、観察、仮説、比較、ブラウザでの確認、DevTools、行動観察を一つの制作へつなぎます。

順番に読むと概念が積み上がりますが、実務の違和感から関連章へ入っても構いません。付録 B の 100 の問いと付録 C のレビュー語変換を入口にできます。

章の読み方

各章は、人間の日常的な現象から始まり、Web 例を比べ、名前と正確な定義を知り、実装へ接続し、最後にその説明を疑います。問いには共通の正解を置かず、答えの例、別の答え方、よくある考え方、注意点を示します。

図では一度に一つの差を見ます。良い／悪いのラベルだけを信じず、何が同じで、何が変わったかを確認してください。色だけでなく、形、位置、文言、説明も合わせて見ます。

参考資料の読み方

章末の「参考」は、権威を並べる欄ではなく、次に進む入口です。一次資料、研究機関、仕様・公式文書を優先し、読みやすい資料も併記します。英語資料は、何を知るためにどこを読むかを添えます。

独習するとき

最初に自分の言葉で書き、答えの例は後から見ます。本文と同じ UI を作る必要はありません。身近なサイトや自分の制作物で、見た条件をメモし、一つだけ変えて比べてください。

他者の行動を見る場合は、第24章の倫理、同意、プライバシー、中止条件を先に確認します。学習のためでも、説明せずに録画したり、本番アカウントへ障害を起こしたりしません。

制作中の補足資料について

この本には、本文のほかに、図版の作り方、参考資料、レビュー記録などの補足資料があります。補足資料には制作中の確認事項も含まれます。読者として読むときは、本文と図版を中心に進め、制作管理用のメモは必要になったときだけ参照してください。

序章　まず、一つの画面を見る

ここでは、架空の権限申請画面を短時間だけ見ます。まだ専門用語を使う必要はありません。「なんか変」「分かりにくい」でも構いません。いま持っている言葉を、そのまま残します。

OPENING-SCREEN-V1を示す図。 — 序図 1　OPENING-SCREEN-V1

観察の手順

まず 30 秒だけ画面を見る。
最初に目に入ったものを書く。
気になった場所と理由を、いまの言葉で書く。
答えを調べず、下の「観察メモ」に記録を残す。

観察メモを残す

このメモは、本書を読み終えた後、第 25 章でもう一度同じ画面を見たときに、最初の記録と比べるために使います。第 25 章では、この画面をもう一度見ます。

下の項目をコピーして、テキストエディタ、メモアプリ、ノート、印刷した紙など、自分が後で見返せる場所に残してください。本書のサーバーへ送信する必要はありません。共有端末を使っている場合は、置き場所を確認し、他の人に見られたくない内容は残さないでください。

序章の観察メモ

最初に目に入ったもの:

気になった場所:

なぜ気になったと思うか:

最初に目に入ったもの

画面を見て、最初に視線が向いたものを書きます。正確な名前が分からなければ、「左上の大きい文字」「右側の青いボタン」のような書き方で構いません。

気になった場所

違和感、見づらさ、迷い、逆に分かりやすさを感じた場所を書きます。一つだけでも、複数でも構いません。

なぜ気になったと思うか

理由を推測して書きます。「近いから」「目立つから」「押してよいか分からないから」のような短い言葉で十分です。理由が分からない場合は、「理由はまだ分からない」と書いておきます。

メモを残さなかった場合

ここでメモを残さなかった場合、第 25 章で最初の観察と読後の観察を比べることはできません。その場合は、別の初見画面を使う単独の観察練習として進めます。

画面図を見づらい場合

画面図を見ることが難しい場合は、代替テキストや長い説明を読んで観察しても構いません。ただし、図を見た場合と説明を読んだ場合では、手がかりの受け取り方が変わります。第 25 章で比べるときは、自分がどの方法で観察したかも一緒に残しておきます。

キーボードだけで操作している場合も、同じ項目をメモアプリや紙に書けば進められます。

第1章　人間は、見たものをそのまま見ていない

画面を開いた瞬間、目には色、明るさ、輪郭、文字、画像などが入ってきます。しかし、私たちが経験するのは、それらを一つずつ数えた結果ではありません。「上にナビゲーションがある」「中央に大きな告知がある」「ここまでが一つの内容に見える」といった、整理された画面です。

この違いは、Web デザインを見る出発点になります。

画面が読みにくいとき、HTML が間違っているとは限りません。CSS の値が一般的な値から外れているとも限りません。画面上の要素が、作り手の意図とは違うまとまりや強さで知覚されている可能性があります。

この章では、内容を詳しく読む前に、画面に見えるまとまり、密度、強さ、流れを観察します。読み終えたとき、画面をすぐに「よい」「悪い」と評価するのではなく、まず「何が、どのように見えているか」を説明できることを目指します。

ここでいう「読む前」は、文字や画像の意味を無視するという意味ではありません。最初の一巡では形と配置を見て、次の一巡で内容へ戻ります。二つの見方を往復するための、一時的な順序です。

最初に、短い観察を試します。次の無注釈画面を、ひとまず 10 秒ほど見てください。10 秒は観察を始めるための便宜的な目安であり、人の知覚を測る基準ではありません。時間を延ばしても構いません。

章末課題と同じ無注釈画面をここへ複製掲載するを示す図。 — 図 1-7A　章末課題と同じ無注釈画面をここへ複製掲載する

詳しく読まずに「分かれて見える領域」「周囲との差が大きい箇所」「繰り返される方向」を一つずつ記録します。この時点では、用語も原因も書かなくて構いません。章末で同じ記録へ戻ります。

この章で見るもの

画面はいくつのまとまりに見えるか

どこに面積、明暗、太さ、孤立の大きな差があるか

どの方向の揃い、反復、間隔が順序を示しているか

内容を隠しても残る構造は何か

HTML の構造と、見た目の構造はどう違うか

1.1 画面にあるものと、見えている関係

目は画面を保存していない

カメラは、レンズを通った光を画像として記録します。このため、人間の目もカメラのように世界を写し取り、脳がその画像を見る、と説明されることがあります。

このたとえは、光が目へ入るところまでを考えるには便利です。しかし、人間が何を「見るか」を説明するには足りません。

私たちは画面の全画素を、同じ精度、同じ強さで経験しているわけではありません。注意を向ける場所は変わります。過去に見た画面の経験も持ち込みます。近いものをまとめ、境界を見つけ、前にあるものと後ろにあるものを分けます。読めないほど短い時間でも、大きな色面や密集した領域は見えます。

ここで区別したいのが、表示上の属性と、知覚や行動についての記述です。

画面には、色、明るさ、位置、大きさなどの表示上の属性がある
観察者には、目標、経験、言語、身体的な条件がある
道具と環境には、ビューポート、ズーム、入力方法、光、中断などの条件がある
それらの条件のもとで、まとまりを報告したり、情報を探したり、操作したりする

この並びは、知覚が順番に処理されて頭の中へ画面の複製を作る、という生理学的なモデルではありません。この章では知覚の神経機構を扱いません。本書で大切なのは、「画面に置いたもの」と「人が条件のもとで報告・利用するもの」を同じだと決めつけないことです。

同じ画面に対する複数の観察を示す図。 — 図 1-1　同じ画面に対する複数の観察

観察条件カード

画面について結論を述べる前に、結論を左右しそうな条件だけを書きます。

人：初見か、既知か、使用言語、必要なら視覚・運動上の条件

課題：概要を知る、日程を探す、申し込む、監視する

道具：ビューポート、ズーム、入力方法、ブラウザの状態

環境：光、騒音、移動、時間制約、中断

毎回すべてを埋める必要はありません。「この条件が変わると結論も変わる」と考えられる項目を残します。

見えているものは、画面の中だけで決まらない

同じ画面でも、何をしようとしているかによって見つけるものは変わります。

文化祭のサイトを開いた人を考えます。開催日を知りたい人は、日付らしい数字やカレンダーのアイコンを探すかもしれません。出演を申し込みたい人は、「参加」「募集」「申込」といった言葉や、ボタンらしい形を探すでしょう。会場へ向かっている人は、住所や地図へのリンクを優先します。

画面の視覚的な構成が同じでも、利用者の目標によって注意の向け方は変わります。屋外の眩しい場所、小さな画面、通信中で画像がまだ届いていない状態でも、経験される画面は変わります。

したがって、「人間はこの順番で見る」と画面だけから断定することはできません。本書で「最初に見えやすい」「まとまりとして知覚されやすい」と書くときは、傾向や仮説を述べています。誰にでも必ず同じことが起こる、という意味ではありません。

さらに、見慣れた形式も判断へ影響します。下線をリンクの手がかりとして読むことや、右向きの三角形を再生操作と結びつけることは、形だけから必然的に決まるわけではありません。印刷物、OS、Web サービスを使う中で学んだ慣習が加わっています。読み方向、文字体系、地域、世代、利用してきた道具が変われば、同じ配置の読み方も変わりえます。

1.2 読む前に、ページの骨格は見えている

観察に使う最小の語彙

この章では、感覚的な言葉を捨てるのではなく、比較できる属性へ一度ほどきます。

感じたこと	観察の候補	記述例
まとまっている	距離、境界、似た形、反復	ラベルと入力欄の間隔は、次の項目までの間隔より狭い
密度が高い	一定面積内の文字・線・要素数、空白の連続	上半分には 5 つの情報群があり、下半分には 2 つある
強い	面積、背景との明度差、太さ、彩度、孤立、動き	告知は見出しより面積が大きく、周囲で唯一色面を持つ
流れがある	揃い、方向、反復、連続する間隔	三つの見出しの左端と間隔が揃い、縦方向の順序を示す

これらは厳密な測定用語ではありません。「強い」は初回注視や実際の閲覧順を意味しません。画面属性から立てる仮説と、観察者の主観報告と、行動や視線の測定結果は区別します。

どこまでを一要素、一領域と数えるかにも解釈が入ります。この表は、感覚を機械的に数値へ変換するものではありません。別の人が同じ箇所を指して話せるように、比較相手を探すための足場です。

文章を意味ではなく形として見る

Web ページを見ると、私たちはすぐに文章を読み始めます。内容を理解できることは重要ですが、デザインを観察するときには、それが邪魔になる場合もあります。

文章の意味を追っていると、次のような関係を見落としやすくなります。

見出しより補助情報の方が大きい
一つの説明だけ行長が極端に長い
関係する二つの情報の間に大きな空白がある
ページの上半分だけ密度が高い
同じ役割の項目が異なる幅を持つ

そこで、文字をいったん読まず、灰色の矩形として見ます。文字の一行を一本の長方形へ置き換えるように想像してください。太い見出しは太い矩形、短いラベルは短い矩形、段落は細い矩形の集まりです。

すると、言葉の意味より先に、量と配置の関係が見えてきます。

文字を読まずに矩形として見るを示す図。 — 図 1-2　文字を読まずに矩形として見る

矩形化して見えるもの

矩形化は、画面を分析するための一時的な観察法です。次のような問いに向いています。

文字量は、画面のどこへ集中しているか
見出しと本文の大きさには、識別できる差があるか
行長は、同じ種類の文章で揃っているか
情報の塊と塊の間には、どんな空間があるか
強い色面や画像は、文字の塊とどう釣り合っているか

一方、矩形化すると失われるものもあります。

書体の形、言葉の意味、文の難しさ、画像の主題、色の連想は観察できません。たとえば、同じ長さの二つの見出しでも、「本日中止」と「開催レポート」では、利用者にとっての重要度が違います。矩形化した画面だけを根拠に、情報の優先順位が正しいかどうかは決められません。

情報を減らす観察法は、画面の真実を見せるフィルターではありません。普段とは違う関係を見つけるために、観察条件を変える道具です。

矩形化の後は、必ず文字へ戻ります。字種、Weight、行間、改行位置、言葉の意味が、先ほど見た骨格へ何を加えたかをもう一度記録します。文字を形と声として観察する方法は、第7章で詳しく扱います。

1.3 ばらばらの刺激が、まとまりとして見える

知覚的組織化という問題

夜空の星は、一つひとつ離れています。それでも、いくつかの星を線で結んだ形として見ることがあります。途切れた輪郭から円を見たり、並んだ点から列を見たりすることもあります。

視覚系が、個々の刺激をまとまりや対象として構成することを、知覚的組織化と呼びます。

この問題を考えるうえで大きな影響を与えたのが、20 世紀初頭の欧州で展開し、その後の視知覚研究で検討・更新されてきたゲシュタルト心理学です。知覚経験を独立した感覚要素の寄せ集めとしてだけ説明せず、全体として成立する構造を研究しました。研究者名と原著は章末の参考資料に示します。

Web デザインの記事では、「ゲシュタルトの法則」として近接、類同、閉合などが一覧にされることがあります。本書でも、これらを後の章で扱います。ここでは、画面が要素の一覧ではなく、関係を持つ構造として見えることだけを押さえます。原則の競合と限界は 1.7 で確かめます。

知覚的なまとまりは、複数の手がかり、画面の内容、過去の経験、利用者の目標が関わって生まれます。「近接の法則に従ったから正しい」という使い方は、理論の説明としても、デザインの判断としても粗すぎます。

プレグナンツは「よいデザイン」の法則ではない

正確に知る――ここは後から読んでも構いません

次の説明は理論の射程を確かめるための発展部分です。章末の観察は、この用語を暗記しなくても行えます。

ゲシュタルト心理学に関係する用語として、プレグナンツの原理があります。

簡単に言えば、私たちの知覚経験は、与えられた条件のもとで、できるだけ安定した、まとまりのある構造として成立する傾向がある、という考え方です。

ただし、「単純なデザインほど優れている」「左右対称なら美しい」といったデザイン上の正解を示す原理ではありません。

ここで使われる「よい形」「よい組織」という表現の「よい」は、道徳的によい、使いやすい、美しいという意味ではありません。知覚上どのような組織が成立するかを論じるための歴史的な表現です。また、プレグナンツを精密に定義し、具体的な条件ごとに予測することの難しさも、後の研究で指摘されてきました。

この章では、プレグナンツを「画面を単純にするための法則」として使いません。画面にある刺激を私たちが受動的に写し取っているのではなく、構造を持つ経験として知覚している、という入口として扱います。

1.4 情報を減らすと、別の関係が見える

Web ページは多くの種類の情報を同時に伝えます。文章の意味、色、画像、形、位置、動きが重なるため、どの手がかりが画面の見え方へ影響しているかを分けにくくなります。

情報の一部を一時的に減らすと、観察しやすくなる関係があります。ここでは、グレースケール、ぼかし、シルエットという三つの方法を比べます。

通常、グレースケール、ぼかし、シルエットを示す図。 — 図 1-3　通常、グレースケール、ぼかし、シルエット

グレースケールで明度の関係を見る

色相と彩度を取り除き、明るさの差を中心に見る方法です。

たとえば、鮮やかな青と鮮やかな赤は、色としては明確に違って見えます。しかし、グレースケールにすると近い灰色になる場合があります。色の違いを取り除くことで、文字と背景の明度差や、色へ依存していた分類に気づけます。

ただし、グレースケールで区別しにくいからといって、元の画面でも必ず区別できないとは限りません。反対に、グレースケールで明度差があっても、文字サイズ、細さ、周辺の光、視覚特性などによって読みやすさは変わります。アクセシビリティの適合性を、この加工だけで判定することはできません。

ぼかして大きな強弱を見る

細部が読めない程度に画面をぼかすと、文字の意味や細い線が弱まり、大きな色面、画像、明暗、密集した領域が残ります。

これは、どの領域に大きな面積や明暗差が残るかを考える手がかりになります。主題より大きな告知面がある、行動を促す要素と背景の明暗差が小さい、といった観察から仮説を作れます。

ぼかした画面を、人の「実際の見え方」と呼ぶことはできません。ぼかしの量によって結果は変わりますし、低視力の状態を再現するものでもありません。あくまで細部を一時的に弱める観察法です。

シルエットで領域の形を見る

文字や画像の細部を取り除き、主な領域を少数の明度面へ置き換えます。すると、画面のどこが埋まり、どこが空いているか、要素の外形がどの方向へ連続しているかを見やすくなります。

シルエットでは、文章の意味も画像の主題も失われます。画像が画面の半分を占めていることは分かっても、その画像が人物なのか商品なのか、どちらを向いているのかは分かりません。

加工前の画面へ必ず戻る

どの方法にも、見えやすくなる関係と見えなくなる情報があります。

通常の画面で違和感を記録する
情報を一種類だけ減らす
何が見えやすくなり、何が失われたかを書く
通常の画面へ戻り、最初の違和感を説明できるか考える

加工結果だけでデザインを評価せず、通常の画面へ戻るところまでが一つの観察です。

加工条件も記録します。縮尺、グレースケールの変換方法、ぼかし半径、シルエットへ変換する規則が変われば、見える結果も変わります。これは人の見え方を測る検査ではなく、説明候補を見つけるための教育的な比較です。

1.5 DOM の木と、目に見える構造は一致しない

ブラウザは HTML を解析して Document を構築します。現在の DOM は、読み込み後もスクリプトなどによって変化しえます。CSS によるスタイル計算、レイアウト、描画を経て見えている表示は、DOM そのものではありません。

この木構造は、文書と実装を考えるために重要です。しかし、利用者が画面上で知覚するまとまりと同じものではありません。

HTML の親子関係と知覚されたまとまりを示す図。 — 図 1-4　HTML の親子関係と知覚されたまとまり

同じ親を持っていても、別々に見える

一つの section の中に、見出し、説明、申込ボタンが入っているとします。現在の DOM 上では、同じ親要素の子です。

ところが、見出しと説明の間が広く、説明と次のセクションの画像が近ければ、見出しだけが孤立し、説明は次の内容へ属して見えるかもしれません。同じ親に置かれていても、視覚上のまとまりは意図と異なります。

別の親を持っていても、一組に見える

反対に、コード上では別のコンポーネントに属する「残り 3 席」という表示と「申し込む」というボタンが、同じ色面の中で近く並んでいれば、一つの行動領域として見えるでしょう。

ここで、HTML と見た目のどちらかが常に正しい、という話ではありません。Web 画面には、少なくとも次の異なる層があります。

層	この章での見方
現在の DOM 上の関係	どの Node が親・子・兄弟として存在するか
HTML 要素と属性が表す意味	見出し、ボタン、ラベルなどを何として記述したか
CSS による視覚配置	距離、順序、重なり、表示・非表示がどう見えるか
支援技術へ公開される情報	ブラウザが名前、役割、状態、関係などをどう公開するか

これらの層は関係しますが、同じではありません。視覚的に整っていても、意味、名前、状態、操作順が適切とは限りません。反対に、意味上の構造があっても、見た人へ関係が伝わるとは限りません。

実装と接続する――ここは後から読んでも構いません

DOM 順、Accessibility Tree、読み上げ順、キーボードのフォーカス順は同じ概念ではありません。この章では、それらの挙動を一括して説明しません。Semantic HTML、CSS のレイアウト、支援技術との接続は、後の章で資料と実例を伴って扱います。

この章で覚えておきたいのは、DevTools で木構造を確認しても、人がどうまとめて見るかの答えにはならないことです。コードは重要な証拠ですが、画面を観察する仕事を代行しません。

1.6 観察と解釈と評価を書き分ける

「この画面は分かりにくい」という言葉には、複数の段階が混ざっています。

何が見えているのか。なぜそう見えると考えたのか。目的に照らして、どのように判断したのか。この三つを分けると、他の人と検討しやすくなります。

観察

画面上で比較できる属性を、証拠源とともに記述します。利用者の操作を記録する場合は、表示の記述とは別にします。

表示上の字面を比べると、告知バナーの文字はページ見出しより高い。告知だけが色面を持ち、見出しの背景には色面がない。

第三者が同じ条件で画面を見たとき、どこを指しているか確認できる書き方です。数値を測っていなくても、比較相手を示せます。

解釈

観察した差が、どのような意味を持つかの候補を書きます。

告知バナーがページの主題より先に注意を引き、何のサイトかを理解する前に告知を読ませる可能性がある。

解釈には不確実性があります。利用者が告知を探しているなら、先に注意を向けるかもしれません。色より言葉の意味が強く働く場合もあります。このため、「可能性がある」「別の説明も考えられる」と書きます。

評価

目的や条件に照らし、望ましいかどうかを判断します。

初めて来た人にイベントの内容を理解してもらうことがこのページの第一目的なら、告知が主題より強く見える構成は、その目的に合っていない。

評価には基準が必要です。告知を最優先で伝えるページなら、同じ構成を適切と評価する可能性があります。祝祭感を先に作るという表現意図に対しては、大きな色面が期待を作ると評価するかもしれません。「強く見える」という観察だけでは、よいか悪いかは決まりません。

表現意図は、評価を免れるための説明ではありません。意図した経験が受け手にも生じるか、情報到達や操作を不必要に妨げないかを検討する仮説になります。

観察、解釈、評価の書き分けを示す図。 — 図 1-5　観察、解釈、評価の書き分け

三つは完全に切り離せない

観察は、何の解釈も含まない純粋な記録ではありません。「告知バナー」と名付ける時点で、画面の役割を解釈しています。どこを観察するかも、知識や関心に影響されます。

それでも書き分ける価値はあります。事実のように述べた部分が推測だった、目的を共有しないまま評価だけが衝突していた、といった問題を見つけやすくなるからです。

この区別は、第19章でデザインレビューの方法として詳しく扱います。第1章では、まず文章の形を変えるだけで十分です。

「分かりにくい」ではなく、画面上の差を書く
原因を述べるときは、仮説であることを示す
よしあしを述べるときは、目的と利用状況を書く

1.7 ゲシュタルト原則だけで画面を説明できるか

知覚の原則を知ると、画面を見る言葉が増えます。一方で、見つけた用語だけですべてを説明したくなる危険もあります。

複数の手がかりは競合する

四つのカードが並んでいる画面を考えます。

左の二つと右の二つの間だけ距離が広い
一つ目と三つ目が青く、二つ目と四つ目が白い
上の二つだけ同じ背景面に入っている
一つ目と二つ目は「参加者向け」、三つ目と四つ目は「来場者向け」と書かれている

距離、色、背景、意味が、それぞれ異なるまとまりを示しています。「近いものを仲間と思う」という説明だけでは、どのまとまりが成立するか決められません。

ここから、一つの予測を作れます。色、背景、文言を固定したまま、左の二枚と右の二枚の間隔だけを広げると、左右の組として報告する人が増えるのではないか。これはまだ結果ではありません。F06 では、この変更前後を一差で比べ、距離以外の説明を残します。

複数のまとまり方が競合する画面を示す図。 — 図 1-6　複数のまとまり方が競合する画面

実際の Web 画面では、手がかりはもっと多くなります。位置、形、文字、画像、動き、操作後の反応、過去に使ったサイトの経験が重なります。

原則は目的を決めない

近接によって三つの項目が一組に見えるとしても、それが望ましいかどうかは、三つを一組として理解してほしいかによって変わります。

知覚心理学は、何が重要か、ブランドをどう表現したいか、誰へ何を伝えるべきかを決めてくれません。デザイン上の目的を決めた後で、その意図が画面上の手がかりへ翻訳されているかを考える助けになります。

原則は人間を直接見た結果ではない

画面を見て「近接の原則が原因だ」と説明しても、それだけで利用者が実際に取り違えると証明したことにはなりません。

まず、距離の関係を観察します。次に、取り違えが起こるかもしれないという仮説を作ります。比較画面を作り、必要なら実際の利用者の行動を見ます。

本書の中心にあるのは、この往復です。

画面を見る
違いを記述する
名前を手がかりに説明候補を作る
別の説明を残す
画面を変えて比べる
人間の行動で確かめる

名前を知ると、次から見つけられます。そして、名前を知ると、次から疑えます。

1.8 問い――内容を読まずに、何が見えるか

次の画面を二巡して観察します。最初の一巡では文章の内容を詳しく読まず、二巡目で内容と短いブリーフへ戻ります。

問い

画面はいくつのまとまりに見えますか。
周囲より面積、明暗差、太さ、孤立が大きい領域はどこですか。
どの方向の揃い、反復、間隔が順序を示していますか。
その判断には、距離、面積、明度、境界、文字の大きさのうち、何が関わっていますか。
デスクトップ表示とモバイル表示で、まとまり方は変わりますか。
まだ画面だけでは判断できないことは何ですか。
「最初に見つける」という仮説を確かめるなら、どんな課題と記録が必要ですか。
この画面で残したい、目的にかなった関係は何ですか。

一度、用語を使わずに書いてみてください。画面上の差を指せたら、それだけでも十分です。説明に使えそうな概念名があれば、後から候補として加えます。

答えの例――記録を三段階で育てる

1. 場所を指す

画面上部と、その下の大きな写真の領域が分かれて見える。写真の上には、周囲で唯一色面を持つ告知がある。

まず、どこを見ているかを第三者が指せるようにします。

2. 比較相手を足す

画面上部には、ロゴとナビゲーションからなる細長い領域があります。その下には大きな写真と見出しがあり、一つの主題領域に見えます。ただし、写真の上に置かれた告知だけが色面を持ち、主題から独立した領域にも見えます。

開催日と会場は文字サイズが近く、横に並んでいます。しかし、開催日と会場の間より、会場と申込ボタンの間が近いため、会場と申込が一組に見える可能性があります。

モバイル表示では写真と見出しの間に告知が入るため、デスクトップ表示より主題が分断されて見えます。一方、縦一列になることで、出演者カードの順序は追いやすくなっています。

ここでは、面積、間隔、色面、揃いという比較を足しています。実際の最終図では「デスクトップ表示」「モバイル表示」と表記し、同じ縮尺で見る全体比較と、同倍率で見る局所比較を分けます。

3. 仮説と条件を足す

この観察は、知覚的組織化という考え方から説明候補を作れます。ただし、どの領域を最初に見るかは、利用者の目的や文章の意味によっても変わります。

ここで述べた順序は視線計測の結果ではありません。表示上の手がかりから作った閲覧順の仮説です。確かめるなら、たとえば「初見の参加者が開催日を探す」という課題を定め、最初の選択、発見までの時間、迷い、発話など、何を記録するかを決めます。

残したい関係も書きます。出演者カードの左端と間隔の反復は、一覧を縦に追う手がかりになっています。告知を弱める変更を試す場合も、この反復まで崩す必要はありません。

別の答え方

この画面は、三つのまとまりではなく、上下に連続する一本の流れとして見ることもできます。各領域の左端が揃い、背景色の切替よりも垂直方向の整列が強い手がかりになっているからです。

また、告知を探してサイトを開いた人にとっては、告知が強いことは問題ではありません。画面の目的を「初見者へイベントを説明すること」と置くか、「変更情報を素早く伝えること」と置くかで、評価は変わります。

この考え方の注意点

何を「情報」と数え、どの関係を「ごちゃごちゃ」と感じたのかが分かりません。

情報の数が同じでも、まとまり、階層、利用者の知識によって見え方は変わります。次のように書き換えると、検討できる観察になります。

告知、開催情報、申込の三つが近い距離にあり、それぞれが異なる強い色を持つため、どこまでが一つのまとまりか判断しにくい。

この文にも解釈は含まれています。しかし、どの要素とどの差を見ているか、他の人が確認できます。

必須セルフチェック

内容の感想だけでなく、位置、距離、形、強さを記述したか
「何となく」感じたことを捨てず、画面上の手がかりへ結びつけたか
観察と原因の推測を分けたか
評価するときに、ページの目的と利用状況を置いたか

発展セルフチェック

一つの用語で説明を終えず、別のまとまり方を考えたか
加工した画面だけでなく、通常の画面へ戻ったか
文字と画像の意味へ戻したとき、最初の評価が変わらないか確かめたか
自分とは違う見え方がありうることを残したか

次章へ

この章では、画面がまとまりを持つ構造として知覚されることを見ました。次章では、その手がかりの一つである距離に焦点を絞ります。

「余白が足りない」という評価を、どの要素とどの要素の距離が、どの関係を表せていないのかという観察へ変えていきます。

参考資料

入口: ISO, “ISO 9241-11:2018.” Usability を利用の結果として捉え、利用状況を含めて考える規格の公式紹介です。本章では概要の箇条書きだけを読み、人・課題・道具・環境を考える入口にしてください。
入口: W3C Web Accessibility Initiative, “Images Tutorial.” 図版の目的に応じた代替テキストと、複雑な図の説明方法を確認する公式資料です。最初に冒頭の画像分類を読むと、本書の図版仕様と接続できます。
発展: Johan Wagemans et al., “A Century of Gestalt Psychology in Visual Perception I: Perceptual Grouping and Figure–Ground Organization,” 2012. 知覚的グルーピングと図と地を、後続研究を含めて整理した長いレビュー論文です。最初は “Introduction” と原則を図示した箇所を確認してください。
発展: Jeremy M. Wolfe and Todd S. Horowitz, “Five Factors that Guide Attention in Visual Search,” 2017. 視覚探索で注意を導く要因を整理したレビューです。画面属性だけで実際の探索順を決められないことを考えるために使います。
発展: Johan Wagemans et al., “A Century of Gestalt Psychology in Visual Perception II: Conceptual and Theoretical Foundations,” 2012. 理論的背景と限界を確認する論文です。プレグナンツの操作化の難しさを扱う箇所が本章に対応します。
発展: Baingio Pinna and Katia Deiana, “Prägnanz in visual perception,” 2024. プレグナンツの説明と知覚研究での扱いを確認する論文です。
原典: Max Wertheimer, “Untersuchungen zur Lehre von der Gestalt. II,” 1923. 古典的原著です。ドイツ語で難度が高いため、現代のレビューを読んだ後に図と例を中心に確認してください。
公式仕様: WHATWG, “HTML Standard.” HTML parsing と Document の構築を確認する仕様です。
公式仕様: WHATWG, “DOM Standard.” Node、Tree、Document の関係を定義する仕様です。「1.1 Trees」と「4.1 Introduction to ‘The DOM’」が本章に対応します。

検索キーワード：知覚的組織化、ゲシュタルト心理学、perceptual organization、Gestalt grouping、Prägnanz、visual search task guidance

第2章　人間は、近いものを仲間だと思う

フォームを見て、「余白が足りない」と感じることがあります。では、どこの余白が、何に対して足りないのでしょうか。

すべての間隔を広げても、読みやすくなるとは限りません。ラベルと入力欄の間まで広げれば、どのラベルがどの入力欄へ対応するのか、かえって分かりにくくなることがあります。反対に、画面全体を詰めても、関係する要素同士と、次のまとまりまでの距離に十分な差があれば、構造は見える場合があります。

距離は、空いている場所の量ではありません。要素同士の関係を画面へ表す手がかりです。

この章では、「広い」「狭い」という絶対的な評価から離れます。何と何の距離を比べ、その差がどの関係を表しているかを観察します。読み終えたとき、次のように説明できることを目指します。

ラベルと対応する入力欄の距離より、入力欄と次のラベルの距離が狭いため、項目の境界が曖昧に見える。

この章の必修は三つです。

何と何の距離かを指す
まとまり内部と、次のまとまりまでの距離を比べる
目的と状態を置き、一つの変更仮説を書く

CSS の詳しい挙動、スペーシングスケール、空白の表現性は発展です。そこを後から読んでも、章末の基礎課題へ取り組めます。

この章で見るもの

小さな間隔が、どの要素を一組にしているか

まとまり内部とまとまり間に、区別できる距離差があるか

距離と、ボーダー、背景、色、形、文言が同じ関係を示しているか

margin、padding、gap の値が、画面上のどの関係から決まったか

スペーシングスケールの候補が、目的に合う距離を表現できるか

2.1 列に並ぶ人は、どこまでが同じ組か

駅のホームに 8 人が並んでいます。全員の間隔がほぼ同じなら、一本の列に見えるでしょう。2 人ずつの間隔だけが狭ければ、4 組が並んでいるように見えます。左の 4 人と右の 4 人の間だけが広ければ、二つの集団に見えるかもしれません。

人の服装も姿勢も変えず、間隔だけを変えても、見えるまとまりは変わります。

ここで大切なのは、何 cm なら一組に見えるかではありません。同じ画面内で、どの間隔が他より小さく、どこで間隔の関係が変わるかです。

たとえば、隣り合う距離が次のようになっているとします。

人  8  人  24  人  8  人  24  人  8  人

8 という小さな間隔と 24 という大きな間隔が反復すれば、小さい間隔で結ばれた人同士が一組として見えやすくなります。8 という数値自体がまとまりを作るのではありません。周囲の 24 との関係が、まとまりの手がかりになります。

距離だけで関係は決まらない

近くに立つ 2 人が、互いに背を向け、別々のまとまりへ話しかけていたらどうでしょうか。距離は一組を示し、身体の向きや会話は別のまとまりを示します。

日常の場面では、距離だけでなく次の手がかりが重なります。

同じ方向を向いている
同じ服装や名札を持つ
同じ机や囲いの中にいる
会話や作業を共有している
同じ列へ並ぶという状況を知っている

Web 画面でも同じです。近さは有力な手がかりですが、色、形、境界、整列、言葉の意味、操作結果と競合します。

この章では、まず距離だけを変えた比較で働きを見ます。その後で、他の手がかりが加わる画面へ戻ります。

2.2 フォームで、対応が曖昧に見えるとき

フォームは、距離による関係が現れやすい場所です。

距離を動かす前の三つの問い

数値を試す前に、情報構造と失敗の影響を確認します。

利用者は、どこからどこまでを一つの入力単位として扱うか
どの順番で探し、読み、入力し、修正するか
誤って一組に見えた場合、どんな間違いや損失が起こるか

たとえば病院予約で、診療科、希望日、連絡先の対応を誤れば、予約内容の訂正や再入力が必要になり、受診手続きが遅れるかもしれません。一方、アンケートでも、回答内容や利用目的によっては誤入力の影響が大きくなります。画面の種類だけで重大さを決めず、具体的な失敗場面を置いて距離案の優先順位を考えます。

氏名のラベル、その入力欄、Email のラベル、その入力欄が縦に並んでいるとします。画面上には、少なくとも二種類の距離があります。

ラベルと対応する入力欄の距離
入力欄と次のラベルの距離

この二つが同じなら、すべての要素が均等な列に見えます。どこからどこまでが一項目かは、言葉を読まなければ分かりにくくなります。

ラベルと入力欄の距離より、次のラベルまでの距離が大きければ、一項目の境界を距離でも示せます。

フォームの距離を一つずつ変えるを示す図。 — 図 2-3　フォームの距離を一つずつ変える

良い例と悪い例の二択にしない

比較図では、ラベル―入力欄間を 8、12、16、20、24 と段階的に変えます。次の項目までの距離は固定します。

8 なら正解、24 なら不正解、と覚えるためではありません。どのあたりから対応関係が曖昧に感じられるか、その変化を自分で観察するためです。図 F03 では、注釈のないフォームを先に観察し、その後で意味上のまとまりを重ねます。ラベル―入力欄間だけを変える系列と、項目間だけを変える系列も分けます。

境界が急に切り替わるとは限りません。はっきり一組に見える条件と、はっきり分離して見える条件の間には、判断の割れる中間があります。文字の大きさ、入力欄のボーダー、画面幅、利用者の経験が変われば、中間の見え方も変わります。

エラーメッセージが入ると、距離関係も変わる

通常状態では、ラベルと入力欄が近く見えていたとします。入力後にエラーメッセージが現れると、入力欄と次のラベルの間へ新しい要素が入ります。

エラーメッセージが入力欄から遠く、次のラベルへ近ければ、どの項目のエラーか分かりにくくなる可能性があります。これは表示上の距離から立てた仮説であり、実際の取り違えを観察した結果ではありません。長いエラー文で折り返しが増えれば、項目全体の高さも変わります。

通常状態だけを見て決めた距離は、状態が変わると別の関係になります。Web の距離設計では、次の状態も確認します。

フォーカスインジケーターが現れた状態
エラーメッセージが 1 行または複数行ある状態
Optional／Required の説明が加わる状態
長いラベルへ翻訳された状態
200% ズームで折り返した状態
狭いビューポートで一列へリフローした状態

確認するときは、何を合格とするかも書きます。文字が欠けない。ラベル、説明、エラーが対応する入力欄の近くに見え、プログラム上の関係も正しく伝わる。フォーカスインジケーターが切れない。長文が重ならない。意図しない二次元スクロールを要求しない。これらを検証条件ごとに記録します。

視覚的な近さと、コード上の関連は別である

ラベルを入力欄の近くへ置いても、それだけでプログラム上の関連は作られません。HTML では label 要素とフォームコントロールを関連づけます。ラジオボタンやチェックボックスの集合には、共通の問いを伝える代表的な方法として fieldset と legend があります。すべての視覚的なまとまりへ fieldset を使うわけではありません。

説明文やエラーメッセージは、見える位置だけでなく、どの入力欄の説明・状態なのかを支援技術へ伝える必要があります。aria-describedby や aria-invalid が使われる場合もありますが、属性名を付ければ自動的に解決するわけではありません。表示する時機、読み上げ順、動的な通知、フォーカスの移動、修正後の状態まで検証画面で確認します。

視覚的な距離、Accessible Name、説明、まとまり、状態通知は、別々の証拠として確認します。

反対に、コード上で関連があっても、視覚的な距離が意図と逆なら、画面を見ている人にはまとまりが伝わりにくいことがあります。

見た目のまとまりと、意味上のまとまりは同じではありません。両方が、それぞれの方法で関係を伝える必要があります。

2.3 近接の原則――近さがまとまりを作る

第1章では、ばらばらの刺激がまとまりとして知覚されることを扱いました。その知覚的グルーピングの手がかりの一つが、近接です。

簡単に言えば、近いもの同士は同じまとまりとして知覚されやすい、という傾向です。

点列で見る Factor of Proximityを示す図。 — 図 2-2　点列で見る Factor of Proximity

点の大きさ、形、色を同じにし、水平方向の間隔だけを小さくすると、横の組が見えやすくなります。垂直方向の間隔だけを小さくすると、縦の列が見えやすくなります。

Max Wertheimer が 1923 年に示した古典的な例でも、間隔の小さい要素同士がまとまりとして組織される Factor of Proximity が論じられています。

「近い」を絶対値だけで定義しない

この説明から、「要素同士を 8px 以内に置けばまとまりになる」と結論づけることはできません。

近さは、配置全体の中での関係です。8px が小さく見えるかどうかは、周囲の距離、文字サイズ、要素の面積、画面のズーム、境界、背景などによって変わります。

二つの距離を考えます。

ラベル ─ 12 ─ 入力欄 ─ 16 ─ 次のラベル

12 と 16 の差は小さいため、対応関係が十分に分かれないかもしれません。

ラベル ─ 12 ─ 入力欄 ─ 36 ─ 次のラベル

ラベル―入力欄の距離は同じ 12 ですが、次項目までの距離との差は大きくなりました。この画面では、一項目の境界が見えやすくなる可能性があります。

ここから作れる仮説は、「12px が正しい」ではありません。

ラベル―入力欄間を固定し、項目間だけを広げると、対応するラベルと入力欄を一組として報告する人が増えるのではないか。

実際にそうなるかは、比較と人の行動で確かめます。

数値の読み方

本章の 8、12、24 などは比較条件であり、推奨値ではありません。CSS px は物理 px でも、見る人の視角でも、知覚された距離でもありません。フォーム図では、ラベルの行ボックス下端から入力欄のボーダー上端までを基本の測定区間とし、CSS ボックスの距離と、文字の形から感じる見かけの距離を区別します。ズーム、ビューポート、フォント、表示密度も記録し、同じ条件内の比較として使います。

原則は設計目的を決めない

近接の原則は、何を一組にすべきかを教えません。

住所の郵便番号と都道府県を一組に見せるか。カードのタイトルとカテゴリーを一組に見せるか。ナビゲーションで「製品」と「料金」を近づけるか。それは情報の意味、利用者の目的、業務上の手順によって決めます。

目的を決めた後で、距離がその関係を支えているかを見る。その順序が必要です。

2.4 「余白を増やす」から「関係を距離へ変換する」へ

「余白を増やしてください」というレビューは、変更量を伝えているようで、設計理由を伝えていません。

余白を、関係の種類へ分けます。

コンポーネント内部の距離

ボタンの文字と外形の間、カードの端と内容の間など、一つのコンポーネント内部にある距離です。内容を囲む形、操作領域、密度、調子に関わります。

要素間の距離

タイトルとメタ情報、アイコンとラベル、ナビゲーション項目同士など、並ぶ要素の関係を示します。

まとまり間の距離

一つのフォーム項目と次の項目、カード群と次のセクション、ヘッダーと主内容など、意味上のまとまりを分ける距離です。

内部余白、要素間隔、まとまり間隔を示す図。 — 図 2-4　内部余白、要素間隔、まとまり間隔

同じ 16px でも、ボタン内部にある場合と、セクション間にある場合では役割が違います。数値が揃っていることと、関係が適切に見えることは同じではありません。

異なる関係を距離で区別する

画面を作る前に、情報同士の関係を言葉で書きます。

氏名ラベル と 氏名入力欄：直接対応する
氏名入力欄 と エラー：同じ項目の状態を説明する
氏名項目 と Email項目：同じForm内だが別の入力単位
個人情報まとまり と 支払情報まとまり：目的の異なる大きなまとまり

この関係の違いを、距離だけでなく、見出し、境界、背景、HTML の意味構造へ表します。距離は関係を示す手がかりの一つであり、あらゆる関係を一つの大小順へ変換するものではありません。

距離は「関係が強いほど小さく、弱いほど大きい」という一方向の規則ではありません。操作対象同士が近すぎれば誤操作が起きることがあります。密接な情報でも、読みやすい行間やタッチターゲット間隔が必要です。距離は、意味、操作、安全、表現の複数条件を調整した結果です。

空白の形を見る

発展――ここからは近接の原則だけでは説明しきれません

空白には量だけでなく、形があります。

空白の輪郭、縦横比、方向、連続、分断、重心を観察します。主題の周囲へ連続した空間を置くと静けさを感じる場合がありますが、この解釈は普遍的ではありません。情報を狭い領域へ集めた構成が速報的に読まれるかどうかも、媒体、文化、Genre、Typography、色、画像、Brand の慣習によって変わります。

Negative Space が作る形と調子を示す図。 — 図 2-5　Negative Space が作る形と調子

F05 では、同じ目的と素材から作った方向性の異なる案を比べます。一変数実験とは呼びません。各案について、意図、画面で観察できる構成、副作用、別の読みを記録します。空白を機能上の分離だけで評価せず、表現意図と受け手の経験へ戻ります。

距離案のトレードオフを決める条件

条件	確認すること
目的	探す、比較する、入力する、監視するのどれか
失敗時の影響	誤対応が不便、損失、安全問題のどれにつながるか
利用頻度と熟練度	初見中心か、反復する業務か
道具と環境	タッチ、キーボード、ズーム、移動、時間圧があるか
内容変動	エラー、翻訳、長文、動的追加があるか
表現	維持したい密度、速度感、静けさ、Brand らしさは何か

病院予約と文化祭一覧へ同じ距離案を適用しないのは、好みが違うからだけではありません。誤りの影響、課題、利用頻度、内容変動が違うからです。ただし、どちらが常に高リスクかは画面名から決まりません。想定する人、行動、失敗、その結果まで書いて比較します。

2.5 カード、ナビゲーション、一覧で距離を読む

同じ距離値でも、置かれた文脈によって意味が変わります。

カード、ナビゲーション、一覧の同じ 16pxを示す図。 — 図 2-6　カード、ナビゲーション、一覧の同じ 16px

カード内部

カードの Title と補助情報の 16px は、内容の階層を分ける距離かもしれません。ボーダーや背景がカード全体を囲んでいれば、内部の距離が多少大きくても一つのカードとして見えます。

データテーブル

テーブル行内の 16px は、情報密度と走査のしやすさに関わります。業務ダッシュボードでは、高密度でも列の揃いと意味が明確なら、目的に合う場合があります。

「16px だから同じ余白」とまとめることはできません。何と何の距離で、周囲にどんな境界や反復があり、利用者が何をしようとしているかを見ます。

ボーダーを加えたら、距離の意味も変わる

カードにボーダーを加えると、カード間の距離が小さくても境界は見えやすくなります。ナビゲーション Item に区切り線を加えると、近さによる一続きの関係が弱くなる場合があります。

距離とボーダーを同時に変えると、どちらが見え方を変えたのか分かりません。比較するときは、まず距離だけ、次にボーダーだけを変えます。実際の設計案を評価するときは、最後に全体を戻して見ます。

2.6 `margin`、`padding`、`gap` は何を表現しているか

実装と接続する――章末の基礎課題の後に読んでも構いません

画面上で必要な距離を判断した後で、CSS の構造へ接続します。

CSS ボックスモデルでは、内容領域の周囲に余白、ボーダー、マージンの領域があります。gap は Grid、Flex、段組みレイアウトで、ボックス間の溝を指定します。行／列という語が単純な上下／左右を表すとは限らず、レイアウト方式や書字方向によって軸が変わります。

margin、padding、gap の出所を示す図。 — 図 2-7　margin、padding、gap の出所

Property 名から設計理由を決めない

初学者向けには、次のように説明されることがあります。

padding は内側の余白
margin は外側の余白
gap は並んだ要素の間隔

Box の位置関係を理解する入口としては便利です。しかし、画面上の関係をどの Property へ持たせるかは、内側／外側だけでは決まりません。

同じ見た目の距離を、親の gap でも、子の margin-block-start でも作れる場合があります。どちらを使うかは、距離を誰が所有するか、要素の順序や数が変わるか、例外をどう扱うかによって判断します。

`gap` が向く場合

同じ Container に並ぶ Sibling の間隔を、親がまとめて管理したい場合です。項目が増減しても、先頭や末尾に不要な外側 Margin を作らずに済みます。

ただし、すべての兄弟要素間が同じ関係とは限りません。フォーム内で、ラベル―入力欄と項目間へ同じ gap を適用すれば、関係の差を表現できません。必要ならコンテナを意味まとまりごとに分けます。

`margin` が向く場合

要素が、自分より前後の内容との距離を持つ設計もあります。Typography の Flow や、特定要素の前だけセクション Gap を作る場合です。

ブロック方向の流れでは、隣接するマージンが、整形文脈、親子関係、回り込み解除などの条件によって相殺される場合があります。指定した二つのマージンが単純に足されるとは限りません。図では指定値、相殺が起きる条件、画面で観察されるボーダー端間の距離を分けます。

`padding` が向く場合

内容とボーダー／背景の間隔を作り、コンポーネントの内部領域を定義する場合です。ボタンでは見た目の空間だけでなく、操作領域にも関わります。

ただし、padding を増やせば常に操作しやすいとは限りません。隣の Target との距離、折り返し、ビューポート、入力方法も確認します。操作対象の大きさは第14章で詳しく扱います。

Logical Properties で方向を固定しない

margin-left や padding-top のような Physical Property だけで考えると、Writing Mode や Text Direction が変わったときに、意図した関係と実装がずれることがあります。

margin-inline-start や padding-block などの Logical Property を使うと、Inline／Block 方向を基準に距離を表せます。これは Direction や Writing Mode が変わっても、関係の意図を保ちやすくする一手段です。国際化全体を保証するものではありません。Flex／Grid の配置、方向を持つ Icon、双方向 Text、DOM 順、フォーカス順も別々に確認します。

画面から CSS へ進む順序

何と何が一つの関係かを書く
内部、要素間、まとまり間の距離を比べる
状態とビューポートを変えても関係が保たれるか見る
HTML の意味構造と Container を決める
gap、margin、padding などへ責任を割り当てる
ブラウザで幅、ズーム、内容、状態を変えて確かめる

CSS の値から画面を決めるのではなく、画面で表したい関係から CSS へ進みます。

2.7 スペーシングスケールは判断を代行しない

発展――デザインシステムへ接続する

画面ごとに 13px、17px、29px と、その場で距離を決め続けると、似た関係へ異なる値が増えます。変更時には、どの値が同じ役割か分からなくなります。

そこで、利用できる距離の候補を限定したスペーシングスケールが使われます。

4, 8, 12, 16, 24, 32, 48

この列は一例です。4px 刻み、8px 刻み、倍数列、等比に近い列、ビューポートに応じて変わる流動的なトークンなど、さまざまな設計があります。

スペーシングスケールの粗さと柔軟さを示す図。 — 図 2-8　スペーシングスケールの粗さと柔軟さ

Scale が助けること

似た関係へ同じ候補を使いやすくする
デザインとコードで値を共有しやすくする
全体の密度をまとめて調整しやすくする
例外や未整理の値を見つけやすくする

Scale が決めてくれないこと

どの要素を一つのまとまりにするか
どの関係にどの段階を使うか
Typography や画像との釣り合い
タッチターゲットやエラー表示の条件
Brand らしい空白の調子
狭いビューポートで距離をどう変えるか

「8px Grid を使っているから正しい」とは言えません。8 という基準は、関係の意味も、読みやすさも、アクセシビリティも保証しません。

Scale が粗すぎる場合

候補が 4、8、16、32、64 だけなら、16 では近すぎ、32 では遠すぎる関係が出るかもしれません。例外を許さなければ、Scale へ画面を合わせることになります。

Scale が細かすぎる場合

4、6、8、10、12、14、16 と細かく用意すると、ほとんど自由値と同じになり、選択理由を共有しにくくなります。

Scale の設計は、候補数、表現幅、例外、変更容易性のトレードオフです。実際の画面を作り、必要な関係を表現できるか確かめながら調整します。

トークンの層にも判断が現れる

space-3 のような基礎トークンを、form-field-gap のような意味トークンから参照し、必要なら booking-form-field-gap のようなコンポーネント固有トークンへ閉じる設計があります。意味名なら常に優れるのではありません。変更をどこまで波及させ、どこへ閉じ込めるかで層を選びます。詳細は第4章と用語集へ送ります。

2.8 距離と競合する別の手がかり

距離だけを整えても、別の手がかりが逆の関係を示していれば、意図したまとまりは伝わらないことがあります。

共通領域

離れた二つの要素でも、同じボーダーや背景で囲まれると、一つの領域に属して見えることがあります。

類同

近くに異なる色の要素が並び、離れた場所に同じ色や形の要素があると、似たもの同士のまとまりが見える場合があります。類同は第4章で詳しく扱います。

連結

線や面で物理的につながって見える要素は、一つの構造として知覚される場合があります。

文言の意味

「開催日」と日付、「会場」と住所のように、言葉の意味が強い対応を作ります。距離を見やすく整えても、ラベルの文言が曖昧なら関係は理解できません。

どの原則が一番強いかを暗記しない

共通領域は近接より強い、連結はさらに強い、と固定順位を覚えることが目的ではありません。どの手がかりが働くかは、刺激条件、課題、過去の経験によって変わります。

画面では、次の順で観察します。

距離だけを見る
境界、背景、色、形、連結を見る
文言と情報の意味へ戻る
手がかりが同じ関係を示しているか書く
競合する場合、どちらを優先してほしいか目的へ戻る
一つだけ変えた比較を作る

たとえば、距離を固定したまま共通の囲みだけを加えます。

囲みを加えると、囲みの中を一組として報告する人が増えるのではないか。

この仮説を比較画面で確かめます。結果が予想と違えば、「近接の原則に反した」と人を評価するのではなく、他の手がかりや課題を調べます。

2.9 問い――どの距離が、どの関係を壊しているか

まず病院予約フォームを観察します。カード一覧は発展課題として分けます。

章末統合課題――フォームとカードを示す図。 — 図 2-10　章末統合課題――フォームとカード

観察条件

ケース A　病院予約フォーム

人：この病院を初めて利用する人
課題：診療科、希望日、連絡先を入力して予約する
道具：幅 390px の画面、タッチ入力、200% ズームも確認する
状態：通常、フォーカス、エラーメッセージ表示

基礎の問い

どの二つの距離を比べると、項目の境界を説明できますか。
「余白が足りない」を、比較相手を含む文へ書き換えてください。
一つだけ変えるなら、どの距離を変え、何が変わると予想しますか。
エラー状態で、距離、意味上の関連、操作の何を確認しますか。

答えの例――6 段階で書く

1. 場所を指す（問い 1）

病院予約フォームでは、「希望日」の入力欄と、その下の「連絡先」ラベルが近く見えます。

2. 距離を比較する（問い 1・2）

「希望日」ラベルと対応する入力欄の距離より、入力欄と次の「連絡先」ラベルの距離が小さくなっています。項目内部と項目間の距離関係が逆です。

3. 概念を候補として加える（問い 2）

近接による知覚的グルーピングから考えると、「連絡先」ラベルが上の入力欄へ属して見える可能性があります。用語を使わなくても、二つの距離を指せていれば観察は成立します。

4. 別の要因を残す（問い 4）

一方、入力欄の上にラベルを置くという慣習や、ラベルの文言から対応を理解できる可能性もあります。エラーメッセージのボーダーと色が、別のまとまりを作っているかもしれません。

5. 変更仮説を作る（問い 3）

ラベル―入力欄間を固定し、項目間だけを広げると、各項目の境界を判断しやすくなるのではないか。ただし、フォーム全体が長くなり、スクロール量が増える可能性があります。

6. 確かめ方を書く（問い 4）

二つの評価を分けます。知覚の比較では「どこからどこまでを一項目として見たか」というまとまりの報告を主要指標にします。入力課題では、ラベルと入力欄の誤対応や入力誤りを主要指標にし、停止、戻り、エラー修正、完了時間を補助指標として記録します。見た印象と課題成績を一つの結果へまとめません。提示順を入れ替え、前の案を見た影響も記録します。一人の結果を一般化せず、対象者、課題、環境、試行順まで含めて解釈します。

表示条件も一つの「ズーム」にまとめません。ビューポート幅は 1280、390、320 CSS px、ブラウザズームは 100%、200%、400%、文字サイズ変更は 100%、200%、入力方法はマウス、タッチ、キーボードという別の軸として記録します。全組み合わせを機械的に試すのではなく、折り返し、横スクロール、操作順の崩れが起きそうな条件を選びます。WCAG の文字サイズ変更とリフローは、それぞれの達成基準の条件に沿って別に確認します。

発展課題――カード一覧へ移す

人：出演内容を比較したい来場者
課題：興味のある出演者を見つけ、詳細へ進む
道具：デスクトップ表示とモバイル表示
状態：通常と長い Title。画像未読込は第22章の可変状態で再訪する

次の三点だけを考えます。

カード内部、カード間、セクション間のうち、どの距離を比較するか
距離とボーダーが同じ境界を示しているか
変えずに残したい反復や揃いは何か

発展課題の答えの例

カード同士の距離が小さくても、各カードに明確な背景とボーダーがあれば、境界は見えます。距離を広げるより、カード内部の Title と出演時刻を近づけ、カード間の反復を保つ方が、比較しやすくなるかもしれません。

長いタイトルでカードの高さが変わる場合、縦方向の距離だけでなく、ボタン位置の揃いも関わります。この問題は近接だけでは説明できません。第3章の整列、第4章の類同も説明候補になります。

よくある考え方

余白が足りないので、全体的に 16px 増やします。

この考え方の注意点

どの距離が、どの関係に対して不足しているのかが分かりません。すべてを同じだけ広げれば、対応する要素同士まで離れます。画面が長くなり、比較もしにくくなるかもしれません。

次のように、距離の対象と予想を書くと検討できます。

カード内部の Title―時刻間は 8px ですが、カード間も 8px です。カード内部を固定し、カード間だけを 24px へ変えると、各出演者の境界が見つけやすくなるのではないか。

24px は答えではなく、比較案の一つです。ボーダーを加える、背景を変える、カード構造を見直すという別案もあります。

必須セルフチェック

何と何の距離かを指したか
まとまり内部と、次のまとまりまでの距離を比べたか
目的と状態を置き、一つの変更と予想される結果を書いたか

発展セルフチェック

ボーダー、背景、類同、連結、文言との競合を見たか
通常、フォーカス、エラー、長文、ズーム、リフローを確認したか
視覚的まとまりと HTML 上の関係を別々に確認したか
スペーシングスケールの候補へ画面を無理に合わせていないか
機能上の分離だけでなく、空白の形と表現意図を見たか
変えずに残すべき関係を書いたか

次章へ

距離は、要素同士の関係を見せる手がかりです。しかし、縦に並ぶ要素の左端が少しずつずれていれば、距離が整っていても流れは途切れて見えることがあります。

次章では、画面上に描かれていない基準線を探します。左端、右端、中央、文字のベースラインが、どのように連続と秩序を作るかを見ていきます。

参考資料

入口: York University, “Max Wertheimer, Laws of Organization in Perceptual Forms（英訳）.” 1923 年の原著の英訳です。“The Factor of Proximity”の点列例が本章に対応します。英語ですが、図と該当見出しから読めます。
発展: Johan Wagemans et al., “A Century of Gestalt Psychology in Visual Perception I,” 2012. 近接を含む知覚的グルーピングと後続研究を整理したレビュー論文です。まとまり ing Principles の図と説明から読むとよいでしょう。
原典: Max Wertheimer, “Untersuchungen zur Lehre von der Gestalt. II,” 1923. ドイツ語の原著です。英訳と図を照合するための資料です。
発展: Stephen E. Palmer, “Common region: A new principle of perceptual grouping,” 1992. 共通領域が近接とは別のまとまり手がかりになることを調べた論文です。
公式資料: W3C Web Accessibility Initiative, “Grouping Controls.” 関連するフォームコントロールを視覚的にもコード上でもまとめる例を示す資料です。
公式資料: W3C, “CSS Box Model Module Level 3.” 内容、余白、ボーダー、マージンの領域とプロパティを定義する仕様です。まず“2 The CSS Box Model”を確認してください。
公式資料: W3C, “CSS Box Alignment Module Level 3: Gaps Between Boxes.” gap が Flex、Grid 等の Box 間隔へどう適用されるかを確認する仕様です。
公式資料: W3C Web Accessibility Initiative, “エラー Identification.” 入力エラーを特定し、文字で説明する達成基準の解説です。距離だけでエラー通知が成立するとは考えません。
公式資料: W3C Web Accessibility Initiative, “User Notifications.” フォームの成功、エラー、進行状況を通知する実装例への入口です。
公式資料: W3C, “CSS Logical Properties and Values Level 1.” 物理方向ではなく、ブロック／インライン方向で余白を指定する仕様です。
公式例: U.S. Web Design System, “Spacing units,” GOV.UK Design System, “Spacing.” 異なるスペーシング尺度の実例です。心理学的な正解の根拠には使いません。
公式資料: W3C Web Accessibility Initiative, “Resize Text” と “Reflow.” 文字サイズ変更とリフローを別の条件として確認する資料です。

検索キーワード：近接の原則、知覚的グルーピング、factor of proximity、perceptual grouping proximity、common region grouping、CSS box model gap

第3章　人間は、揃ったものに線を見る

ページを見て、「少しガタついている」「なんとなく落ち着かない」と感じることがあります。その違和感を、すぐに「1 px ずれている」と決めつける必要はありません。

まず、どの要素が、どの基準を共有しているように見えるかを探します。文字の左端でしょうか。カードの外形でしょうか。数値の右端でしょうか。アイコンの中心でしょうか。それとも文字のベースラインでしょうか。

画面には、CSS で描かれていない基準が多数あります。要素の端や中心が反復すると、それらを構成上の軸として読める場合があります。本章では便宜上、この軸を「見えない線」と呼びます。ただし、観察者が分析のために引く補助線や、良い連続で知覚される輪郭とは区別します。幾何学的に揃っていることと、揃って見えることも分けます。

この章の必修は三つです。

どの要素の、どの基準が共有されているかを指す
物理的なずれ、ずれの知覚、課題への影響を分ける
幾何学的な基準案と形態に応じた調整案を比較する

この章で見るもの

左端、右端、中心、ベースラインのどれが共有されているか

見えない線がどこで始まり、どこで途切れるか

CSS の Box、Font Metrics、実際の文字の輪郭がどう異なるか

ずれが意図された例外か、偶発的な差か

目測した線と Grid／Flexbox の構造が一致するか

3.1 石畳、棚、文章に見える線

石畳の左端が連続していると、目地が一本の線のように見えます。書棚で高さの違う本が並んでいても、背表紙の下端が揃っていれば、棚板に沿った水平線を感じます。丸い皿が等間隔に置かれていれば、輪郭ではなく中心を結ぶ線が見えることもあります。

文章にも線があります。左横書きの段落では、行頭が反復して左端の線を作ります。すべての行へ縦線が描かれていなくても、文字の始まる位置から基準を見つけられます。

図 F01 は、最初に Overlay なしで見ます。自分ならどこへ線を引くか考えてから、解説面を開いてください。

ここで見つける線は、物体として存在する線とは限りません。要素配置が共有する構成軸を、観察者が分析用の補助線として書き表したものです。後で扱う良い連続の知覚された輪郭とは同じではありません。別の人が別の構成軸を見つける場合もあります。皿の左端を見る人もいれば、中心を見る人もいるでしょう。

重要なのは、模範線を当てることではありません。

私は、どの要素の、どの部分を結んで線を見たのか。

この問いに答えることが、画面の整列を見る入口です。

3.2 Web ページを支える見えない基準線

Web ページでは、多数の要素が一つの画面に並びます。見出し、本文、画像、カード、ボタン、ナビゲーション、時刻、価格。すべてを同じ線へ揃えることはできませんし、その必要もありません。

まず、基準線の種類を分けます。

左端

見出し、本文、リスト、カード内の文章など、読み始める位置が反復して作る線です。左横書きでは、次に読む位置を戻りながら探す手がかりになります。

ただし、文字の左端と、カードのボーダー左端は同じものではありません。カードに内部余白があれば、外形の線と内容の線が並行して存在します。

右端

価格、時刻、桁の揃った数値、操作ボタンの列などで現れます。数値を比較する画面では、右端だけでなく小数点や位を揃える方が課題に合う場合があります。

中心

アイコン、アバター、短いラベル、対称的な部品で使われます。しかし、Bounding Box の中心と、形が中央に見える位置は同じとは限りません。

ベースライン

文字が並ぶ基準の一つです。異なる大きさの文字、数字、アイコンが横に並ぶとき、Box の上下中央を一致させるより、文字のベースラインを共有した方が一行として見える場合があります。

Web ページの基準線を探すを示す図。 — 図 3-2　Web ページの基準線を探す

「この画面は揃っている」という言い方だけでは、観察した場所が分かりません。次のように書き換えます。

セクション見出し、導入文、カード一覧の外形は左端を共有している。カード内部の文字は、カード外形から一定の内部余白を置いた別の左端を共有している。

線は一本とは限りません。大きな構成の線と、コンポーネント内部の線が入れ子になります。どの線へ何を所属させるかが、情報構造を画面へ表します。

先に読む順序を置く

整列案を選ぶ前に、利用者の課題を置きます。

長い文章を上から読む
複数の価格を比較する
時刻から出演者を探す
一覧から操作ボタンを見つける
画像を手がかりに項目を選ぶ

同じ要素でも、読む課題が違えば有効な基準は変わります。価格比較なら位や右端が重要かもしれません。文章を連続して読むなら、安定した行頭が重要かもしれません。整列は、見た目を几帳面にする作業ではなく、関係と課題に合わせて基準を選ぶ設計です。

図 F02 の同じデータを、二つの課題で見比べます。出演者名から探す条件では名前の行頭を揃え、開始時刻から探す条件では時刻の桁と右端を揃えます。色、文字、項目数は固定します。どちらが普遍的に優れるかではなく、課題によって観察すべき基準が変わることを確かめます。

3.3 整列と「良い連続」は同じ概念ではない

整列は、デザイン実務で使われる原則です。複数の要素へ共通の端、中心、軸などを与え、構成上の関係を作ります。

一方、良い連続は知覚的グルーピングに関する概念です。簡単に言えば、方向の合う線分や滑らかにつながる部分は、連続した輪郭としてまとまって見えやすいという傾向です。

より正確には、良い連続は輪郭統合や知覚的組織化の研究で扱われます。離れた局所要素でも、向きが滑らかな曲線に沿えば、一つの輪郭として検出されやすくなる条件があります。

Web ページで見出しと本文の左端を揃えることは、滑らかな曲線を検出する実験課題と同じではありません。図 F03 も二つの概念を二軸の実験へしたものではなく、整列、良い連続、両者を混同できない反例を順に見る概念比較です。整列した端が連続した構造として見える説明候補に、知覚的な連続性を挙げられる場合はあります。しかし、次のように短絡させません。

良い連続の法則がある。だから、すべて左揃えにすべきだ。

良い連続は、どの要素を揃えるべきかも、左・右・中央のどれを選ぶべきかも決めません。整列の目的は、内容、読む方向、課題、媒体、表現意図から決めます。

名前を分野と一緒に使う

整列：［デザイン原則］
良い連続：［知覚心理学］
ベースライン整列：［Typography／CSS］
光学調整：［Typography／グラフィックデザイン実務］

似た場面で使われる言葉でも、出自と説明できる範囲は違います。名前を知ることは、同じ言葉へまとめることではなく、どの説明を疑うべきか見分けることでもあります。

3.4 1 px のずれが問題になるとき、ならないとき

レビューで「ここが 1 px ずれています」と指摘されることがあります。CSS 上で測れば、実際に 1 px の差があるかもしれません。しかし、そこから直ちに「利用者にも見える」「使いにくい」「修正優先度が高い」とは言えません。

少なくとも、三つを分けます。

物理的な差: CSS や Screenshot 上で位置が異なる
知覚: 観察者が差や線の途切れを検出する
影響: 探索、比較、理解、操作、印象へ差が生じる

図 F04 は心理物理実験の結果ではなく、観察条件を揃えるための教材です。図から人間一般の検出閾を求めません。「差を検出した」「線が途切れて感じた」「課題を妨げた」を分けて記録する練習に使います。

反復があると差を見つけやすい

二つの要素だけを見比べる条件と、同じ端が八回反復する列の中で一つだけ位置が異なる条件では、比較対象の数、全体幅、視線移動も変わります。例外を見つけやすくなる可能性はありますが、反復数だけの効果とは断定できません。図では系列の占有幅と項目密度を記録し、交絡を含む教育比較だと明示します。

境界の強さで見え方が変わる

高いコントラストの細いボーダーが 1 px ずれる場合と、輪郭の曖昧な影が 1 px ずれる場合では、検出しやすさが異なる可能性があります。文字ブロックでは、Glyph の形や Font Metrics も見かけの端へ影響します。

CSS px だけでは表示を特定できない

CSS px は、そのまま特定の物理画素や視角を意味しません。ブラウザズーム、DPR、OS、Rasterization、視距離、画面の品質によって、Screenshot や実機での見え方は変わります。

図 F04 の 1 px は、特定条件内の比較値です。「人間は 1 px のずれを検出できる」あるいは「検出できない」という一般則を示す図ではありません。

見つけた差を、直す理由へ飛躍させない

ずれが検出できても、課題を妨げない場合があります。反対に、数値上は小さな差でも、表の列を読み違える、フォームの対応を誤る、状態の違いを見落とすなら優先度は上がります。

修正理由は、次のように書きます。

8 枚の出演者カードが左端を共有する中で、4 枚目の本文だけが 2 CSS px 右へずれている。カード間の反復から偶発的な例外として検出される可能性がある。変更前後で線の途切れの検出と、出演者名を探す時間を別々に比べたい。

「2 px ずれている」は観察の一部であって、結論ではありません。

3.5 数学的中央と視覚的中央

円を正方形の中央へ置く場合、Bounding Box の中心を一致させれば、中央に見えやすいでしょう。では、右向きの三角形ではどうでしょうか。

三角形の Bounding Box を枠の中央へ置いても、左右の塗り面積、輪郭の張り出し、尖った先端、内外の空白形状が非対称なため、少し左または右へ寄って見える場合があります。再生アイコンがボタン内でずれて見えるのは、よく使われる例です。

幾何学的中央を捨てない

光学調整は、「数値を無視して感覚で動かす」という意味ではありません。まず、Bounding Box、Container、Center を確認します。その基準案と、位置を少しずつ変えた候補を同じ条件で並べます。

幾何学的中央を基準案にする
左右・上下の塗り面積、輪郭の張り出し、Stroke、内外の空白、隣接要素を観察する
水平または垂直位置だけを変えた候補を作る
実際の表示サイズと背景で比べる
補正の責任をアイコン画像、コンテナ、CSS のどこへ持たせるか決める

補正値は普遍的ではありません。同じ三角形でも、線だけの Icon か塗りの Icon か、16px か 64px か、文字と並ぶか単独かで結果が変わります。

「視覚的中央」は測定値の名前ではない

画像上の面積重心を計算しても、必ず人が中央と判断する位置を得られるわけではありません。形の意味、方向、周辺の余白、見る時間、慣習も関わります。本章では、視覚的中央を固定公式ではなく、比較によって確かめる調整目標として扱います。

3.6 文字は箱の中央だけでは揃わない

発展――タイポグラフィと CSS の詳細です。章末課題の後に読んでも構いません

文字は長方形の画像ではありません。CSS の行ボックス、フォント内部の指標、実際に描画される字形の輪郭には、それぞれ別の境界があります。

文字列内部のベースライン

多くの欧文文字がその上に並ぶ基準です。H や x はベースライン付近で止まり、g や p の一部は下へ伸びます。見えている文字の最下端を揃える線ではありません。

大文字の高さと小文字の高さ

大文字の高さと小文字の代表的な高さは、欧文フォントの見かけを説明する指標です。同じ font-size でも、フォントが違えば見かけの大きさが異なる理由の一部になります。

ただし、日本語の仮名・漢字を小文字の高さで評価することはできません。和欧混植では、日本語と欧文の設計枠、ベースライン、約物、数字の見え方を実際の文字列で確認します。

行ボックス

ブラウザが行を配置する箱です。line-height は行の高さへ関わりますが、見えている字形の上下へ単純に同量の空白を足す指定とは限りません。フォント指標とブラウザのインラインレイアウトによって結果が決まります。

レイアウトで使うベースライン整列

大きな価格「3,000」と小さな通貨単位「円」を横に並べるとします。二つの箱を上下中央へ揃える案と、文字のベースラインを揃える案では、一行としての見え方が変わります。

インライン整形文脈で文字やインラインレベルの箱が共有するベースラインと、Flexbox／Grid で項目同士を揃えるベースライン整列は、同じ説明段階ではありません。まず一つの行ボックス内で文字がどのベースラインへ置かれるかを見ます。その後で、Flex 項目または Grid 項目がベースラインを共有する条件を仕様とブラウザで確認します。

Flexbox や Grid では、align-items: center とベースライン整列を比較できます。ただし、CSS の baseline を指定すれば、あらゆる文字とアイコンが自動的に美しく揃うわけではありません。置換要素、インライン SVG、絵文字、異なる書字方向では、どのベースラインが使われるか、合成されるかを仕様とブラウザで確認します。

タイポグラフィの詳細、Web フォント読込中のフォント指標の変更、和欧混植は第7章で改めて扱います。本章では、文字にも複数の見えない線があることを観察します。

3.7 Flexbox と Grid の重ね合わせ表示で仮説を確かめる

実装と接続する――必修は、重ね合わせ表示を見る前に基準を予想することです

DevTools を開く前に、画面を見て予想します。

カード外形は三列の Grid トラックへ揃っている。カード内部のボタンは Flex コンテナの交差軸中央へ置かれている。見出しだけは親 Grid ではなく、別コンテナの左端を使っているのではないか。

その後で重ね合わせ表示を表示します。

DevTools で基準線を答え合わせするを示す図。 — 図 3-7　DevTools で基準線を答え合わせする

確認の順序

重ね合わせ表示なしで、見える線を予想する
要素を選び、ボックスモデルの端を確認する
Grid の線、トラック、領域、間隔を表示する
Flex コンテナの軸と配置を確認する
Computed で実際に適用された値を確認する
一つの値または規則を一時的に変える
重ね合わせ表示を消し、ページ全体へ戻って見る

重ね合わせ表示は、デザインの正解を表示しません。Grid の線へ一致していても、その Grid 自体が内容や課題に合わないことがあります。反対に、意図的な視覚補正によって、幾何学上は線から外れていても揃って見える場合があります。

値を見る前に、何が原因かを予想する

左端のずれが見えたとき、原因候補は一つではありません。

親 Grid の Track が違う
子要素の margin がある
Container の padding が違う
Border の有無で見える端が変わる
Font や Glyph が見かけの端を変える
transform で描画位置だけが動いている
Scrollbar や動的内容で利用可能幅が変わる

候補を書いてから DevTools で確かめると、値を眺める作業が仮説検証になります。

DevTools の画面や機能は更新されます。図 F07 ではブラウザ名、版、確認日を記録し、Chrome と Firefox の UI を同じ手順図へ混ぜません。

3.8 揃えないことで関係を示す場合

すべてを一つの線へ揃えれば、常に良い画面になるわけではありません。

見出しを本文の軸から意図的に外すと、章の切り替わりや階層を強く示せる場合があります。画像と文章の軸をずらすと、非対称なリズムや方向を作れる場合があります。雑誌的な構成、広告、ポートフォリオでは、ずれそのものが表現の一部になります。

意図は画面だけから断定できない

一つだけずれたカードを見て、「意図されたデザインだ」「実装ミスだ」と画面だけから確定することはできません。次の証拠を集めます。

同じ役割でずれが反復されるか
ずれが階層や状態の違いと対応するか
別のビューポートでも関係が保たれるか
デザイントークンや部品バリエーションに名前があるか
変更履歴や設計意図に記録があるか
利用者が差をどのように解釈するか

意図された例外でも、目的を果たしているとは限りません。偶発的な差でも、必ず利用上の問題になるとは限りません。「揃っていない」という観察から、意図と効果を分けて調べます。

揃える単位を変える

ページ全体を一つの Grid へ押し込む代わりに、セクションごとに異なる軸を持たせる方法があります。大きな構成ではずらし、各セクション内部では反復する。こうすれば、変化と規則を同時に作れます。

Web では、画面幅と内容量が変わります。デスクトップ表示で成立する非対称構成が、モバイル表示で偶発的な段差に見えることもあります。意図したずれには、どの条件で維持し、どこで解消するかというレスポンシブ上の規則が必要です。

3.9 問い――どの線が途切れて見えるか

文化祭の出演者一覧を観察します。無注釈面へ、自分が見つけた線を三本まで引いてください。

観察条件

人：出演時刻を手がかりに、見たい出演者を探す初見の来場者
課題：16 組の一覧から、15 時以降に出演する音楽企画を時刻から見つける
道具：幅 1280px のデスクトップ表示と、幅 390px のタッチ端末
基準状態：通常の出演者名、画像あり、Firefox の「テキストだけ拡大」を無効、ページズーム 100%
耐性状態：長い出演者名、画像なし、幅 390px、Firefox の「テキストだけ拡大」で 200%を、それぞれ別の派生条件として確認する

問い

どの要素の、どの基準が共有されていますか。
どこで見えない線が途切れていますか。
それは物理的な差、知覚、課題への影響のどれについての観察ですか。
まず幾何学的な基準案を作れますか。形態による見かけのずれが残る場合は、調整案も作れますか。
一つだけ変えるなら、何を固定し、何を変えますか。
その変更を、知覚と探索課題でどう確かめますか。

答えの例

1. 場所と基準を指す

各カードでは、出演時刻の右端を基準に縦方向へ走査できます。しかし、4 枚目だけ時刻要素の Border Box 右端が、他の時刻列から 2 CSS px 外れています。Glyph の見える右端は別に観察し、CSS Box の Edge と混同しません。

2. 観察の種類を分ける

DevTools で測った位置差は実装上の差です。カード列を見たとき、4 枚目で時刻の右端を結ぶ構成軸が途切れて感じられるかは知覚の問いです。15 時以降の企画を時刻から探す正確さや時間へ影響するかは課題の問いです。まだ後二つの結果は得られていません。

3. 概念を候補として使う

同じ右端と桁位置の反復が構成上の基準を作っているため、4 枚目が意図しない例外として見える可能性があります。これはデザイン原則としての整列から説明できます。良い連続という語だけで修正を正当化する必要はありません。

4. 別の要因を残す

4 枚目には「まもなく開始」という状態表示があり、その挿入によって時刻列の Container 幅が変わっているかもしれません。状態差を表す意図があるなら、単純に左端を揃えると意味を失う可能性があります。比例数字、等幅数字、長い名前の折り返しも確認します。

5. 二つの案を作る

幾何学的な基準案では、時刻列へ固定幅を与え、時刻の右端を同じ Grid Line へ配置します。この案で時刻探索が成立し、見かけ上の問題が残らなければ、追加補正は不要です。形態によるずれが残る場合だけ、比例数字と等幅数字、コロンや接尾辞の見え方を実際の時刻列で比較します。これは位置補正だけでなく Typography を含む発展的な別案です。

6. 確かめ方を書く

無注釈の変更前後を同じ条件で提示します。知覚課題では、どこで線が途切れたかの報告を主要指標にします。探索課題では正答率を主要指標、完了時間と誤って選んだ項目数を補助指標にします。視線計測をしていないのに「視線の戻り」を測ったとは書きません。印象評価とは別に記録します。

表示条件は、ビューポート、ブラウザズーム、文字サイズ変更、DPR を別軸として残します。すべての組み合わせを試すのではなく、折り返しや列構成が変わる代表条件を選びます。

幅 390px で一列になる場合は、デスクトップ表示の縦方向の軸をそのまま縮小するとは限りません。時刻をカード上部へ移し、各カード内部で右端を共有する案も比較します。どの基準を維持し、どの Breakpoint で別の基準へ切り替えるかを記録します。

別の答え方

出演者名の行頭を中心問題にする答えもあります。ただし、今回の課題は時刻から探すことなので、課題への影響を論じるなら時刻列を先に検討する方が直接的です。名前の行頭は、名前から探す別課題で確かめます。

また、カード単位ではなく、セクション見出しとカード列の左端が異なることを観察できます。これは意図された階層差かもしれないため、ページ内の他セクションと反復を確認します。

よくある考え方

4 枚目が 2 px ずれているので、他と同じ値へ直す。

この考え方の注意点

何の Edge がずれているか、なぜ共有されるべきか、知覚できるか、課題へ影響するかが書かれていません。また、状態を示す意図的な差である可能性も残っています。

次のように書けば、比較できます。

4 枚目の時刻要素の Border Box 右端が、他の 15 枚と共有する列から 2 CSS px 外れている。状態表示の挿入で時刻列の幅が変わった可能性がある。状態表示の領域を分け、時刻列の右端だけを固定すると、状態を保ちながら開始時刻を走査しやすくなるのではないか。

必須セルフチェック

どの要素の、どの基準が共有されているかを指したか
物理的な差、ずれの知覚、課題への影響を分けたか
幾何学的な基準案と形態に応じた調整案を比較したか

発展セルフチェック

整列と良い連続を同義語にしていないか
Box の Edge と、Glyph の見かけの Edge を区別したか
1 px を表示条件のない絶対基準にしていないか
ずれを意図またはミスと画面だけから断定していないか
Overlay を見る前に基準線を予想したか
デスクトップ表示以外でも規則が続くか確認したか
日本語、欧文、数字、Icon を同じ Metric で説明していないか

次章へ

揃いは、複数の要素へ共通の基準を与えます。しかし、同じ線へ置かれていても、色、形、角丸、文字の扱いが異なれば、同じ役割には見えないことがあります。反対に、異なる役割が同じ見た目を持てば、誤った規則を教える可能性があります。

次章では、似たものを仲間として見る知覚と、Web 画面が反復によって役割を教える仕組みを扱います。

参考資料

入口: York University, “Max Wertheimer, Laws of Organization in Perceptual Forms（英訳）.” 良い連続を含む古典的な知覚的組織化の原典英訳です。現代の Web レイアウト規則を直接述べた資料ではありません。
発展: Johan Wagemans et al., “A Century of Gestalt Psychology in Visual Perception I,” 2012. 良い連続と輪郭統合を含む研究史のレビューです。4.2.2 から読むと本章に接続しやすいでしょう。
実験研究: Field, Hayes, and Hess, “Contour integration by the human visual system,” 1993. 局所的な線要素から輪郭を検出する実験です。初学者には難しいため、刺激図と要旨から確認してください。
デザイン: Ellen Lupton, Thinking with Type. 整列を含む Typography と Layout の入口です。心理学上の法則集ではなく、デザイン実務の文献として読みます。
デザイン: Josef Müller-Brockmann, Grid Systems in Graphic Design. グリッドを用いた構成の歴史的・実務的資料です。Web にそのまま適用する規格ではありません。
公式仕様: W3C, “CSS Box Alignment Module Level 3.” Flexbox や Grid を含む Box Alignment と Baseline Alignment の仕様です。
公式仕様: W3C, “CSS Inline Layout Module Level 3.” Line Box と Baseline の詳細を確認する仕様です。初読では Baseline 関連の用語を引く用途で構いません。
公式仕様: W3C, “CSS Fonts Module Level 4.” Font 選択と Metric Override を含む CSS Fonts の仕様です。
公式資料: Chrome for Developers, “Inspect CSS grid layouts.” Grid Overlay の操作と表示内容を確認できます。公開時には画面が更新されていないか再確認します。
公式資料: Chrome for Developers, “Inspect and debug CSS flexbox layouts.” Flexbox の Badge、Overlay、Editor を確認する資料です。

検索キーワード：整列デザイン、良い連続知覚、good continuation contour integration、optical alignment typography、CSS baseline alignment、font metrics baseline cap height、DevTools grid overlay

第4章　人間は、似たものを仲間だと思う

画面内に青い角丸ボタンが五つあるとします。四つは次の画面へ進み、一つだけは入力内容を削除します。見た目が同じなら、利用者は同じ種類の操作だと予想するかもしれません。

反対に、五つとも同じ「詳細を見る」という操作なのに、高さ、色、角丸、文字の太さが一つずつ違っていたらどうでしょうか。役割は同じでも、別の重要度、別の状態、別の機能に見える可能性があります。

人は、似たものをまとまりとして見やすい傾向を持ちます。しかし、画面で似て見えることと、同じ役割であることは同じではありません。HTML や部品が同じこととも、同じトークンを参照していることとも違います。

本章では、類似を次の四層に分けます。

知覚: 何が似て見え、同じまとまりとして見えるか
役割: 同じ種類の情報・操作・状態だと予測するか
動作: 実際に同じ結果や操作方法を持つか
実装: 部品、トークン、CSS 値の何を共有するか

この章の必修は三つです。

何と何の、どの属性が似ているかを指す
見た目の類似と、役割・状態・動作の類似を分ける
差の意図を仮説にし、画面・実装・人の行動で確かめる

この章で見るもの

色、形、大きさ、向き、タイポグラフィ、アイコンの何が反復するか

同じ役割なのに違う見た目がないか

違う役割なのに同じ見た目がないか

例外が状態、重要度、危険性、文脈を表しているか

部品、デザイントークン、CSS カスタムプロパティのどこから差が生じたか

4.1 同じ制服、同じ標識から規則を見つける

駅で同じ色と形の衣服を着た人を見れば、同じ活動に参加していると予想するかもしれません。しかし、服装から職業、権限、所属を決めつけることはできません。同じ形の標識が反復されれば、同じ種類の案内だと考えるかもしれません。作業台に同じ向きで並んだ道具は、一つの工程のために用意されたまとまりに見えることがあります。

制服、標識、道具を分類するを示す図。 — 図 4-1　制服、標識、道具を分類する

ただし、ここには複数の説明があります。

色や形が知覚的なまとまりを作った
制服や標識の社会的な意味を知っていた
同じ場所に近接していた
同じ方向を向き、同じ行動をしていた
その場の状況から役割を推測した

色が同じだから同僚だ、と知覚だけで決まるわけではありません。似た外観は分類の手がかりですが、その分類へ何の意味を与えるかには、経験と状況が加わります。

図 F01 では、最初に意味ラベルを隠します。何を同じ組へ入れたか、次に何が似ていたためかを答えます。その後で複数の状況説明を開き、同じ配置にも別の社会的解釈がありうることを比べます。正しい所属を当てる課題にはしません。

観察の基本形

私は A と B を同じまとまりとして見た。色は同じだが、形と向きは異なる。意味を知る前は同じ役割だと予想したが、説明を読むと役割は異なっていた。

「似ている」で止めず、似ている属性と、そこから予測した意味を分けます。

4.2 同じ役割なのに違うボタン

文化祭サイトに「詳細を見る」というボタンが五つあります。どれも出演者カードから詳細プレビューが開く操作です。しかし、一つだけ高さが 2px 低く、一つだけ角丸が強く、一つだけアイコンを持つとします。

ボタンの一属性だけを変えるを示す図。 — 図 4-2　ボタンの一属性だけを変える

一度に一属性だけを見る

色、高さ、角丸、文字、アイコンを同時に変えた比較では、どの差が見え方を変えたのか分かりません。図 F02 では、文言、位置、動作、状態を固定し、一つの属性だけを段階的に変えます。属性を個別に見た後は実際の画面へ戻り、タイポグラフィ、余白、画像、構図を含む全体の調子として差がどう働くかも見ます。

統合画面では、カード群の画像比率、見出しの書体、余白の周期、色面の配置が同じ調子を作っているかを観察します。ボタンだけが揃っていても、画像の扱いとタイポグラフィがカードごとに別の調子なら、画面全体の一貫性は保たれない場合があります。属性分析は入口であり、造形全体の評価の代わりではありません。

見る順序も分けます。

差を検出したか
同じ役割だと予想したか
重要度の差だと思ったか
ホバー、フォーカス、無効などの状態差だと思ったか
実際に操作すると同じ結果だったか

見た目の差を検出しても、役割は同じだと判断する人がいるでしょう。反対に、小さな差から別状態を予測する人もいるでしょう。「違って見える」と「違う役割に見える」を同じ回答にしません。

差は情報になる

一つだけ異なる見た目は、例外として注意を引く可能性があります。その差が選択中、危険な操作、主要な行動、読込中を一貫して示すなら、必要な情報です。

問題は、差があることそのものではありません。

この差は、利用者が知る必要のある何の違いと対応しているのか。

答えられない差は、制作途中の偶発差かもしれません。ただし、スクリーンショットだけから「技術的負債だ」と断定はできません。実装、設計意図、履歴も確認します。

同じ役割の範囲を決める

「すべてボタンだから同じ見た目」にする必要もありません。送信、削除、閉じる、カード全体の補助操作は、いずれもボタンであっても役割、重要度、危険性、配置が違います。

比較する単位を、HTML 要素名だけで決めません。

同じ結果を起こすか
同じ重要度か
同じ状態か
同じ文脈にあるか
同じ入力方法と操作を持つか

どの範囲を同じ役割として設計したかを先に書きます。

4.3 違う役割なのに同じ見た目

角丸の枠に短い文字が入ったピル状の要素を考えます。次の要素が、ほぼ同じ見た目を持っています。

別ページへ移動するリンク
フィルターを適用するボタン
現在選択中の条件を示す文字
条件を解除するボタン

知覚上は、同じ種類の要素としてまとまって見えるでしょう。しかし、クリック後の結果、選択状態、キーボード操作、フォーカス、解除方法は異なります。操作要素を別の操作要素へ入れ子にせず、状態を表す文字と解除ボタンを別の操作単位として設計します。

見た目は意味を自動的に作らない

CSS で a と button を同じ外観にできます。div をボタンのように見せることもできます。しかし、外観を似せただけで HTML の意味や標準的なキーボード動作が同じになるわけではありません。

反対に、ネイティブの button を使っただけで、役割が見て分かるとも限りません。アクセシブルネーム、状態、フォーカス表示、操作結果、エラー時の動作まで確認します。

見た目と実装を、次の表で分けます。

確認層	問うこと
外観	色、形、文字、アイコンの何が同じか
予測	利用者は何が起きると思うか
HTML	どの要素・役割・状態を持つか
操作	ポインター、キーボード、タッチでどう使うか
結果	移動、実行、選択、削除の何が起きるか

本章の例では、ページ移動は a[href]、フィルター適用と解除は button、現在条件は文字として実装します。フィルターの押下状態には aria-pressed を使う案を、一覧更新には状態メッセージを使う案を検証します。ただし、ARIA 属性を付ければ完了とは考えません。Tab 順、Enter／Space、フォーカスの維持、更新範囲、読み上げ、ローディング、0 件、エラーを状態表にして確認します。

単一選択か複数選択かを先に決めます。本章の基準画面は複数ジャンルを選べるトグルボタン群とし、各ボタンは aria-pressed で現在の押下状態を伝えます。リンクは Enter、ボタンは Enter と Space というネイティブの操作差を維持します。フィルター実行後もフォーカスを押したボタンへ保ち、一覧更新はフォーカスを移動せず状態メッセージで件数を通知する案を検証します。

同じ外観を使うなら、利用者が同じ種類だと予測しても困らない範囲かを確かめます。違う外観を使うなら、その差が役割や状態の差と対応するかを見ます。

4.4 類同の原則と一貫性

第2章では近接を扱いました。知覚的グルーピングの別の手がかりが類同です。

簡単に言えば、似たもの同士は同じまとまりとして知覚されやすい、という傾向です。色、形、大きさ、向き等の類似が手がかりになります。

より正確には、他の条件がおおむね等しい刺激で、ある視覚属性が類似する要素が知覚的にグループ化されやすい現象を扱います。どの属性の類似が、どの条件で、どの程度働くかは一様ではありません。

類同は役割を決めない

同じ赤い円が一列に見えても、それらが削除ボタンであるか、エラー表示であるか、装飾であるかは類同から決まりません。類同は知覚上のまとまりを説明します。意味と役割は、内容、経験、操作、文脈から推定されます。

一貫性は実務上の設計原則である

一貫性は、同じ役割や状態へ反復した表現・動作を与え、画面や製品の規則を保つ設計原則です。知覚心理学の類同と関係する場面はありますが、同じ概念ではありません。

類同：似た視覚属性がまとまりを作る知覚的傾向
一貫性：役割、状態、動作、表現の対応を反復する設計判断

「類同の原則があるから、ボタンはすべて同じ色にする」とは結論できません。主要ボタン、補助ボタン、危険なボタン、選択状態を同じにすれば、必要な差を失う可能性があります。

近接と類同が競合するとき

近い要素は縦の組を作り、同じ色の要素は横の組を作る配置があります。このとき「類同は近接より強い」という固定順位を覚えません。距離差、色差、形、配置、課題を変えれば、まとまりの報告も変わり得ます。

図 F04 では、距離を固定して色差を変える系列と、色を固定して距離差を変える系列を分けます。最後に競合画面へ戻ります。一つの原則名で勝敗を宣言するのではなく、どの手がかりがどの関係を示しているかを書きます。

4.5 UI は使われながら自分の規則を教える

初めて見る Web サイトでも、利用者は完全に知識がないわけではありません。過去の Web 利用から、青い下線付き文字はリンク、歯車は設定、虫眼鏡は検索、といった期待を持ち込みます。この外部の慣習は第15章で扱います。

同時に、一つのサイト内でも規則を学びます。

最初の青い角丸要素を使う前に、結果と確信度を答える
プレビューが開く経験をする
複数の既知要素で同じ対応を経験する
未知の青い角丸要素について、結果と確信度をもう一度答える

これは図だけで実証された学習効果ではなく、観察するための仮説シナリオです。「3 回で学ぶ」という回数則ではありません。経験回数、順序、既存の Web 経験を記録し、経験前、経験後、未知要素への転移で予測と確信度がどう変わったかを確かめます。

一貫性が破れたとき

四回目だけ、同じ青い角丸要素がフィルターを解除したらどうでしょうか。利用者は過去の対応から移動を予測し、意図しない結果を起こすかもしれません。

ただし、予測違反が常に悪いわけではありません。購入完了、危険な操作、現在位置など、重要な例外を強く示すために規則を変えることがあります。例外が必要なら、差を明確にし、文言、アイコン、配置、確認手順などでも意味を支えます。学習を観察する試行では、削除、購入、公開などの不可逆または高リスクな結果を使わず、プレビューやフィルターのように安全に戻せる課題を使います。

学習を観察する

次の三つを別に記録します。

操作前に何が起きると予測したか
操作後に何が起きたか
次の同種要素への予測がどう変わったか

「分かりやすかったですか」という感想だけでなく、予測と行動の変化を見ます。一人の結果を全利用者へ一般化しません。

4.6 部品とデザイントークンが守るもの

実装と接続する――章末課題の後に読んでも構いません

同じボタンを何度も手作業で描けば、色、高さ、角丸、内部余白に小さな差が生じやすくなります。部品は、外観と動作を再利用する単位を作る手段です。デザイントークンは、色や寸法などの設計判断を名前付きデータとして共有する手段です。

部品、トークン、CSS の三層を示す図。 — 図 4-6　部品、トークン、CSS の三層

しかし、次の四つは同じではありません。

画面上で同じに見える
同じ部品を使う
同じトークンを参照する
計算後スタイルの値が同じである

別の部品でも同じ見た目を作れます。同じ部品でもバリエーションや状態で見た目は変わります。同じトークンを異なる役割へ流用すれば、後の変更で意図しない連動が起こることがあります。自由値が偶然トークンと同じ値になることもあります。

部品は外観だけではない

ボタン部品を考えるとき、色と角丸だけでなく次を含めます。

内容とラベル
HTML の意味
ポインターとキーボードの操作
通常、ホバー、フォーカス、押下中、無効、ローディング
アイコン有無と長い文言
レスポンシブ条件
エラーと成功後の動作

同じ見た目を再現するだけでは、同じ部品とは言い切れません。反対に、同じ部品内で必要な状態差を作ることも、一貫性の一部です。

トークンは判断を代行しない

color-blue-600 のような基礎トークンや、action-primary-background のような意味トークンが考えられます。名前を細かくすれば必ずよいわけではありません。どの変更を一緒に波及させ、どの差を閉じ込めたいかで層を選びます。

Design Tokens Community Group の Format Module は、トークンデータを交換する形式を整理しています。これは知覚原則でも、部品設計の正解でもありません。草案の版を確認し、仕様が定義する範囲と自分たちの命名規則を分けます。

四層監査表で一つの差を追う

層	文化祭サイトで記録する証拠
知覚	どのボタンが同じまとまりに見えたか
役割	押す前に同じ結果を予測したか
動作	移動、フィルター、解除のどれが起きたか。キーボード動作は何か
実装	HTML 要素、部品／バリエーション、トークン参照、計算後スタイル

一つの青いボタンだけ色が違う事例を、4.6 と 4.7 で継続して追います。画面上の差から始め、役割と状態を確認し、部品、トークン、CSS へ進みます。四層すべてが一致することを正解にはしません。どの層の差が意図を持ち、どこで説明が途切れているかを見ます。

4.7 CSS Custom Properties で差異の出所をたどる

発展――CSS の詳細です。四層監査表まで読めば章末課題へ進めます

画面で、同じ主要操作の一つだけ色が違うと気づいたとします。すぐ値を上書きせず、出所を予想します。

別の部品か
状態による上書きか
テーマか
親から継承されたカスタムプロパティか
代替値が使われたか
局所的な自由値か
カスケードの優先関係か

CSS Custom Properties で差をたどるを示す図。 — 図 4-7　CSS Custom Properties で差をたどる

画面から実装へ進む

何と何の、どの属性が異なるかを書く
役割と状態が同じか確認する
適用値を予想する
計算後スタイルを見る
スタイルパネルなどで宣言と var() 参照を辿る
計算後スタイルの最終値と、定義位置、継承、代替値、状態による上書きを分けて見る
一つだけ一時変更し、画面全体へ戻る

カスタムプロパティは、値を共有し、出所を辿る手がかりになります。計算後スタイルは最終的なプロパティ値を確認する場所であり、すべてのカスタムプロパティの継承・代替値・カスケード経路を説明する標準化された履歴画面ではありません。親で未定義、登録プロパティの inherits: false、無効値、代替値使用を別条件にします。同じ変数を使っているから同じ役割だとも限りません。--blue をリンクとボタンが共有していても、役割は違います。

スクリーンショットから技術的負債を断定しない

見た目の差は、技術的負債の兆候かもしれません。しかし、次の可能性もあります。

A/B テスト中である
新旧部品を段階移行している
ブランドやサブプロダクトが違う
状態または権限差を表している
アクセシビリティモードが働いている
ブラウザのネイティブ部品差である

DOM、CSS、デザインファイル、部品の利用例、トークン、変更履歴を確認します。見た目から作った仮説を、コード上の事実にすり替えません。

4.8 一貫していればよいわけではない

一貫性は、すべてを同じにすることではありません。必要な違いを、規則的に表すことでもあります。

状態の違い

選択中、無効、ローディング、エラー、成功は、通常状態と同じ見た目では状態を伝えられません。差は必要です。ただし、色だけで示さず、文字、アイコン、形、位置、支援技術へ伝わる状態を組み合わせます。

危険性と重要度

削除や公開の操作は、通常の補助操作と区別する理由があります。ただ赤くすれば安全になるわけではありません。文言、配置、確認、取り消し、権限、結果のフィードバックも設計します。

文脈の違い

同じ「保存」でも、自動保存の設定画面と、公開を伴う編集画面では意味が違います。製品全体で完全に同じ見た目へ揃えるより、文脈に必要な説明を加える方がよい場合があります。

アクセシビリティ

強制色や文字拡大では、通常テーマと異なる境界線や形が現れる場合があります。これは「アクセシビリティが一貫性を壊す例外」ではありません。色の置換後にも役割と状態を一貫して識別できるよう、文字、形、システム色、境界線を含めて設計する条件です。一貫性の対象を、特定ピクセルの一致ではなく、役割と状態が伝わることへ置き直します。

段階的な移行

デザインシステム更新中は、新旧部品が同時に存在することがあります。これは負債かもしれませんが、安全な移行計画かもしれません。移行範囲、期限、互換性、利用状況を確認します。

一つの差を見つけたら、次の順で考えます。

何が違うか
役割、状態、文脈も違うか
差を説明する意図はあるか
その意図は利用者に伝わるか
実装上の出所は何か
変更すると何が波及するか

4.9 問い――この違いは、役割の違いを教えているか

文化祭のフィルターと出演者カード一覧を観察します。

観察条件

人：好きなジャンルの出演者を探す初見の来場者
課題：「音楽」を選び、15 時以降の出演者を一人開く
道具：幅 1280px、マウスとキーボード
基準状態：通常の内容、キーボードフォーカスなし
派生状態：幅 390px、キーボードフォーカス、ローディング、エラー、Windows 強制色を一軸ずつ

問い

何と何の、どの属性が似ていますか。
似た要素は、本当に同じ役割・状態・動作ですか。
一つだけ違う要素は、何の差を示している可能性がありますか。
画面だけでは分からないことを、何で確認しますか。
フィルター選択と、その後の時刻からの出演者探索を通して、一つだけ変えるなら何を変え、何が起きると予想しますか。
知覚、役割推定、操作課題をどう分けて確かめますか。

答えの例

1. 属性を指す

「音楽」「演劇」「展示」のフィルターと「選択中：音楽」というタグは、青い文字、薄い青の背景、角丸の外形が似ています。一方、フィルターには枠線があり、選択中タグにはチェックアイコンがあります。

2. 役割を分ける

フィルターは押すと一覧条件を変更するボタンです。選択中タグは現在の条件を表示し、末尾の削除ボタンで解除できます。知覚上は同じまとまりに見えても、操作単位と結果は同じではありません。

3. 概念を候補にする

色と形の類同によって、フィルターと選択状態が同じ機能群として見える可能性があります。これは関連性を示す点では役立つかもしれません。しかし、全体をクリックできるか、状態表示なのかは類同だけでは説明できません。

4. 別仮説と証拠を残す

近接、位置、文言、チェックアイコン、フォーカス表示も役割推定へ関わります。HTML 要素、アクセシブルネーム、キーボード操作、クリック結果、部品の利用例を確認します。スクリーンショットだけから「同じ部品の使い回し」とは断定しません。

5. 変更仮説を作る

フィルターの外形を固定し、現在条件の表示だけに「選択中」という文字ラベルと独立した解除ボタンを加えると、関連する機能群であることを保ちながら、操作と状態表示を区別しやすくなるのではないか。その後の一覧では、時刻列の位置とカードの詳細リンクは変えず、フィルター修正だけが 15 時以降の出演者探索へ与える影響を比べます。

6. 確かめ方を書く

知覚課題では、どの要素を同じまとまりへ分類したかを記録します。役割推定では、操作前に各要素を押すと何が起きると思うかを聞きます。操作課題は二段階に分けます。第一段階は音楽フィルターを正しく選べたかを主要指標、フィルター／解除の誤操作と所要時間を補助指標にします。第二段階は更新後の一覧から 15 時以降の出演者を正しく開けたかを主要指標、時刻条件の見落としと所要時間を補助指標にします。全体完了率を示す場合も、止まった段階を併記し、合成値だけで解釈しません。

四層監査表を完成させる

層	この画面で得た証拠
知覚	フィルターと現在条件表示は青・角丸が似て同じ機能群に見えた
役割	一部の人は現在条件表示の全体を解除ボタンだと予測した
動作	フィルターボタンは一覧更新、独立した解除ボタンは条件解除、詳細リンクはページ移動を行う
実装	`button[aria-pressed]`、文字＋解除 `button`、`a[href]` を別部品のバリエーションとして実装し、背景トークンだけを共有した

四層は一致／不一致を一語で採点する表ではありません。どの層で予測が成立し、どの層で関係が変わるかを残します。

キーボード条件では Tab 順、フォーカス表示、Enter／Space の動作を記録します。Windows 強制色では色や背景が変わっても、フィルターと選択状態を識別できるか確かめます。基準状態と派生状態を同時に変えません。

別の答え方

主要操作の「出演者を開く」と、補助リンクの「会場を見る」が同じ塗りボタンに見える点を中心にできます。この場合は、どちらを主要行動として予測するか、移動先の違いが外観から伝わるかを検討します。

ローディング中のスケルトンがカードと同じ角丸・幅を持つことは、対応位置を予測させるための一貫性として説明できるかもしれません。ただし、スケルトンを操作可能なカードと誤認しないかも確認します。

よくある考え方

ボタンのデザインを全部統一します。

この考え方の注意点

どこからどこまでを同じ役割としたか、状態や重要度の差をどう残すかが分かりません。リンク、フィルター、タグまで同じ外観へすれば、役割差を失う可能性があります。

次のように書きます。

出演者詳細へ進む主要操作は、同じ役割・重要度・状態なのにカードごとに高さと角丸が異なる。文言と動作を固定し、同じ部品バリエーションへ揃えると、一覧内で同じ操作として予測しやすくなるのではないか。危険な操作と選択状態は別の役割・状態なので変更対象から外す。

必須セルフチェック

何と何の、どの属性が似ているかを指したか
見た目の類似と、役割・状態・動作の類似を分けたか
差の意図を仮説にし、画面・実装・人の行動で確かめたか

発展セルフチェック

類同と一貫性を同義語にしていないか
近接、文言、位置、状態等の別の手がかりを残したか
HTML 要素名だけで見た目を決めていないか
部品名、トークン、CSS 値、見た目を同一視していないか
スクリーンショットだけから技術的負債を断定していないか
色だけで役割や状態を示していないか
レスポンシブ、キーボード、ローディング、エラー、Windows 強制色を確認したか

次章へ

似た見た目は、離れた要素にも共通の規則を感じさせます。しかし、画面のすべてを境界線、背景、影で囲めば、既に距離や類似で見えていた構造を重ねて説明することになります。

次章では、人が足りない輪郭を補い、共通の領域からまとまりを作り、前景と背景を分ける仕組みを扱います。

参考資料

入口: York University, “Max Wertheimer, Laws of Organization in Perceptual Forms（英訳）.” 類同を含む古典的な知覚的組織化の原典英訳です。
発展: Johan Wagemans et al., “A Century of Gestalt Psychology in Visual Perception I,” 2012. 色、形、大きさ、向きによる類同を含むレビューです。
研究: Claessens and Wagemans, “Grouping principles in direct competition,” 2013. グルーピング手がかりの競合を扱います。UI の固定順位表としては使いません。
仕様: WHATWG, “The button element” and “The a element.” 見た目とは別に HTML 要素の意味を確認します。
仕様: W3C, “CSS Custom Properties for Cascading Variables Module Level 1.” カスタムプロパティの定義、カスケード、継承、var() を確認する仕様です。
仕様候補: Design Tokens Community Group, “Design Tokens Format Module.” トークン交換形式の草案です。公開状態と版を再確認してください。
調査資料: Open UI. 部品の構造、状態、振る舞いを横断的に調査する資料への入口です。Web 標準として確定した全ての部品仕様という意味ではありません。

検索キーワード：類同の原則、grouping by similarity、perceptual grouping competition、UI consistency、design token format、CSS custom properties cascade、component variant state

第5章　人間は、足りないものを勝手に補う

画面の構造が伝わるか不安になると、境界線を加えたくなります。カードを枠で囲み、その中の項目を別の枠で囲み、さらにセクション全体へ背景を置く。気づけば、四角の中に四角が重なっています。

しかし、人は描かれた線だけから構造を見ているわけではありません。距離、整列、類似、見出し、輪郭の一部、共通の領域から、まとまりや形を知覚します。境界がなくても構造が見える場合があります。

反対に、境界を消せば洗練されるわけでもありません。入力欄、ボタン、フォーカス、選択状態の識別に必要な境界まで消せば、操作できる場所や状態が分からなくなる可能性があります。

本章では、「枠を減らす」を目標にしません。

章題の「補う」が直接指す中心例は、閉合と遮蔽補完です。共通領域は同じ領域内の要素をまとめる手がかり、図と地は対象と背景の組織化であり、どちらも「足りない線を補う現象」として一括しません。似た Web 表現へ複数の概念名を貼ってしまわないため、あえて同じ章で違いを比べます。

この境界は、何を分けるためにあるのか。境界がなくても、その関係は既に何から見えているのか。

この章の必修は三つです。

見える境界と、それが分ける関係を指す
閉合、共通領域、図と地を区別する
境界を一つだけ変え、知覚・課題・操作への影響を確かめる

この章で見るもの

実際に描かれた輪郭と、補って見た輪郭

同じ領域に入ることで見えるまとまり

前景と背景の分かれ方

境界線、背景、影、間隔が示す別々の関係

モーダルの視覚的な前景化と操作上のモーダル性

境界を消したときに失われる状態・操作の手がかり

5.1 欠けた円と、隠れた物体

円の輪郭が何か所か欠けていても、一つの円として見えることがあります。四つの角だけが描かれた四角形を見て、描かれていない辺を含む形としてまとめる場合もあります。

一方、長い長方形の中央が帯で隠れているとき、左右に別々の長方形があるのではなく、帯の背後へ一つの物体が続いていると知覚することがあります。

この二つは、どちらも「見えていない部分を補う」と説明できますが、同じ現象ではありません。

閉合

離れた輪郭要素や欠けた輪郭が、まとまりのある閉じた形として知覚される傾向です。輪郭の配置、良い連続、対称性、既知の形等も関わります。

遮蔽補完

物体の一部が別の面に遮られているとき、遮蔽物の背後にも物体が続く構造として知覚することです。背後の部分を実際に見ているわけではありません。物体の連続性を推定しています。

図 F01 では、次の三つを線種で分けます。

実際に描かれている輪郭
観察者が形の構造として推定した輪郭。感覚上の線が実際に描かれて見えるという意味ではない
遮蔽物の背後へ続くと推定した部分

「脳が勝手に全部描いてくれる」という説明にはしません。何が実際に見え、何を構造として推定したかを分けます。

5.2 全部を囲まなくてもカードは見える

文化祭の出演者情報が三つ並んでいます。画像、出演者名、時刻、説明、詳細リンクからなるまとまりです。カードの境界線がなくても、カード間の距離がカード内部の距離より大きく、同じ配置が反復していれば、三つのまとまりは見えるかもしれません。

そこへ背景、境界線、影を加えると、まとまりの手がかりは増えます。

カードへ境界を一つずつ加えるを示す図。 — 図 5-2　カードへ境界を一つずつ加える

間隔

カード内部を近づけ、カード間を離すことでまとまりを示します。第2章の近接です。

背景

同じ面色の上に置くことで、一つの領域を作ります。周囲との色差、面積、形、余白によって見え方が変わります。

境界線

領域の外周を線で示します。隣接する面との差が小さい場合や、操作領域を明確にしたい場合に役立つことがあります。

影

面の前後関係や浮き上がりを示す表現として使われます。しかし、影があれば必ずクリック可能、浮き上がりが強ければ必ず重要、とは言えません。製品内の反復と操作結果を確認します。

図 F02 では二つの比較を分けます。

個別比較: 同じ基準画面へ背景だけ、境界線だけ、影だけを加える
累積比較: 間隔→背景→境界線→影と手がかりを重ねる

累積比較で最後の案が最良だとは限りません。どの段階でカード単位が見えたか、どの段階で境界が過剰に感じられたか、クリック可能性の予測が変わったかを別々に記録します。

カードが見えることと、押せることは別である

一つのまとまりに見えても、カード全体が操作可能か、詳細リンクだけが操作可能かは分かりません。ホバー、フォーカス、カーソル、文言、HTML、操作領域、操作結果を確認します。共通領域は、操作可能性の意味を自動では作りません。

5.3 閉合、共通領域、図と地を区別する

閉合、共通領域、図と地は、いずれも「まとまりが見える」場面で紹介されがちです。しかし、説明する現象は異なります。

閉合――輪郭から形をまとめる

欠けた輪郭や離れた輪郭要素が、閉じた形として組織化される現象を扱います。

共通領域――同じ領域内の要素をまとめる

同じ境界領域の中にある要素が、近接や類同とは別の手がかりによって同じまとまりとして知覚される現象です。Palmer が 1992 年に、近接等へ還元できない Grouping Principle として論じました。

囲みを加えたら必ず近接より強くなる、という固定順位ではありません。領域がどう知覚されるか、入れ子、Depth、配置等の条件があります。

図と地――対象と背景を組織化する

形を持つ対象として知覚される側と、その背後に続く背景として知覚される側へ分かれる現象です。図側は輪郭を持つ対象として見え、地側は背後へ続くように見える場合があります。

Web 用語へ直結させない

次の対応を暗記しません。

カード＝閉合
境界線＝共通領域
モーダル＝図
背景の覆い＝地

カードのまとまりは、近接、類同、整列、共通領域などで説明できる場合があります。モーダルを前景として見る説明に図と地を候補として使えても、モーダルの操作規則は知覚心理学からは決まりません。

名前は、画面へ貼る正解ラベルではありません。どの現象を説明しているかを限定するために使います。

5.4 四角の中に四角が増えていく理由

管理画面を作っているとします。ページ全体に背景を置き、セクションをカードで囲み、その中の設定グループを枠で囲み、各入力欄にも境界線があり、補足情報をバッジで囲みます。

境界を加える理由は理解できます。

構造をはっきりさせたい
部品の範囲を示したい
クリック可能に見せたい
情報を整理して見せたい
実装単位と視覚単位を一致させたい

しかし、境界が増えると、それぞれの強さが競合します。セクション、カード、グループ、入力欄がすべて同じ太さ、線種、コントラスト、角丸なら、どの階層が大きいのか分かりにくくなる可能性があります。境界には本数だけでなく、線の太さ、明度差、連続／破線、角の形、面の広がり、影のぼけとずれ、周囲の空間という造形語彙があります。

DOM の入れ子を全部見せない

DOM 上のコンテナすべてに背景や境界線を付ける必要はありません。実装上のラッパー、レイアウトコンテナ、意味上のセクション、知覚されるまとまりは別です。

図 F04 では、外形数の少なさを競うのではなく、意味階層ごとにどの境界語彙を割り当てたかを比べます。次の三つを別 Overlay にします。

DOM の入れ子
画面に見える境界
情報の意味上の階層

三つが完全に一致しないこと自体は問題ではありません。利用者に必要な構造が、適切な手がかりで伝わるかを見ます。

外形数だけで「カードだらけ」を判断しない

カードが多くても、比較単位が明確で、状態と操作が伝わり、高密度な監視課題に合う場合があります。境界線が少なくても、距離と見出しの関係が曖昧なら構造は伝わりません。

「四角が多い」は観察です。問題仮説にするには、何の階層が競合し、どの課題を妨げるかを書きます。

5.5 モーダルを前景化する表現と、操作上のモーダル性

発展――知覚の比喩だけで実装を決めないための HCI 節です

モーダルダイアログを開くと、ダイアログが前景に置かれ、元のページは背景の覆いで暗くなることがあります。背景の覆いの明度差、ダイアログの影、位置、周囲の遮蔽は、ダイアログを前景として見る手がかりになります。

モーダルの前景・背景・操作規則を示す図。 — 図 5-5　モーダルの前景・背景・操作規則

しかし、背景の覆いが暗いことと、操作がモーダルであることは別です。

視覚的な前景化

背景の覆いの明度・色
ダイアログと背景のコントラスト
影や輪郭
位置と大きさ
背景のぼかし

これらは前景と背景の分離へ関わります。ただし、背景の覆いを濃くすれば必ず重要に見える、ぼかせば必ず集中できる、という法則ではありません。内容、文化、テーマ、表示環境も関わります。

モーダルな操作契約

開いたとき、適切な要素へフォーカスが移る
Tab／Shift+Tab でダイアログ内を操作できる
外側の内容が操作不能になり操作できない
Escape または明示的なボタンで閉じられる
閉じた後、原則として開いた要素へフォーカスが戻る
ダイアログにアクセシブルネームがある
背景スクロールとダイアログ内スクロールを意図どおり扱う

aria-modal="true" や背景の覆いだけで、これらが自動的に実装されるとは限りません。aria-modal は支援技術へモーダルであることを伝える状態であり、外側を実際に操作不能にしたりフォーカスを管理したりする実装ではありません。ネイティブの dialog.showModal() はトップレイヤーへの配置、モーダル状態、外側の操作不能化などをブラウザが扱う基準候補です。トップレイヤーは単に非常に大きな z-index を指定した状態ではありません。

制作者は、開いた要素、アクセシブルネーム、内容に合う初期フォーカス、閉じるボタン、cancel／close イベントへの方針、破壊的操作の安全性、閉じた後の作業の流れを設計します。フォーカスは通常、開いた要素へ戻しますが、開いた要素が消えた場合や次の作業点が明確な場合は論理的な別位置を選びます。Escape による閉じる要求を許すか、未保存内容をどう扱うかも明記します。

図 F05 では、背景の覆い／影／ぼかしを比べる視覚系列と、ポインター／キーボード／支援技術で開閉する操作系列を別図にします。視覚系列は前景報告、操作系列はフォーカス、外側操作、閉じる、復帰を測り、同じ「集中できた」へまとめません。

フォーカス位置は常に最初のボタンではない

短い確認なら主要または安全な操作へフォーカスする案があります。長い説明やリストを先に理解する必要があるなら、先頭の静的な見出しへ tabindex="-1" を与えてフォーカスする案があります。不可逆な削除では、最も破壊的でない操作を初期フォーカスにする案もあります。

一つの固定手順ではなく、ダイアログの内容と課題から決め、ポインター、タッチ、キーボードのみ、スクリーンリーダー＋キーボードを別シナリオで確かめます。長文ダイアログでは、ダイアログ内部だけを意図どおりスクロールでき、背景は操作中にスクロールせず、閉じた後に元の背景位置へ戻ることを期待値として記録します。モバイルのビューポートは別条件にします。入れ子のダイアログは基準から除外します。

5.6 見えている構造を重ねて説明しない

境界を加える前に、既に働いている手がかりを書きます。

近接で見えている

ラベルと入力欄が近く、次の項目までが十分に離れているなら、各項目へ個別境界線を追加しなくてもまとまりが見えるかもしれません。

整列で見えている

同じ左端と列を共有する情報は、外周を囲まなくてもリストとして追える場合があります。

類同で見えている

同じ役割のカードが同じ画像比率、タイポグラフィ、配置を反復していれば、共通の外形が弱くても同じ種類として見えるかもしれません。

見出しと意味で見えている

明確な見出し、fieldset／legend、文章の順序が、視覚と支援技術へまとまりを伝える場合があります。

それでも境界が必要な場合

操作対象の範囲を示す
選択、フォーカス、エラーなどの状態を示す
密度の高い情報を比較単位へ分ける
背景との差が小さい領域を識別する
ドラッグ／ドロップの対象を示す
内容が動的に追加・削除される範囲を示す

境界を重ねる前に、目的を一つ書きます。既に別の手がかりで伝わるなら削減候補です。役割や状態を伝える唯一の手がかりなら、単純に消しません。

5.7 境界を消すと失われるもの

「境界線を消すとすっきりする」という変更は、通常のスクリーンショットだけでは成立して見えるかもしれません。状態と表示条件を変えると、失うものが見えます。

入力欄と背景の区別

入力欄の背景が周囲と同じで境界線もなければ、入力位置を見つけにくい場合があります。プレースホルダーだけを境界の代わりにすると、入力後に手がかりが消えます。

ボタンの操作範囲

文字だけのボタンは文脈によって成立しますが、隣接する文字やリンクと区別できる必要があります。見える外形と操作領域は別なので、境界線を残せば対象サイズが十分になるわけでもありません。

フォーカスと状態

通常の境界線を消しても、明確なフォーカス表示が別にあればキーボードフォーカスは示せます。反対に、フォーカス時の境界線まで消せば現在位置を失う可能性があります。選択中、エラー、無効も別状態として確認します。

コントラスト

WCAG の文字以外のコントラストは、すべての装飾境界線に一律の比率を要求するものではありません。利用者が部品や状態を識別するために必要な視覚情報が対象になります。どの境界が必要情報かを特定し、隣接色とのコントラストを確認します。

強制色

制作者の背景や影が置換・抑制される環境では、通常テーマで成立した面の差が失われる場合があります。システム色、境界線、文字、ネイティブ部品を使い、Windows 強制色の実環境でも確認します。

アクセシビリティは、境界を増やす理由の一覧ではありません。誰が、どの環境で、何を識別し、何を操作するかという条件です。

5.8 問い――このカードには何枚の枠が必要か

文化祭の予約確認画面を観察します。セクション、予約内容カード、各項目、エラーメッセージ、主要操作に境界があります。

章末――このカードには何枚の枠が必要かを示す図。 — 図 5-8　章末――このカードには何枚の枠が必要か

観察条件

人：初めて予約内容を確認し、間違いがあれば修正する人
課題：日時、会場、人数を確認し、誤った人数を修正して予約する
基準：1280 CSS px、マウス、通常状態
派生：390 CSS px、キーボードフォーカス、エラー、Windows 強制色を一軸ずつ

本章の操作モデルでは、日時、会場、人数は静的な確認文字として表示し、各項目に独立した「変更」ボタンを置きます。人数の変更ボタンを押すと、人数入力と保存／キャンセルを持つ編集領域が開きます。カード全体はクリック可能にしません。エラー文は人数入力へプログラム上も関連づけ、状態変化の通知とフォーカス位置を検証します。

問い

画面に見える境界を数え、それぞれが何を分けるか書いてください。
境界がなくても構造を示している手がかりは何ですか。
閉合、共通領域、図と地のどれで説明できる現象ですか。説明できないものは何ですか。
一つだけ境界を除く、または加えるならどれですか。
変更によって何が見えやすくなり、何を失う可能性がありますか。
知覚、課題、操作、実装でどう確かめますか。

答えの例

1. 境界と関係を指す

ページ背景と予約セクションの面差、予約カードの境界線、カード内の各項目境界線、エラーの境界線、主要操作の外形があります。予約カードの境界線は予約内容全体を、項目境界線は日時・会場・人数を個別に分けています。

2. 既存の手がかりを見る

各項目は見出しと値が近く、次項目までの距離が広いです。見出しのタイポグラフィと左端も反復しています。項目境界線がなくても、近接、整列、類同から三項目の境界が見える可能性があります。

3. 概念を限定して使う

予約カードの同じ面色と外周は、カード内要素を共通領域としてまとめる説明候補になります。項目境界線を外してもカードの形が閉合によって補われる、と断定する必要はありません。モーダルではないため、図と地だけで予約確認の操作を説明することもできません。

4. 一つの変更仮説

予約カードとエラー境界線は固定し、通常項目の個別境界線だけを除くと、予約全体とエラーの境界を保ちながら、階層の競合を減らせるのではないか。

5. 失うものを残す

項目と独立した変更ボタンの所属が分かりにくくなる可能性があります。カード全体は操作できないという規則を保ち、変更ボタンの範囲、文言、ホバー、フォーカス、アクセシブルネームを確認します。人数のエラー状態で、エラーの所属が距離と文言から伝わるかも見ます。

6. 確かめ方

知覚課題では、どこからどこまでを一つのまとまりとして見たかを記録します。確認課題では、日時・会場・人数を正しく読み、誤った人数を発見できたかを主要指標にします。修正課題では、編集操作を見つけて予約を完了できたかを主要指標にし、誤操作と時間を補助指標にします。

マウス、タッチ、キーボードを別試行にします。キーボードではフォーカス順と表示を確認します。エラー状態では、入力とのプログラム上の関連、状態メッセージなどによる通知、エラー発生時にフォーカスを移すか維持するかを分けます。強制色では面色が変わっても境界と操作を識別できるかを実環境で確認します。基準と派生状態を同時に変えません。

境界を減らす判断表には、線、面、影、空間を分けて実際の結果を残します。

条件	線／面／影／空間	変更する境界	失う可能性	確認指標
予約確認・通常	見出し、距離、カード外周	項目境界線を除く	変更ボタンの所属	項目確認、変更操作
人数エラー	エラー文、アイコン、関連づけ	エラー境界線は残す	色置換時の識別	エラー発見、修正完了
390px	一列順序、見出し	面差を弱める案	セクション境界	スクロール後の再定位
強制色	文字、システム色、境界線	制作者の影に依存しない	面によるまとまり	部品／状態の識別

表現意図も別欄に残します。静かな文化施設の案、速報性を持つイベント案、高密度な業務案では、同じ情報階層でも線質、面積、空間、影の調子が異なり得ます。機能条件だけで造形案を一つに決めません。

別の答え方

高密度な業務画面なら、項目境界線を残す方が比較しやすい場合があります。境界線を消す代わりに、予約カードの背景差を弱め、項目の列構造を強くする案もあります。

エラー境界線が他の通常境界線と似すぎているなら、通常境界線を減らすことでエラーを見つけやすくなる可能性があります。一方、色だけに依存せず、エラー文とアイコン、関連づけ、フォーカスも必要です。

よくある考え方

カードが多くてダサいので、境界線と影を全部消します。

この考え方の注意点

どの境界が何を分け、何が既に別の手がかりで伝わり、何を失うかが書かれていません。すべてを一度に消せば、どの変更が結果に関係したかも分かりません。

次のように書きます。

項目境界線と予約カード境界線が同じ強さで、項目と予約全体の階層差が外形に表れていない。カード境界線とエラーは固定し、通常項目境界線だけを除くと、近接と見出しで項目を保ちながら、予約全体の境界を強く読めるのではないか。

必須セルフチェック

見える境界と、それが分ける関係を指したか
閉合、共通領域、図と地を区別したか
境界を一つだけ変え、知覚・課題・操作への影響を確かめたか

発展セルフチェック

境界線、背景、影、間隔を同じ「枠」にしていないか
実装コンテナのすべてを視覚化していないか
カードのまとまりとクリック可能範囲を分けたか
モーダルの背景の覆いと操作上のモーダル性を分けたか
フォーカス、エラー、200% 文字、強制色を確認したか
境界を減らすこと自体を美的正解にしていないか

次章へ

境界や面は、構造を示す静的な手がかりです。しかし、画面内で何かが動けば、境界の強さに関係なく注意を奪う場合があります。動きは状態変化や空間関係を伝える一方、自動再生や反復によって課題を妨げる可能性もあります。

次章では、動きの有無ではなく、面積、速度、距離、方向、反復、目的を分けて観察します。

参考資料

入口: York University, “Max Wertheimer, Laws of Organization in Perceptual Forms（英訳）.” 閉合を含む古典的な知覚的組織化の原典英訳です。
発展: Johan Wagemans et al., “A Century of Gestalt Psychology in Visual Perception I,” 2012. 閉合、輪郭や面の補完、図と地を含むレビューです。
論文: Stephen E. Palmer, “Common region: A new principle of perceptual grouping,” 1992. 共通領域を近接や閉合から区別した研究です。
仕様: WHATWG, “The dialog element.” ネイティブダイアログ、showModal()、トップレイヤー、操作不能状態などの定義を確認します。
技法: W3C WAI, “H102: Creating modal dialogs with the HTML dialog element.” HTML dialog を使ったモーダルの技法です。WCAG の唯一の必須実装ではありません。
パターン: W3C WAI-ARIA APG, “Dialog (Modal) Pattern.” フォーカス、キーボード、役割の実務的な参考です。規範的標準そのものではありません。
公式解説: W3C WAI, “Understanding Non-text Contrast.” 部品と状態を識別する視覚情報のコントラストを確認します。
仕様: W3C, “CSS Backgrounds and Borders Module Level 3.” 背景、境界線、影の仕様です。

検索キーワード：閉合知覚、amodal completion occlusion、common region perceptual grouping、figure ground organization、HTML dialog showModal inert、modal dialog focus management、non-text contrast border

第6章　人間は、動いたものを見てしまう

画面の端で何かが動くと、読んでいた文章から注意が移ることがあります。ボタンを押した直後の変化なら、その動きは結果を理解する助けになるかもしれません。広告が反復して揺れているなら、目的の情報を探す妨げになるかもしれません。

ただし、「動いたものを見た」「注意が移った」「内容を理解した」「作業が遅れた」「身体的に不快だった」は同じ出来事ではありません。視線が向いても意味を理解したとは限らず、目立つ動きがいつも課題を妨げるとも限りません。

本章では、アニメーションを良いか悪いかで裁く前に、何が、いつ、どのように動き、何を伝えようとしているかを観察します。

本章でいう「動き」には、位置の移動だけでなく、拡大縮小、回転、透明度や色の時間変化、突然の出現、動画、自動スクロールを含めます。利用者が操作するスクロール、操作に続く画面遷移、自動で反復するアニメーション、映像コンテンツは条件が異なるため、観察時には種類を記します。

この章の必修は三つです。

動いた要素、開始時点、面積、距離、時間、反復等を指して説明する
動きが伝える状態・因果・位置関係と、副作用を分ける
通常、動きを減らした状態、静止状態を比べ、注意・理解・課題・不快感を別々に確かめる

この章で見るもの

既にある物体が動き始めることと、新しい物体が突然現れること

動きの面積、距離、時間、速度変化、方向、反復、位置

アニメーションが伝える状態、因果、空間的位置

自動で切り替わるカルーセルと利用者の操作権

スケルトン UI が示すもの、示さないもの

横方向という一語に隠れた複数の条件

動きを減らす設定と、意味を保つ代替表現

6.1 視野の端の動きに振り向く

駅で案内板を読んでいるとき、視野の端を自転車が横切れば、そちらへ注意が移ることがあります。環境の変化へ素早く気づくことには意味があります。一方、画面上では、読む課題と関係のない動きも同じ視野へ入ります。

研究では、静止していた物体が動き始める Motion Onset が、一定の実験条件で注意を捕捉し、標的の識別時間へ影響することが示されています。しかし、実験室の単純な刺激で生じた反応時間差を、そのまま「Web のアニメーションは必ず注意を奪う」という規則にはできません。動きが課題に関係するか、何を探すよう指示されたか、刺激が新しい物体か、既存物体かなどで結果は変わります。

視野端の Motion Onsetを示す図。 — 図 6-1　視野端の Motion Onset

図 F01 では三つを分けます。

既に見えていた物体が動き始める
物体が突然現れる
読者が探している対象自体が動く

新しい物体の突然の出現は Abrupt Onset として研究されてきました。Motion Onset と似た結果に見える場合があっても、刺激は同じではありません。Web では、トースト通知が現れると同時に移動するなど、複数の変化が重なりがちです。何が注意へ影響したかを考えるなら、出現、移動、色変化、拡大を一度に変えない比較が必要です。

注意を向けさせる必要がある場合

動きによる注意誘導が、利用者の目的に合うこともあります。送信後に結果が追加された場所、Drag した項目の移動先、通信中から完了へ変わった状態などです。重要なのは、目立ったかだけでなく、利用者が「何が起きたか」を説明できるかです。

観察は、次のように書けます。

記事を読んでいる間、右端の告知が約 3 秒ごとに上下した。告知へ視線が向いたかは未確認だが、本文と無関係な反復する動きが周辺視野に存在する。

「気が散るアニメーションだ」は評価です。まず、位置、開始、反復、課題との関係を記録します。

6.2 動きの経験を形づくる複数の変数

「もっとゆっくり」「横移動は強い」といった言葉だけでは、動きの条件を再現できません。速度は、移動距離と時間の関係から生まれます。同じ時間で遠くまで移動すれば速くなり、同じ距離でも時間を延ばせば遅くなります。

動きを観察するときは、少なくとも次を分けます。

観点	観察すること
面積	動く領域はアイコンだけか、画面全体か
距離	開始位置から終了位置まで何 px、画面幅の何割か
時間	何 ms 続くか、いつ始まるか
速度変化	一定か、加速・減速するか
方向	上下、左右、奥行きを模した拡大縮小か
反復	1 回か、周期的か、終わりがないか
視野位置	操作対象の近くか、周辺か
同時数	ほかにいくつ動いているか
時間構成	始まるまでの間、要素間のずれ、重なり、周期
軌跡	直線、曲線、往復、画面外を通るか

一つの値だけから強さは決まりません。短距離の小さな状態変化と、画面全体が同じ時間で移動する画面遷移では、面積も空間的位置の変化も異なります。遅い動きでも反復し続ければ、読書中に何度も現れます。

一度に一つだけ変える

距離の影響を比べたいなら、面積、時間、方向、反復を固定します。時間を固定して距離を変えれば速度も変わるため、「距離だけを変えた」とは言えません。厳密な実験でなくても、何が連動して変わったかを記録すると、比較の解釈が良くなります。

次の四つも別々に尋ねます。

動きに気づいたか
探していた対象を見つけられたか
状態変化の意味を説明できたか
不快または避けたいと感じたか

これらを一つの「疲れる」へまとめると、改善対象が分からなくなります。

身体的不快を無理に再現しない

不快感を確かめるために、参加者へ強い動きを耐えさせてはいけません。軽減設定を尊重し、内容を事前に伝え、いつでも即時停止・離脱でき、完全な動きを見ない経路を用意します。不快を申告した人へ同じ刺激を再提示しません。本書の比較から医学的な安全閾値を推定しません。

6.3 アニメーションは何を伝えるためにあるか

アニメーションは、時間とともに画面の属性を変える表現です。フィードバックは、操作やシステムの結果を利用者へ返すことです。両者は重なることがありますが、同じではありません。色や文言が即座に変わるだけでもフィードバックになり、動いていても操作結果を何も伝えない場合があります。

動きの目的を、次の候補から考えます。

状態変化

メニューが閉じた状態から開いた状態へ変わる、保存中から保存済みへ変わるなどです。開始と終了の状態が識別できることが先で、アニメーションだけに状態を担わせません。

因果

押したボタンからダイアログが開いた、削除した項目がリストから消えたなど、操作と結果の関係をつなぎます。動きが長すぎると、因果を示す前に待ち時間になる可能性があります。

空間的定位

いま見ていたページが左へ退き、次のページが右から入る表現は、情報空間の隣接を示すことがあります。しかし、実際の情報構造と方向が一貫しなければ、位置関係を誤って教えるかもしれません。

注意誘導

更新された行やエラーの位置へ注意を導きます。エラーを揺らすだけでなく、文言、色以外の印、フォーカス、読み上げなども必要です。

装飾

雰囲気やブランドの調子を作ります。装飾であることは、無価値という意味ではありません。ただし、課題に不可欠な動きと違い、利用者が減らしたいときに残す必要性は低いかもしれません。

一つのアニメーションが複数の目的を持つこともあります。目的を名付けた後は、「その意味は静止した最終状態からも分かるか」「同じ意味を、より小さい面積や短い距離で保てるか」を考えます。

機能目的と表現目的

同じ状態変化でも、動きの間、リズム、軌跡、要素同士の同期によって、静か、軽快、重い、祝祭的といった印象が変わります。これは状態伝達とは別の表現目的です。「装飾だから不要」と切り捨てず、伝える意味、課題への副作用、ブランド表現との適合を別々に評価します。読み方向や「先へ進む方向」の慣習も言語、文化、製品内の規則によって変わり得ます。

動きの約束を書く

実装値を決める前に、動きの契約を一行ずつ書きます。

開始状態 → きっかけ → 変化 → 終了状態 → 途中で再操作された場合 → 軽減時の代替

メニューなら、「閉じている→メニューボタンを押す→パネルが現れる→開いた状態とフォーカスが確立する→再操作なら閉じる→軽減時は移動せず即時表示」と書けます。アニメーションの終了イベントだけに処理完了を依存させず、動きが無効でも状態とフォーカスが成立するようにします。

方向の意味も固定しません。日本語横書きで右から入るパネルが「次」を示していても、右から左へ読む言語や縦書き、別の製品内規則では同じ解釈にならない可能性があります。内容の論理順序と画面上の移動方向を一緒に確認します。

6.4 カルーセルと自動再生が奪うもの

カルーセルには、限られた場所へ複数の内容を置ける利点があります。一方、自動切替は読む時間と画面の主導権をシステム側で決めます。読了前に切り替わる、戻ったスライドを再発見できない、キーボードフォーカス中に内容が変わる、といった問題が起こり得ます。

カルーセルの読む速度と操作権を示す図。 — 図 6-4　カルーセルの読む速度と操作権

図 F04 では、自動切替なし、5 秒、10 秒、利用者が操作した後に停止する条件を比べます。ここで 5 秒を推奨値にはしません。見出しの長さ、読者の言語能力、画像の理解、拡大表示、支援技術等によって必要時間は異なります。

WCAG 2.2 の達成基準 2.2.2 は、自動で始まり、5 秒を超え、他の内容と並行して動く情報などについて、一時停止・停止・非表示の仕組みを求める条件を定めています。この 5 秒は「5 秒以下なら使いやすい、安全」という意味ではありません。点滅には別の達成基準があります。

カルーセルを見るときは次を確かめます。

自動で始まるか、停止できるか
前後へ移動でき、現在位置が分かるか
キーボードで操作でき、フォーカスが見えるか
フォーカス中やホバー中にも勝手に切り替わるか
スライドの変更が支援技術へ過剰に通知されないか
3 枚目を見た後、同じ内容へ戻れるか
最重要情報を隠してまでカルーセルにする理由があるか

測定も分けます。見出しを読み終えられたか、目的のスライドを見つけたか、申込ボタンを操作できたか、再び見つけられたかは別の課題です。「カルーセルを見た人が少ない」だけでは、動き、位置、内容、計測方法のどれが原因か決まりません。

比較ではスライドの文章、画像、順序を固定し、条件の提示順を入れ替えます。自動切替を止める操作、フォーカスやホバーでの停止、利用者が前後操作した後に再開しない状態を条件として定義します。現在のスライドだけを適切に通知し、自動更新を読み上げ続けないことも確認します。

6.5 スケルトン UI は待ち時間を短くするのか

通信中に最終レイアウトに似た灰色の形を出すスケルトン UI があります。何もない画面より、これから現れる情報の位置を予告できる場合があります。しかし、スケルトンは進捗率を示しません。半分の形が埋まっていても、処理が 50% 終わったとは限りません。

「待ち時間が短く感じる」を一つの事実として扱わず、次を分けます。

ネットワークや処理に要した実時間
利用者が推定した時間
進行していると理解できたか
待ち続けたか、離脱したか
最終レイアウトを正しく予測できたか
読み込み後にレイアウトが大きく移動したか

実時間はパフォーマンス計測で確認できます。知覚された時間は利用者の報告、待機継続は行動です。スケルトンにしただけで通信は速くなりません。

光が流れるスケルトンは、処理が止まっていない印象を与えるかもしれませんが、反復する動きでもあります。静止スケルトン、スピナー、進捗率を示せる進捗表示、何も表示しない条件を、同じ実時間で比べます。短い処理では、ローディング表示が一瞬だけ現れることで、かえってちらついて見える場合もあります。

最終内容とスケルトンの形が大きく違えば、予告としての意味は弱くなります。ローディング中の仮の見た目ではなく、どの情報が読み込み中か、失敗時に何が起きるか、再試行できるかまで状態として設計します。

既に内容がある更新では、それを消してスケルトンへ戻すより、古い内容を保って「更新中」と示す方が課題を続けやすい場合があります。0 件、部分成功、失敗、再試行、逐次表示も別状態です。aria-busy などで領域の更新中状態を伝えることと、真の進捗値を示す progressbar を混同しません。詳細は第14章で扱います。

6.6 横方向の移動は本当に疲れるのか

「横スクロールは疲れる」「横移動は人間に不自然だ」と方向だけで結論づけることはできません。横方向のカード列、ページ遷移、横書き文章を画面ごと移動させる表現は、同じではありません。

横方向の体験には、少なくとも次が含まれます。

移動距離と回数
自動か、利用者の操作か
タッチ、ホイール、キーボードなどの入力方法
視線で追う必要があるか
内容の読む順序と方向が一致するか
次の項目が一部見え、続きが予測できるか
Snap によって意図しない位置へ移動しないか
画面幅と表示項目数
元の位置を再発見できるか

方向の影響を知りたいなら、縦方向との比較で距離、時間、内容、入力、反復などをそろえる必要があります。実務では完全にそろえられなくても、「横だから」以外の代替仮説を挙げられます。

たとえば横カード列で目的の出演者を見つけにくいとき、見えていない項目数、スクロール可能性の手がかり、カードの類似、現在位置、並び順、入力装置が関係しているかもしれません。改善案も、縦並びに変えるだけでなく、検索、分類、件数表示、前後コントロール、一覧へのリンクなどが考えられます。

なお、利用者が操作する横スクロールと、画面が自動で横へ移動するアニメーションを混同しません。前者は探索構造と入力、後者は時間変化と注意の問題を持ちます。

キーボードフォーカスが画面外へ移動しないか、移動後も見えるか、右から左へ読む言語や縦書きで順序が保たれるかも確認します。

6.7 `prefers-reduced-motion` と動きの代替

OS などで、不要な動きを減らしたい設定を表明できる場合があります。CSS の prefers-reduced-motion メディア機能は、その要求を検出するためのものです。

動きを減らす設定と意味の代替を示す図。 — 図 6-7　動きを減らす設定と意味の代替

@media (prefers-reduced-motion: reduce) {
  .page-transition {
    animation: none;
  }
}

これは出発点です。アニメーションを消した結果、状態や因果まで消えていないかを確認します。メニューなら開閉状態を即座に反映し、ローディングなら文言や進捗を残し、エラーなら揺れ以外の印と説明を示します。

reduce は「すべてのアニメーションを必ずゼロにする」という値ではありません。不要な動きを最小化する要求です。短いフェードへ置き換えることもありますが、フェードも時間変化であり、誰にとっても安全な万能代替とは決めません。面積、距離、拡大縮小、反復を減らし、意味を別の手がかりで保ちます。

反対に、no-preference は「派手な動きへ同意した」という意味ではありません。利用者が軽減要求をシステムへ表明していない状態です。通常状態でも、目的のない反復や大面積の移動を無制限にしてよい根拠にはなりません。

検証では、開発者用の切替だけでなく、可能なら実際の OS 設定と複数ブラウザで確認します。JavaScript が動かない状態、印刷、キーボード操作、支援技術での状態通知も見ます。

CSS 以外の Web Animations API、Canvas、SVG、動画でも軽減条件を確認します。transitionend や animationend を、状態更新やフォーカス移動の唯一の条件にしません。

6.8 動きを止めて比較する

動きは、再生したままでは複数の差を同時に追いにくい対象です。まず実時間で見た後、低速再生し、開始・中間・終了フレームへ止めます。

次の順で観察します。

実時間で、最初に気づいたことを記録する
0.25 倍などで、変化するプロパティと同時に動く要素を見る
開始・中間・終了フレームを横に並べる
境界ボックスの軌跡、距離、面積を重ねる
動きなしの最終状態と比べる
一つの変数だけ変えて再生する

ブラウザの開発者向け機能や Web Animations API から、継続時間、遅延、イージング、反復などを確認できます。ただし、開発者向け機能の名称や場所はブラウザと版によって変わります。値を見る前に、どれくらいの時間・距離かを予想すると、知覚と実装値を接続できます。

録画やフレーム列は、何が変化したかを調べる資料です。それだけで、利用者がどう知覚し、課題成績や不快感がどう変わるかを測定したことにはなりません。

仕様上の 300ms が、いつも滑らかな 300ms として経験されるわけでもありません。メインスレッドの処理、フレーム落ち、入力への応答遅延、レイアウトシフトを実機で記録し、設定値、記録上の時間、利用者が待った時間を分けます。

6.9 問い――文化祭の画面で動きを見る

文化祭 Web サイトのトップページを使います。上部に自動カルーセル、出演者欄に光が流れるスケルトン、メニューに画面幅いっぱいの遷移、フィルター保存後にトースト通知があります。

次の課題を一つずつ行います。

開催日時を読む
特定の出演者を探す
絞り込み条件を保存する

基準条件

初見の利用者を想定し、390px 幅、キーボード操作、通常の動き設定、カルーセルは 1 枚目、通信待ち 5 秒から始めます。次に、一度に一軸だけ、1280px 幅、ポインター操作、reduce、静止、待ち 2 秒または 10 秒へ変えます。四つの動きは個別切替で一つずつ有効にし、同時再生を基準比較にしません。身体的不快の比較には、前述の停止・離脱・非曝露の手順を適用します。

問い

何が、いつ、どの範囲で動くか
それぞれの動きは何を伝えようとしているか
課題と関係のない動きは何か
動きを止めると失われる意味は何か
通常、軽減、静止の三条件で何を測るか

答えの例

開催日時を読んでいる間にも、画面上部のカルーセルが 10 秒ごとに画面幅の約 70% を横移動する。日時の理解を助ける動きではない。読了前の切替、注意の移動、元のスライドの再発見へ影響する可能性がある。自動切替を止めた条件で、日時の読み誤りと完了時間を比べたい。

フィルター保存後のトースト通知は、操作結果を知らせる目的がある。ただし、右端から大きく移動する必要があるかは別である。まず文言、位置、表示時間を固定し、移動距離だけを 16px、0px と変える。次の比較で、移動距離を固定して表示位置を保存箇所の近くへ変える。完了の理解と不快感を分けて確認する。

別の答え方

問題は動きの強さではなく、開催日時の視覚的階層が弱く、カルーセルの近くに置かれていることかもしれません。カルーセルを止めても日時を見落とすなら、位置、見出し、コントラストなどの仮説を調べます。

スケルトンによる待機離脱が少ないとしても、知覚時間が短くなったとは限りません。最終レイアウトが予測できた、処理中と理解できた、単に実時間が短かった、という別の説明があります。

四つの動きへの回答例

動き	観察	目的候補	副作用の仮説	軽減・静止代替	確認
カルーセル	10 秒ごとに画面幅 70% を横移動	内容切替、注意誘導	日時の読了前に注意が移る	自動切替を止め、前後ボタンを残す	読み誤り、再発見、完了時間
光が流れるスケルトン	出演者欄全体を光帯が反復	更新中、レイアウト予告	探索中も周辺の動きが続く	静止スケルトン＋更新中文	状態理解、推定時間、離脱、レイアウトシフト
メニュー遷移	全幅パネルが右から左へ移動	開閉、空間関係、表現	大面積移動、フォーカス確立の遅れ	パネルを即時表示し、開閉状態とフォーカスを保つ	メニュー発見、項目選択、状態説明
トースト通知	保存後に右端から入り 4 秒後消える	保存完了のフィードバック	読む前に消える、移動が過剰	保存箇所近くの静止状態＋履歴	完了理解、再確認、フォーカス／読み上げ

よくある考え方

アニメーションが多くて疲れる。全部消した方がよい。

注意点

どの動きの、どの変数が、どの課題または身体反応に関係するかが書かれていません。状態や因果を伝えているアニメーションまで消すと、操作結果が分からなくなる可能性があります。まず各動きの目的と副作用を分けます。

必須セルフチェック

動いた要素、開始、面積、距離、時間、反復を観察の言葉で書ける
状態・因果・空間・注意・装飾という目的候補と、副作用を分けられる
通常・軽減・静止を比べ、注意・理解・課題・不快感を別々に確かめられる

発展セルフチェック

動きの約束に、再操作、軽減時、低性能時の終了状態を書ける
カルーセル、スケルトン、横スクロールの問題を方向や秒数だけで説明していない
不快感を再現させない安全な観察手順を用意できる

参考

Abrams, R. A. and Christ, S. E. (2003), “Motion Onset Captures Attention,” Psychological Science, 14(5), 427–432, DOI: 10.1111/1467-9280.01458. 動き始めと注意捕捉を扱う原著です。https://doi.org/10.1111/1467-9280.01458
Smith, K. C. and Abrams, R. A. (2018), “Motion onset really does capture attention,” DOI: 10.3758/s13414-018-1548-1. Motion Onset をめぐる追試と条件を確認できます。https://pubmed.ncbi.nlm.nih.gov/29971749/
“Attentional Capture by Abrupt Onsets: Foundations and Emerging Issues.” Abrupt Onset 研究の議論と条件を整理した Review です。専門的です。https://pmc.ncbi.nlm.nih.gov/articles/PMC11908675/
W3C WAI, Understanding Success Criterion 2.2.2: Pause, Stop, Hide. 自動で動く情報の達成条件を確認する公式解説です。https://www.w3.org/WAI/WCAG22/Understanding/pause-stop-hide
W3C WAI, Understanding Success Criterion 2.3.3: Animation from Interactions. 操作で生じる動きと軽減についての公式解説です。https://www.w3.org/WAI/WCAG22/Understanding/animation-from-interactions.html
W3C, Media Queries Level 5: prefers-reduced-motion. メディア機能の正確な定義を確認できます。https://www.w3.org/TR/mediaqueries-5/#prefers-reduced-motion
W3C WAI, Carousels Tutorial. 構造、コントロール、キーボード、通知を実装例とともに確認できます。https://www.w3.org/WAI/tutorials/carousels/
W3C, Web Animations Level 1 / CSS Animations Level 1. アニメーションの時間モデルと CSS の定義を調べる仕様です。https://www.w3.org/TR/web-animations-1/ https://www.w3.org/TR/css-animations-1/
W3C, CSS Overflow Module Level 3 / CSS Scroll Snap Module Level 1. 横スクロールの仕組みとスナップを確認する仕様です。疲労の一般則を示す資料ではありません。https://www.w3.org/TR/css-overflow-3/ https://www.w3.org/TR/css-scroll-snap-1/
W3C WAI-ARIA APG, Carousel Pattern. カルーセルの役割、状態、コントロールを調べる実装パターンです。https://www.w3.org/WAI/ARIA/apg/patterns/carousel/

SC 2.3.3 は WCAG 2.2 の AAA 達成基準です。点滅による発作リスクは別の達成基準で扱われるため、「動きを減らしたから点滅も確認済み」とは考えません。スケルトン UI の知覚時間と横方向の疲労については、本章で無条件の一般則を採用していません。

検索キーワード: motion onset attention capture、abrupt onset visual attention、carousel accessibility pause、skeleton screen perceived waiting time、prefers-reduced-motion、vestibular motion web accessibility

第7章　人間は、文字の形から声を聞く

同じ「ようこそ」という言葉でも、細く静かな文字、太く角張った文字、手で書いたような文字では、受ける印象が変わることがあります。文章の意味は同じでも、文字の形、間隔、大きさ、配置は、話し方の調子のようなものを画面へ加えます。

本章の「声を聞く」は比喩です。文字を見ると実際に音声が聞こえる、書体と性格が一対一に対応する、という心理学的定義ではありません。書体から受ける印象を、曖昧な「雰囲気」で終わらせず、どの形と組み方がそう感じさせたのかを観察するための言葉です。

この比喩で書体を人間の性格へ固定しないため、本章では「文字の調子」「表現上の印象」とも言い換えます。声の性別、年齢、階級等を字形へ安易に割り当てません。

タイポグラフィは書体選びだけではありません。字形、サイズ、太さ、行間、行長、揃え、段落、階層、言語、読み込み中の代替表示まで含む、文字を画面で働かせる設計です。

この章の必修は三つです。

文字の印象を、字面、骨格、太さ、空間、端部等の観察へ戻す
文字識別、文章を読み続けること、理解、好みを分ける
意味構造、表示環境、フォント読み込みが変わっても読めるかを確かめる

この章で見るもの

同じ言葉に異なる調子を感じるとき、文字のどこが違うか

文字の外形、骨格、線幅、内側の空間、端部

読めることと、読み続けられること

見出しの意味構造と、見た目の階層

日本語、欧文、数字、アイコンが共有する線と、共有しない尺度

Web フォントが届く前、届いた後、届かなかったとき

書体の印象を普遍的な性格表へしない方法

7.1 同じ言葉でも、同じ声には見えない

文化祭の入口に「ようこそ、まちの文化祭へ」と書かれています。一方は線が細く、文字間が広く、余白の中へ小さく置かれています。もう一方は太く、字間が詰まり、画面幅いっぱいに置かれています。

言葉は同じでも、前者を静か、後者を力強いと感じる人がいるかもしれません。しかし、「細い書体＝静か」「太い書体＝力強い」という辞書を作るのは早すぎます。Size、面積、配置、周囲の画像、言葉の意味も同時に違えば、書体だけの影響ではありません。

図 F01 では、最初に書体名と用途を隠します。印象語を一つ書いた後、根拠にした形の場所を指します。

比較は二段階です。第 1 段階では同じ CSS のサイズ、ウェイト値、行長で機械的にそろえ、見かけの字面や黒みがそろわないこと自体を観察します。第 2 段階では、見かけの大きさ、黒み、行長を調整し、調整値と理由を公開します。見た目に合わせて調整した結果を「書体だけを変えた実験」とは呼びません。

丸いから親しみやすい。

ここから、さらに観察を進めます。

「よ」と「こ」の曲線が大きく、線端の角が目立たない。文字の内側の空間が広く、隣の文字との間も広い。この形が、私には柔らかい印象と関係して見えた。

後者なら、別の人が検証できます。どの Glyph の、どの部分を見たかが残るからです。

次に同じ書体を、文化祭の歓迎、医療手続の警告、請求書の謝罪へ置きます。用途が変わると印象も変わるかもしれません。書体の印象は形だけから自動的に出るのではなく、読んだ言葉、使われた場面、その書体を過去にどこで見たかとも関係します。

書体へ人格を感じること自体を誤りとはしません。研究でも、書体に異なる人格的印象が評定される例があります。ただし、研究で使った書体、言語、参加者、評定語を越えて普遍化しません。

7.2 字面、骨格、太さ、コントラスト

「このフォントは丸い」と言うとき、何を見ているのでしょう。文字全体の輪郭、線の曲がり方、角、線端、内側の空間は別々に観察できます。

字面

ここでは、フォントの設計領域の中で、文字が実際に占める見かけの大きさを指す実務語として使います。同じ font-size: 16px でも、見える文字の大きさが同じとは限りません。CSS の em Box、フォントメトリクス、実際の文字外形を区別します。

骨格

線の太さをいったん除いて見た、字形の基本的な構造です。同じ文字でも、曲線の張り、払い、交差、開き方が異なります。骨格は画面上に一本の実線として存在するわけではなく、字形を比較するための設計上の見方です。

太さとウェイト

CSS の font-weight: 700 は、すべてのフォントで同じ物理線幅を意味しません。フォントファミリー内の書体、可変フォントの軸、フォント選択、合成によって結果が変わります。見た目の太さを比べるなら、CSS 値だけでなく、文字のどの線が何 px に描画されたかを拡大して見ます。

線幅のコントラスト

一つの文字内で、太い線と細い線にどれほど差があるかです。太さの平均とは別です。高いコントラストが必ず上品、低いコントラストが必ず読みやすい、という性格表にはしません。

Counter と開口部

「あ」「e」「8」等の内側にできる空間や、外へ開いている部分を見ます。小 Size、低解像度、太い Weight では空間が狭く見え、似た文字の識別に関わる可能性があります。

Terminal

線の端部です。水平、斜め、丸い、切り落としたような端等があります。セリフの有無だけでなく、どの線がどの形で終わるかを指します。

用語は書体を格付けするためではなく、差の場所を共有するために使います。

書体は歴史と技術から切り離された形ではない

活字、写植、写真植字、デジタルフォント、可変フォントでは、作られ方と使用条件が異なります。セリフ／サンセリフ等の分類も、形を説明する入口の一つであり、時代や地域を越えた性能順位ではありません。本章では通史を扱いませんが、書体名、デザイナー、制作年、対象文字体系、想定用途、技術形式を図版台帳へ残します。

日本語の形を見るときは、欧文用語だけでなく、漢字の点・横画・縦画・払い・はね、仮名の連続性、ふところ、重心、字面、約物のアキ等、対象に合う観察語を使います。定義が揺れる語は、図で指す場所を示します。

7.3 読めることと、読み続けられること

一文字の「8」と「B」を見分けられることと、400 字の案内を読み終え、開催時刻を答えられることは同じ課題ではありません。

本章では作業上、次のように分けます。

識別しやすさ: 文字や語を識別できるか
読み進めやすさ: まとまった文章を読み進められる条件か
理解: 内容を理解できたか
好み: 好ましい、読みやすそうと感じたか

これらの語の範囲は、研究分野や著者によって揺れます。英語名を付ければ測定対象が自動的に明確になるわけではありません。本書では、何をどう測ったかを併記します。

この区別は本書の操作的な整理です。Legibility 研究でも、単一文字、文字列、読書速度等の異なる課題が使われます。Legge and Bigelow のレビューは文字サイズと読書パフォーマンスを扱いますが、その結果を本章の日本語画面へ無条件に移しません。

読めることと読み続けることを示す図。 — 図 7-3　読めることと読み続けること

一つの「読みやすい」へまとめない

大きな文字で一文字を識別しやすくなっても、行長が短くなりすぎ、改行が増えて読み位置を追いにくくなる場合があります。行間を広げれば常に改善するとも限りません。行と行のまとまり、段落の分離、画面内に残る文脈が変わります。

セリフ体とサンセリフ体のどちらが常に読みやすいか、という二択にも還元しません。同じ分類内にも、字面、線幅のコントラスト、字幅、開口部、間隔の異なる多くの書体があります。サイズ、表示装置、言語、読者の経験、課題を記録します。

Size、行間、行長を一軸ずつ比べる

Font Size の影響を見たいなら、Family、Weight、行長、Line Height 等を固定します。ただし、Size を変えると一行に入る文字数が変わります。同じ Box 幅のままなら、改行も連動します。何を固定し、何が連動したかを書きます。

図 F03 では、次を別に測ります。

似た文字の誤読数
指定情報を見つける時間
文章の読了時間
内容質問の正答
読み位置を失った回数
主観的な好みと負担

「読み位置を失った回数」は、参加者が申告して戻った箇所、または観察者が再読を確認した箇所として事前に定義します。読了時間は正答を伴う試行だけも別集計し、速さと理解のトレードオフを隠しません。視線計測がなくても取れる観察と、推定に留まるものを分けます。

対象者の言語、読字経験、視力補正、年齢範囲、利用する支援、表示距離、照明、画面サイズ、DPR、ズームを記録します。少人数の結果を人口全体へ一般化せず、個人データを公開する場合は同意と匿名化を行います。

数字を最適値にしない

WCAG の文字間隔達成基準は、利用者が一定の間隔へ上書きしても内容や機能が失われないことを求めます。そこで示される値は「この行間が全員に最も読みやすい」という推奨値ではありません。

同様に、視覚表現の達成基準にある行長や行間の値は、調整可能性を含む AAA の条件です。日本語本文を必ず 40 字にし、行間を必ず 1.5 倍にするという美的規則ではありません。読者が文字を拡大し、間隔を変えても、切れ、重なり、機能喪失が起きないことを確認します。

7.4 文字の階層が読む順序を支える

文化祭のプログラムページに、催し名、日時、会場、説明、注意、申込ボタンがあります。すべて同じサイズと太さで等間隔なら、どこから読むかを見た目から予測しにくいかもしれません。

文字の階層には、複数の手がかりがあります。

サイズの差
太さの差
明度や色の差
前後の間隔
位置と揃い
書体の差
大文字、小型大文字、約物等の表記

文字組みは個々の字形だけでなく、段落面の形としても見ます。改行位置、行末の凹凸、段落間のアキ、見出しから本文への距離、行が作る密度と輪郭を観察します。広告的な大見出しの表現価値と、日時を探す課題の両方を目的として明記します。

全部を同時に変える必要はありません。見出しを大きくし、太くし、色を変え、枠で囲み、余白も広げると、ほかの階層との差が過剰になることがあります。一つの差で足りるか、二つの差が補い合うかを比べます。

視覚的階層は重要度そのものではない

大きく目立つ文字は、組織にとって重要でも、利用者の現在の課題には不要かもしれません。広告見出しが開催日時より大きいとき、造形上の主役と、課題上の最重要情報が異なります。

「最初に見えたもの」を重要度の証明にしません。初見の報告、探索課題、理解を分けます。

HTML の見出し構造とは別の層

大きな文字が自動的に h1 になるわけではありません。反対に、h1 を必ず画面最大にする規則もありません。HTML の Heading は文書の意味構造を表し、CSS は視覚表現を作ります。

両者が無関係でよいわけでもありません。視覚的には見出しなのにマークアップが単なる div、意味上は下位見出しなのに視覚上は本文と区別できない、といった不一致を確認します。見た目だけの順序と、見出しをたどった順序を別の重ね合わせで比べます。

7.5 ベースラインと、文字が作る見えない線

日本語、欧文、時刻の数字、アイコンを一列に置くと、CSS では中央揃えでも、文字が上下にずれて見えることがあります。第3章で扱った整列を、フォント指標まで掘り下げます。

箱の中央と字形の中央

インラインボックスの高さ、em ボックス、上へ伸びる部分、下へ伸びる部分、実際の字形を囲む箱は同じではありません。align-items: center は箱を揃えても、字形の黒い部分の重心を揃える機能ではありません。

ベースラインは一本だけではない

欧文でよく見るアルファベット用のベースラインに加え、書字体系やレイアウトには複数のベースライン概念があります。日本語を欧文の小文字の高さ、大文字の高さだけで説明しきれません。ブラウザが実際にどのフォント指標を使い、代替字形がどのベースラインへ置かれたかを確認します。

和欧混植と数字

「午後 6:30」の日本語、空白、数字、コロンが同じフォントファイルから出るとは限りません。数字だけ別フォント、記号だけ代替フォントになることもあります。フォントファミリーの指定ではなく、実際に描画された字形単位で見ます。

アイコンを文字として混ぜる場合も、見かけの中央、ベースライン、意味、読み上げを別に確認します。位置を 1px 動かす視覚補正が必要な場合、その値を普遍化せず、フォント、サイズ、アイコン、DPR の条件を残します。

7.6 日本語と欧文を同じ物差しで見ない

タイポグラフィの解説には、小文字の高さ、大文字の高さ、上へ伸びる部分、下へ伸びる部分等、ラテン文字を中心にした語彙が多くあります。重要な言葉ですが、それだけで漢字、ひらがな、カタカナ、約物、縦組みを説明できません。

日本語と欧文を同じ物差しで見ないを示す図。 — 図 7-6　日本語と欧文を同じ物差しで見ない

文字種が同じ面積を使うとは限らない

日本語フォントでも、漢字、仮名、ラテン文字、数字、約物の見かけの大きさや空間は異なります。全角の設計枠が同じでも、黒い部分の面積は同じではありません。

横組みと縦組み

横組みを 90 度回転すれば縦組みになるわけではありません。文字の向き、約物、括弧、長音、禁則、行の進む方向が関わります。CSS の writing-mode と text-orientation は実装の入口ですが、内容と書体が縦組みに適しているかまで自動で決めません。

和欧混植

日本語と英単語のサイズを CSS 上で同じにしても、見かけの高さや密度が合わない場合があります。機械的に倍率を決めず、本文、見出し、数字、コード等の用途ごとに比べます。

「日本語はこう組む」を固定しない

Japanese Text Layout の要件は重要な参照ですが、日本語タイポグラフィが一つだけあるわけではありません。時代、媒体、縦横、書体、出版／UI／広告の目的で選択が変わります。規範を知り、どこを意図して変えたかを説明できるようにします。

7.7 Web フォントは読み込み中にも画面を変える

デザインツールでは一枚の完成画面を見ます。Web では、フォントファイルがまだ届いていない時間、取得に失敗した状態、利用者の端末に別フォントしかない状態があります。

Web フォント読み込み中の画面を示す図。 — 図 7-7　Web フォント読み込み中の画面

`font-family` は一つの見た目を保証しない

ブラウザは指定されたフォントファミリーのリスト、利用可能な書体、ウェイト、スタイル、言語、文字の収録範囲等からフォントを選びます。一つの文章内でも、含まれない文字だけ別フォントになることがあります。必要なウェイトやイタリック体がなければ、合成される場合もあります。

開発者向け機能で、指定値だけでなく実際に使用されたフォントを文字単位で確認します。

読み込み中の三つの状態

テキストが一時的に見えない
代替フォントで読め、後から Web フォントへ置き換わる
Web フォントが届かず代替フォントのままになる

実装では状態遷移を固定します。

未要求 → 読み込み中 → 利用可能 → 適用済み

未要求 → 読み込み中 → 失敗／タイムアウト → 代替フォントを維持

再試行、キャッシュ済み、オフライン、フォントの一部だけ成功、ページ遷移中の取消も記録します。フォント適用の完了を、画面全体の準備完了や内容取得完了と同一視しません。

FOIT、FOUT という実務語で呼ばれることがありますが、仕様の正式な状態名と同一視しません。font-display は表示方針へ関わりますが、一つの値で全問題が解決するわけではありません。

代替フォントと Web フォントの字幅が違えば、改行、カードの高さ、ボタンラベルの幅が変わります。置換時に読み位置がずれ、押そうとしたボタンが動く可能性もあります。フォントリクエストの時間、描画、レイアウトシフト、実際の改行を記録します。

速さ、安定、表現のトレードオフ

Web フォントを使わなければ常に正解でも、すべて読み込むのが正解でもありません。必要な文字体系とウェイト、サブセット、可変フォント、キャッシュ、先読み、代替フォント、メトリクス上書き等を検討します。ただし、性能施策をフォントの見た目だけから決めません。

利用者の変更へ耐える

200% 文字拡大、文字間・語間・行間・段落間隔の利用者スタイル、最小フォントサイズ、ハイコントラスト等で確認します。コンテナの固定高さ、文字を画像化したボタン、overflow: hidden による切れを探します。

CSS の値を守ることではなく、利用者が文字を自分に合わせても内容と機能が残ることが目的です。

発展――ブラウザで答え合わせする

開発者向け機能で、実際に描画されたフォント、ネットワークリクエスト、計算済みスタイル、パフォーマンス上のレイアウトシフトを確認します。機能名はブラウザと版で変わります。利用できない場合は、フォントファイルを意図的にブロックしたスクリーンショット、document.fonts の状態ログ、改行数と要素矩形の記録で代替します。値を見る前に、どの文字が代替フォントか、どの行が変わるかを予想します。

7.8 書体の印象は普遍的ではない

書体見本に「誠実」「未来的」「女性的」「高級」と書かれていることがあります。選択の入口にはなりますが、書体の本質的な性格として暗記しません。

書体の印象は普遍的ではないを示す図。 — 図 7-8　書体の印象は普遍的ではない

印象評定には、次が関わり得ます。

Glyph の形と組版
表示された語と文章の意味
過去にその書体を見た媒体や Brand
書体名や作者についての知識
言語、地域、世代、専門経験
選択肢として与えられた評定語
サイズ、色、画像、余白等の文脈

図 F08 では、平均値だけで「この書体は親しみやすさ 8 点」と結論しません。個人ごとの Dot を残し、書体名を見せる前後、用途を変えた前後を比べます。

教材の模範値を作るために架空の調査結果を載せません。読者自身の回答を置く空の Template と、観察の書き方を示します。

私は書体 A を「静か」と評定した。線幅のコントラストがあり、見かけの字面が小さく、広い文字間と余白の中へ置かれていたことが関係した可能性がある。ただし、文化施設で見慣れた経験と、書体以外の間隔も代替説明になる。

印象を否定するのではなく、形、文脈、経験へ分解して疑います。

7.9 問い――この文字組みは、何をどう読ませているか

文化祭の出演者詳細画面を見ます。出演者名、日時、会場、400 字の紹介、注意、申込ボタン、日本語と英語のグループ名があります。Web フォントは通信条件によって遅れて表示されます。

基準条件

390px 幅、日本語横組み、100% ズーム、Web フォント取得成功から始めます。次に一軸ずつ、1280px、200% 文字拡大、間隔上書き、フォント遅延、フォント失敗、縦組みへ変えます。内容と意味構造は固定します。

操作と記録の順序

注釈なしで 30 秒見て、最初に気づいた文字と読んだ順序を記録する
開催時刻を探し、見つけるまでの操作と戻りを記録する
紹介文を読み、内容質問へ答える
造形の重ね表示で、印象の根拠となる形を指す
意味構造の重ね表示で見出し順を確認する
フォント遅延、失敗、200% 文字拡大、間隔上書きを一つずつ再現する

記録表は「条件／観察／解釈／代替仮説／変更する一軸／確認指標」の 6 列にします。最初の 6 問について、空欄のまま終わらない回答観点を次の例で示します。

問い

最初に目へ入った文字は何か。最初に読んだ情報は何か
文字のどの形と組み方が、どんな印象に関係したか
一文字の識別、情報探索、文章読了、理解のどこに問題仮説があるか
視覚的階層と HTML の見出し構造はどう対応するか
代替フォントへ変わると、文字、改行、位置、読み続け方の何が変わるか
200% 文字拡大と間隔上書きでも、内容と操作が残るか

答えの例

以下は六つの問いへ対応する回答観点です。文章を一致させる模範解答ではなく、観察と解釈を分けるための Rubric です。

最初に見たもの: 要素名、Size、Weight、位置を記し、「重要だから見た」とはまだ結論しない。
印象と形: 印象語に加え、具体的な文字、線、ふところ、字面、間隔を指す。文脈や経験を代替仮説にする。
読む課題: 誤読、探索時間、読了、内容正答、位置喪失、好みのどれかを選び、測定法を書く。
二つの階層: 視覚上の読む順序と、Heading をたどる意味順序を別々に記録する。
代替フォント: 実際に使用されたフォント、改行数、要素矩形、置換時刻を Before／After で比べる。
変更耐性: 文字拡大と間隔上書きを別試行にし、切れ、重なり、横スクロール、操作不能の有無を記録する。

出演者名が 32px、700 ウェイトで最も大きく、日時は 14px、400 ウェイトで本文と同じ明度に見える。私は出演者名を先に読み、開催時刻を探す課題では本文を二度往復した。問題があるなら「メリハリ不足」ではなく、課題上必要な日時と本文の視覚差がサイズ、ウェイト、間隔のいずれにもほぼ表れていないことが候補になる。

紹介文は一文字ずつ識別できるが、幅 390px で一行約 19 字、行高 1.1、段落間隔 0 のため、改行が密集している。読み位置を失ったという観察があれば、行高だけを 1.1／1.5 で変え、読了時間、位置喪失、内容質問を比べる。ただし、1.5 を全員の最適値とは結論しない。

Web フォント遅延時、代替フォントでは英語グループ名が一行に収まり、置換後に二行になって CTA を下へ押した。フォントが美しいかではなく、字幅差と置換時のレイアウトシフトを観察した。メトリクスの近い代替フォント、表示方針、レイアウトの耐性を別々に試す。

別の答え方

日時の発見が遅い理由はタイポグラフィだけでなく、出演者画像の近くに置かれたバッジ、日時ラベルの文言、情報順序かもしれません。文字の階層を変えても改善しなければ、位置、まとまり、タスク理解を調べます。

書体を「親しみやすい」と感じた理由も、丸い端部ではなく、文化祭という語、暖色の写真、過去のブランド経験かもしれません。文字だけの条件、文脈付き条件を比べます。

ここで章題の「声」を観察へ戻します。「優しい声に見える」で止めず、「仮名のふところ、線端、字面、文字間を私は柔らかい印象と結びつけた。用途と経験による別の説明がある」と書ければ、他者と比べ、次の画面で疑えます。

よくある考え方

Sans Serif だから Web で読みやすい。見出しは太く大きくすればよい。

注意点

分類名だけで、個々の字形、Size、表示条件、言語、課題を説明できていません。大きく太い見出しが増えれば、階層同士が競合する可能性もあります。何を識別し、何を探し、何を読み続けるのかを決めます。

必須セルフチェック

印象語を、Glyph の形と組版上の観察へ書き換えられる
文字識別、文章読了、理解、好みを別々に確かめられる
意味構造、代替フォント、ズーム、間隔変更後にも読めるか確認できる

発展セルフチェック

CSS 値と実際に使用された Font／Glyph を区別できる
日本語と欧文の尺度、横組みと縦組みの条件を記録できる
書体の印象を文化や用途を越えた性格表にしていない

参考

W3C, CSS Fonts Module Level 4. Font Matching、Synthesis、font-display 等を確認する仕様です。https://www.w3.org/TR/css-fonts-4/
W3C, CSS Font Loading Module Level 3. Font の Load 状態と API を確認する仕様です。https://www.w3.org/TR/css-font-loading-3/
W3C, Requirements for Japanese Text Layout. 日本語組版の要件を調べる詳細資料です。必要な節から読む資料です。https://www.w3.org/TR/jlreq/
W3C, CSS Writing Modes Level 3. 横書き、縦書き、文字方向の実装上の定義を確認できます。https://www.w3.org/TR/css-writing-modes-3/
W3C WAI, Understanding SC 1.4.12: Text Spacing. 利用者による Spacing 変更への耐性を確認する公式解説です。https://www.w3.org/WAI/WCAG22/Understanding/text-spacing
W3C WAI, Understanding SC 1.4.4: Resize Text. Text 拡大の達成条件を確認する公式解説です。https://www.w3.org/WAI/WCAG22/Understanding/resize-text.html
W3C WAI, Understanding SC 1.4.8: Visual Presentation. 調整可能な本文表示を扱う AAA の解説です。数値を最適値として読まないでください。https://www.w3.org/WAI/WCAG22/Understanding/visual-presentation.html
Legge, G. E. and Bigelow, C. A. (2011), “Does print size matter for reading?” 文字 Size と読書 Performance の研究を整理した Review です。日本語 Web 画面の固定 px 規則としては読まないでください。https://pubmed.ncbi.nlm.nih.gov/21828237/
Jordan, T. R. et al. (2017), “A Further Look at Print Personalities: The Perception of Personality in Typeface.” 書体への人格評定を扱う研究です。結果を他言語へ一般化せず、方法と条件を確認します。https://doi.org/10.3389/fpsyg.2017.01229
Sheen, M. et al. (2025), “A Further Look at Perception of Personalities in Typefaces: Evidence From Turkish.” 別言語での書体印象研究です。専門的です。https://doi.org/10.1177/00332941241310125
WHATWG, HTML Standard: Headings and Sections. 視覚表現とは別に、見出しの意味構造を確認する仕様です。https://html.spec.whatwg.org/multipage/sections.html#headings-and-outlines
OpenType Specification. Glyph、Metrics、Variation 等の Font 技術を確認する仕様です。書体史そのものの資料ではありません。https://learn.microsoft.com/en-us/typography/opentype/spec/

検索キーワード: typeface personality perception、legibility readability typography measurement、Japanese typography JLREQ、font fallback metrics layout shift、WCAG text spacing、variable font optical size

第8章　人間は、色を単独では見ていない

同じグレーの四角を、白い面と黒い面の上へ置きます。CSS の色の値を調べれば、二つの四角は同じです。それでも、違う明るさに見えることがあります。

画面で経験する色は、カラーピッカーに表示された一つの値だけでは決まりません。周囲の色、境界、面積、隣接関係、目の順応、ディスプレイ、周囲光、過去に見た状態が関わります。さらに Web では、色が役割、状態、操作を教え、テーマや利用者設定によって置き換わります。

色を説明する体系も一つではありません。顔料を混ぜる教育用の色相環、印刷の CMYK、ディスプレイの RGB、測色の XYZ／Lab、CSS の HSL／Oklch は、目的と媒体が違います。同じ「明度」等の語でも体系を記します。

したがって本章は、「美しいパレットの作り方」や「この色はこの感情を表す」という対応表を教える章ではありません。どの値が、どの条件で、何として見え、何を伝えているかを観察します。

この章の必修は三つです。

色の値と、周囲を含む見え方を分けて観察する
数値差、知覚差、意味差、コントラスト達成を区別する
色を変えたテーマや利用者のパレットでも、役割と状態が残るか確かめる

この章で見るもの

同じ色の値と、同じに見える色の違い

色相、明度、彩度と色空間

小さな色見本、広い面、細線、テキスト

色トークンが役割と状態を繰り返して教える仕組み

WCAG のコントラスト比が測るもの、測らないもの

エラー、グラフ、リンクを色だけで伝える問題

ライト、ダーク、強制色の異なる条件

色の意味と文化・文脈

8.1 同じ色は、隣の色によって違って見える

二つのグレーの色片を比べます。一方は暗い周囲、もう一方は明るい周囲に置かれています。中央のピクセル値は同じでも、暗い周囲に置いた方が明るく見える場合があります。

この種の現象は、同時明度対比や同時色対比等として研究されています。ただし、「隣の反対色へ必ず寄る」という一行の法則にはしません。刺激の面積、境界、配置、空間周波数、順応等によって結果が変わり、周囲へ同化するような結果もあり得ます。

値と見え方を別々に記録する

観察は次の順番にします。

どの色片が明るい、赤い、鮮やかに見えたかを記録する
値を取る前に二つの値が同じか予想する
CSS の指定値、計算値、最終ピクセルを調べる
周囲を隠し、色片だけを並べ直す
色片は固定して周囲だけを変える

教材図は知覚実験の結果図ではありません。人を対象に比較する場合は、色片と周囲の視角、視距離、提示時間、順応時間、観察順、ディスプレイの白色点・輝度・カラープロファイル、周囲照度を固定します。自由観察の Web 画面と統制刺激を同じ証拠にしません。

「同じ色なのに違って見える」は、見え方の報告です。「脳が補正したから」は解釈です。どの対比／同化の仕組みで説明できるかは、刺激条件と研究を照合してから考えます。

Web では Surround も状態で変わる

ボタンの色は、ページ背景、カード、画像、ホバー、フォーカスリング、隣のボタンによって見え方が変わります。色トークンだけを一覧にしても、実際の組合せは分かりません。コンポーネントを使われる文脈へ戻して見ます。

8.2 色相、明度、彩度を分けて比べる

カラーピッカーには Hue、Saturation、Lightness と書かれたスライダーがあります。便利ですが、これを人間の色経験を直接表す普遍的な三軸とは考えません。

色相・明度・彩度を Color Space で読むを示す図。 — 図 8-2　色相・明度・彩度を Color Space で読む

色空間が違えば座標の意味が違う

同じ sRGB の色を HSL、Lab、LCH、Oklab、Oklch へ変換すると、異なる座標で表されます。HSL の Lightness、Lab／Oklab の L、WCAG 計算の相対輝度は同じ量ではありません。

Hue: 色相に対応する角度として表す色空間がある
Saturation: HSL 等、その色空間内の定義に依存する
Chroma: LCH／Oklch 等の色みの量に対応する座標
Lightness: 色空間内で定義された明るさ方向の座標
相対輝度: WCAG のコントラスト計算で使う、線形化した sRGB 等から得る量

日常語として「明るい青」と言うことはできます。ただし CSS 値を設計・比較する段階では、どの色空間の何を固定したかを書きます。

発展――知覚的に均等に近い色空間も完全ではない

Oklab／Oklch 等は、sRGB の数値差より知覚差を扱いやすくする目的で利用できます。しかし、同じΔ値なら、すべての色、面積、観察者、ディスプレイで完全に同じ差へ見えるとは限りません。「Perceptual だから人間に正しい」としません。

発展――Gamut の外に出る

Display P3 で表せる色の一部は sRGB では表せません。CSS として有効でも、出力デバイスの色域外にある色があります。ブラウザは表示のために色域変換をします。デザインツールの P3 色を sRGB スクリーンショットへ変えたとき、同じ数値・同じ見え方とは限りません。

図 F02 では、色域外を隠さずマーカーで示し、元の値、変換後、実際のスクリーンショットのピクセルを分けます。

変換では元の色空間、白色点、色順応、色域変換、レンダリング意図、丸め精度と実装版を記録します。ブラウザ間の差を隠しません。

8.3 小さな色見本と、大きな色面

デザインシステムの配色ページには、小さな色見本が並びます。色見本でよく見えた色を、ページ全体の背景へ使うと、強すぎる、暗すぎると感じることがあります。

同じ色の値でも、役割は異なります。

8px の状態ドット
1px の境界線
16px の文字
ボタンの背景
ページ全体の面
写真上の半透明な重なり

色面の構成として、面積比、反復、近接、境界の硬さ、グラデーション、透明な重なり、図と地、アクセントの位置も観察します。色名の組合せだけでなく、どの色がどれだけの面積を占め、どこで接し、どの順序で重なるかを書きます。

小さな色見本だけでは、面積、隣接色、文字とのコントラスト、長時間見る背景、状態変化を判断できません。実際の面積と役割へ置きます。

面積効果を観察するための単純な図と、文字、境界線、背景という実務上の役割へ適用する画面を分けます。役割を変えた比較を「面積だけの実験」とは呼びません。

面積だけの法則にしない

「大きい面は必ず鮮やかに見える」とは断定しません。見る距離、ディスプレイの明るさ、周囲光、境界、順応、色座標も関わります。面積の影響を比べたいなら、色の値、周囲の色、形、表示時間、距離を固定します。

スクリーンショットも中立ではない

スクリーンショットのカラープロファイル、ブラウザ、ディスプレイ、画像ビューアによって表示が変わります。P3 のスクリーンショットを sRGB 前提のツールで開けば、変換または誤解釈が起こり得ます。色を厳密に比べる図版では、元の値、プロファイル、出力形式を残します。

8.4 色は、役割と状態を繰り返して教える

同じ青がリンク、主要ボタン、選択中タブに使われていると、利用者は青を「操作できる」「選ばれている」などのルールとして学ぶかもしれません。しかし、異なる役割を同じ色だけで表すと、ルールが曖昧になる場合があります。

生の値ではなく役割として名前を付ける

blue-600 は配色上の位置を示します。color-action-primary、color-text-link、color-status-error などは設計上の役割を示します。このような名前を使えば自動的に正しくなるわけではありませんが、テーマごとに役割を追跡しやすくなります。

色の名前は primitive → semantic role → component → state → theme override のように参照関係を持たせ、最終的に使われた色まで追跡します。一方、意味を持つ名前は表現を均質化する命令ではありません。祝祭感や静けさなどの表現意図を別列に置き、役割の分かりやすさとブランド表現を両方評価します。

:root {
  --color-surface: oklch(98% 0.01 250);
  --color-text: oklch(24% 0.02 250);
  --color-action-primary: oklch(55% 0.18 255);
  --color-focus-ring: oklch(70% 0.17 80);
}

値を決める前に、役割と組合せを表にします。

部品	状態	前景	背景	境界線／リング	色以外の手がかり
ボタン	通常	文字	主要色	なし	ラベル、形
ボタン	フォーカス	文字	主要色	フォーカスリング	アウトライン
入力欄	エラー	文字	面	エラー境界線	アイコン、エラー文、関連付け

状態を色の値一覧にしない

ホバー、フォーカス、押下中、選択中、無効、エラー、成功は異なる意味を持ちます。少し暗くするだけで、すべての状態が識別できるとは限りません。入力方法、プログラム上の状態、文言、形、位置、操作結果も確認します。

無効状態を低コントラストにすればよいという単純則にも注意します。操作不能の理由、読める必要、利用者が次にできることを状態設計として考えます。

8.5 コントラストは一つの数値だけでは語れない

「この色はコントラストが高い」と言うとき、何と何の、どのコントラストでしょう。文字と背景の相対輝度比、色相差、輪郭の局所差、知覚上の目立ち、役割の違いは別です。

WCAG のコントラスト比

WCAG 2.2 の文字コントラスト達成基準は、文字や文字画像と背景の相対輝度から比率を計算します。通常の文字と大きな文字で閾値が異なり、AA と AAA、例外があります。

計算用の記録では、前景、背景、透明度を合成した後の sRGB 値、相対輝度、文字サイズと太さ、達成基準番号、レベル、合否を一件の記録にします。アンチエイリアスされた文字の縁のピクセルは、CSS の文字色そのものではありません。スクリーンショットの縁から取った値と、仕様上の入力値を別表にします。

比率は重要な確認値ですが、次のすべてを測るものではありません。

色相を区別できるか
色の見え方の個人差全体
フォントの線が細く描画された結果
まぶしさ、ディスプレイ品質、周囲光
文字の意味が理解できるか
ボタンが押せると分かるか
視覚的階層が適切か

基準を満たした後も実際の文字を読み、拡大、フォント、環境を確認します。反対に、主観的に読めた一人の報告で達成基準を省略しません。

透明度、グラデーション、画像背景

半透明の文字や重なりでは、最終的な合成色が背景で変わります。グラデーションや写真上の文字は、値を取る位置によって比率が変わります。Hex 同士を計算するだけでなく、合成順、最も不利な背景、動的な内容を記録します。

文字以外のコントラスト

UI 部品や図形では、識別に必要な視覚情報と隣接色を特定します。「すべての境界線は 3:1」とは限りません。境界線が部品を識別する唯一の手がかりか、フォーカスリング、チェックマーク、グラフの線などの何を測るかを先に決めます。

8.6 色だけで違いを伝えない

フォームの入力欄が赤くなった、グラフの線が赤と緑、リンクが青いだけ。このような画面は、色相差を識別できないと意味が失われる可能性があります。

WCAG の「色の使用」は、色を禁止していません。色に加えて情報を伝える方法を用意します。

エラー境界線＋エラーアイコン＋エラー文
グラフの色＋線種＋マーカー＋直接ラベル
リンク色＋下線
選択色＋チェックマーク＋aria-selected
必須色＋文字ラベル＋プログラム上の関連付け

明度差があれば十分か

色相だけでなく十分な相対輝度差がある場合、視覚上の追加区別として扱える条件があります。しかし、赤ならエラー、緑なら成功という色そのものの意味を答えさせるなら、比率が高くてもラベルなどが必要です。

シミュレーションの限界

色の見え方のシミュレーションは、配色内の区別が失われそうな箇所を探す補助になります。しかし、特定の人がどう見えるかを完全に再現するものではなく、当事者によるタスク確認の代替ではありません。シミュレーションの計算方法と条件を記録します。

シミュレーション前の元プロファイル、変換方法、想定する色の見え方の違い、出力プロファイルを保存します。画像だけから参加者の診断名を推定しません。

また、スクリーンリーダーに状態が伝われば、色だけに依存する問題が解決するわけでもありません。色を区別しにくい視覚利用者が支援技術を使っているとは限りません。視覚上の補助と、プログラム上の状態の両方を確認します。

8.7 ダークモードは色を反転すれば作れるか

明るいテーマの白を黒へ、黒を白へ反転すると、ダークモードらしい画面はできます。しかし、すべての役割が保たれるとは限りません。

Dark Mode と Forced Colorsを示す図。 — 図 8-7　Dark Mode と Forced Colors

面を役割ごとに見る

ページ、カード、ポップオーバー、入力欄などの面が、明るいテーマでは影とグレー差で分かれていても、ダークテーマでは同じ黒へ潰れる場合があります。浮き上がりを明るさだけで表すか、境界線や間隔を併用するかを文脈で決めます。

画像、ロゴ、イラスト、コードの強調表示、チャート、フォーカスリング、選択表示、フォーム部品、スクロールバーも確認します。写真が明るすぎるなら画像や重なりの調整が必要かもしれません。

`prefers-color-scheme` はテーマの同意ではない

メディアクエリは、利用者が明るい配色か暗い配色かを望んだ設定を検出する入口です。製品内のテーマ選択、システム設定、保存値の優先順位を決めます。no-preference を特定テーマへの同意としません。

強制色はダークモードではない

強制色では、ブラウザなどのユーザーエージェントが制作者の色を利用者のシステム配色へ置き換えます。黒背景になるとは限らず、利用者は白背景、黒背景、独自色などを選べます。

制作者の色が置換されると、影、背景画像、色だけで示した状態が消える場合があります。システム色、境界線、アウトライン、文字、ネイティブ部品を使い、Windows 実環境で確認します。forced-color-adjust: none で全ての部品を固定するのは、利用者の選択を奪う可能性があります。

明るいテーマ、暗いテーマ、強制色は「明るさを三段階で変える」比較ではありません。それぞれの条件で、役割と状態が残るかを見ます。

8.8 色の意味は文化と文脈で変わる

赤はエラー、危険、停止として使われることがあります。同じ赤は祭りのアクセント、セール、祝意、チームカラーにもなります。色自体に一つの意味が埋め込まれているわけではありません。

「日本では白は〇〇、国 A では赤は〇〇」という一覧も、理解の入口に留めます。一つの国や文化に、単一の意味があるわけではありません。領域、時代、宗教、地域、ブランド、世代、UI の慣習、周囲の文字が関わります。

図 F08 では同じ赤を、エラー、祭の見出し、売り切れ、値下げへ置きます。色の値を固定し、ラベルと領域だけを変えます。読者が理解した意味と、その根拠を記録します。架空の「国別正答率」は載せません。

Web の状態では、製品内の反復によって意味を学ぶこともあります。最初から普遍的に理解されると仮定せず、ラベル、アイコン、位置、操作結果でルールを教えます。

8.9 問い――この色の差は、何を伝え、誰に見えるか

文化祭のチケットフォームを見ます。座席状況グラフ、入力エラー、リンク、主要操作、写真上の案内、明るいテーマと暗いテーマがあります。

基準条件

sRGB ディスプレイ、明るいテーマ、100% ズーム、通常の制作者色から始めます。次に一軸ずつ、暗いテーマ、強制色、色だけの補助なし、写真差し替え、P3 対応環境へ変えます。色の厳密な知覚実験ではなく、Web 画面の観察とタスク比較です。

操作と記録の順序

注釈なしで、最初に見た色面と要素を記録する
チケットを選び、入力エラーを見つけて修正する
座席グラフの二系列を説明する
CSS 値、計算後の色、実際に使われた色、コントラスト記録を開く
明るいテーマ、暗いテーマ、強制色を一つずつ切り替える
色だけの補助を外し、同じタスクを行う

記録表は「条件／値・色空間／観察／役割・状態／代替仮説／確認方法」の 6 列にします。実機の強制色がない読者には、Windows 実機スクリーンショット、システム色対応表、キーボード操作動画、DOM とアクセシビリティツリーの記録を配布します。エミュレーションだけを実機結果とは呼びません。

問い

同じ色の値なのに違って見える箇所はあるか
各色は、値ではなく何の役割や状態として使われているか
色相を消してもエラー、リンク、座席状態を区別できるか
コントラスト比は、どの前景と背景の何を測ったか
明るいテーマ、暗いテーマ、強制色で、何の意味や境界が失われたか
その仮説を、値、スクリーンショット、人のタスクのどれで確かめるか

答えの例

六つの問いへの回答では、次の観点を最低限含めます。

文脈: 同じ値の要素と異なる周囲色を指し、値を取る前後を分ける
役割: red-600 でなく、エラー、操作、面などの役割と状態を書く
色以外: 文字、形、模様、プログラム上の状態を確認する
比率: 対象の前景と背景、達成基準、レベル、文字か文字以外かを特定する
テーマ: 消えた境界、フォーカス、状態、画像をテーマごとに記録する
証拠: CSS 値、スクリーンショット、タスク観察が支える範囲を限定する

具体例にすると、次のようになります。

同じ oklch(60% 0.12 250) の座席ドットが、白い表の上より濃紺のヘッダー上で明るく見えた。ドットの値を固定し、周囲色だけを入れ替える。
red-600 はエラー境界線と売り切れバッジに使われるが、前者は入力状態、後者は在庫状態である。色名ではなく二つの役割を分ける。
エラーの赤をグレーへ置換すると境界線の差だけが残り、理由が分からない。エラー文、アイコン、入力欄との関連を追加して修正タスクを行う。
主要ボタンの文字と背景について SC 1.4.3 AA を測った。グラフ線やフォーカスリングの合否をこの記録からは結論しない。
強制色で座席グラフの塗りが同じシステム色へ置換された。直接ラベルとマーカー形状で二系列を追えるか確認する。
CSS 記録は値と達成基準、スクリーンショットは特定環境のピクセル、人のタスクはその条件での行動を支える。どれか一つを全体の証拠にしない。

入力エラーは境界線だけが赤へ変わり、文字ラベル、アイコン、エラー文がない。赤を区別できない場合、どの入力欄に何の問題があるか視覚的に分からない可能性がある。エラー文とアイコンを追加し、入力欄へプログラム上も関連付けた条件で、エラー発見と修正タスクを確認する。

座席グラフの赤線と緑線は、白背景との文字コントラスト比を測っても意味がない。図形として線と隣接色を特定し、線種、マーカー、直接ラベルを追加する。比率達成と系列識別タスクを別に確認する。

ダークテーマでカードの影が見えなくなり、ページ面とカード面が同じ計算後の色になった。問題があるなら「ダークモードのコントラスト不足」ではなく、カード境界を示していた唯一の手がかりが影で、それがダークテーマで知覚できないという仮説になる。間隔、境界線、面の差を一軸ずつ比べる。

別の答え方

主要操作が見つからない原因は色ではなく、同じ大きさのボタンが三つあること、ラベルが曖昧なこと、位置がタスクの流れから離れていることかもしれません。色の鮮やかさを上げても改善しなければ、階層、文言、配置を調べます。

写真上の文字が読みにくい理由は、平均比率でなく、文字の背後にある局所的な明暗変化かもしれません。写真を固定して重なりだけを変え、最も不利な位置の値と実際の読字を確認します。

よくある考え方

コントラスト比を満たしたので、この配色はアクセシブルである。赤は危険、緑は安全だから分かる。

注意点

一つの達成基準を、アクセシビリティ全体の合格証にしています。色そのものへ依存する意味、状態のプログラム上の関連付け、テーマ変更、フォント、タスク、環境は別に確認します。色の意味も文脈を越えて固定できません。

必須セルフチェック

色の値、周囲色、見え方を別々に記録できる
数値差、知覚差、意味差、コントラスト達成を区別できる
明るいテーマ、暗いテーマ、強制色で役割と状態を確認できる

発展セルフチェック

色空間、色域、プロファイル、透明度の合成を記録できる
文字、文字以外、色の使用の対象を分けられる
シミュレーションを当事者の見え方やタスク検証の代替にしていない

参考

W3C, CSS Color Module Level 4. CSS の色空間、変換、補間、色域変換を確認する仕様です。https://www.w3.org/TR/css-color-4/
W3C WAI, Understanding SC 1.4.1: Use of Color. 色だけに意味を依存させない達成基準の公式解説です。https://www.w3.org/WAI/WCAG22/Understanding/use-of-color
W3C WAI, Understanding SC 1.4.3: Contrast (Minimum). 文字コントラストの対象、式、例外を確認できます。https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html
W3C WAI, Understanding SC 1.4.11: Non-text Contrast. UI 部品などで何を測るかを確認できます。https://www.w3.org/WAI/WCAG22/Understanding/non-text-contrast.html
W3C, CSS Color Adjustment Module Level 1. color-scheme、強制色、システム色を確認する仕様です。https://www.w3.org/TR/css-color-adjust-1/
W3C, Media Queries Level 5. prefers-color-scheme と forced-colors の定義を確認できます。https://www.w3.org/TR/mediaqueries-5/
Bosten, J. M. and Mollon, J. D. (2012), “New Laws of Simultaneous Contrast?” 同時 Contrast の単純則と条件を検討する専門的な研究です。
CIE, Colorimetry — Part 6: CIEDE2000 Colour-Difference Formula. 色差式の標準です。Web 画面の意味理解や可読性の尺度ではありません。https://cie.co.at/publications/colorimetry-part-6-ciede2000-colour-difference-formula-1
International Color Consortium, ICC.1 Profile Specification. デバイス間のカラーマネジメントを調べる専門仕様です。https://www.color.org/specification/ICC.1-2022-05.pdf

本章の E03「面積」と E09「文化的意味」は、無条件の普遍則を採用していません。図版は本書内比較、意味は対象文脈での理解確認として扱います。

検索キーワード: simultaneous color contrast assimilation、CSS Color 4 Oklch gamut、WCAG use of color、forced colors system colors、dark mode color accessibility、color meaning cross cultural context

第9章　人間は、画面全体にリズムと重心を見る

ボタンの色を直し、カードの余白を整え、見出しのフォントを選び直しました。部品を一つずつ見ると改善しています。それでもページ全体へ戻すと、どこか落ち着かないことがあります。

部分は、全体の中で意味を持ちます。一つの見出しを強くすれば、ほかの見出しとの大きさの関係が変わります。一つのカードを広げれば、余白の形と画面の重心が変わります。すべての部品を同じ品質で強くすれば、全体として競合することもあります。

本章では、大きさの関係、余白、リズム、密度、重心、画像と文字の関係を、画面全体を見るための造形語彙として扱います。「重心」は物理的な質量、「視線の流れ」は測定済みの眼球運動を意味するとは限りません。観察と設計意図を言葉にするための仮説です。

構成の語彙は、絵画、書、版面、写真、広告、映画、建築などの媒体史の中で育ってきました。画面へ借りるとき、固定された枠、紙の見開き、時間を持つ映像、幅と内容が変わる Web の違いを残します。三分割法や黄金比を、歴史を越えた自然法則として扱いません。

この章の必修は三つです。

部品だけでなく、画面全体の面積・位置・反復・空白を記述する
視覚的な重さ、釣り合い、視線、タスクを同一視しない
同じ内容を異なる意図で構成し、レスポンシブ状態まで比較する

この章で見るもの

部品の改善が全体を変える仕組み

大小の差が作る大きさの関係

空いている場所が作る形

反復と変化によるリズム

見た目の密度と情報の密度

造形上の重心と、見る順序の仮説

画像と文字が互いの意味を変える関係

グリッド、DOM、見える秩序の違い

9.1 部品を直しても、全体がよくなるとは限らない

文化祭トップページに、ヒーロー領域、開催日時、プログラムカード、ニュース、スポンサー、申込ボタンがあります。プログラムカードだけを見ると、見出しが小さく、ボタンが弱く見えます。そこで見出しを大きくし、ボタンを鮮やかにします。

カード単体では役割が明確になりました。しかし、同じ修正をすべてのカードへ適用すると、ページ内に大きな見出しと主要に見えるボタンが十個並びました。ヒーロー領域のタイトルや本当の申込操作と競合します。

部品だけで見る場合とページ全体で見る場合

部品単体では、内部の階層、状態、操作を確認します。ページ全体では、次を追加します。

画面内で占める面積
同じ強さの要素数
ページの主題との位置関係
前後セクションとの間隔
同時に見える操作
スクロールしたときの反復

「ボタンをもっと目立たせる」が局所的に正しくても、全体の主要操作を曖昧にする場合があります。修正後は必ずページへ戻します。

Web の全体は一枚に固定されない

ページ全体といっても、利用者が一度に見る範囲はビューポート、ズーム、内容量、状態で変わります。長いページの全体スクリーンショットは構成を見る資料になりますが、実際の一瞬のビューポートではありません。ページ全体、現在見えている範囲、スクロールの順序を分けます。

9.2 大小の差が大きさの関係を作る

見出し 24px、本文 20px、補足 18px。値は違いますが、遠目には同じ強さに見えるかもしれません。反対に、見出し 64px、本文 16px なら大きな差が生まれます。

ここでいう大きさの関係は、単一要素の大きさではなく、要素間の関係です。

ページタイトルとセクション見出し
ヒーロー画像とサムネイル
主要操作と補助操作
主内容と補足情報
ページ全体と内部部品

比率は出発点であって正解ではない

モジュラースケールや一定の比率は、候補を作り、反復可能にする道具です。しかし、1.25 や黄金比を使えば視覚的階層が正しくなるわけではありません。フォントの字面、内容の長さ、言語、ビューポート、役割が関わります。

図 F02 では、同じ要素群を次の三条件で比べます。

ほぼ差がない
数学的に連続する小さな差
役割へ対応させた不均一な差

三番目が常に最良ではありません。静かな一覧では小差が合うかもしれず、短時間探索では大差が必要かもしれません。目的とタスクを書きます。

大きさだけで階層を作らない

位置、間隔、太さ、色、画像、余白も階層へ関わります。すべてを大きさで表せば、画面が際限なく拡大します。一つの役割差をどの造形変数へ翻訳するかを選びます。

9.3 余白は空きではなく、形である

余白を「何も置いていない場所」と考えると、余った場所、削ってもよい場所に見えます。画面を矩形化すると、要素の形と同時に、その間を通る空白の形が見えます。

置かれた形と残った形

文字、画像、ボタンなどが占有する形と、その周囲に残る形を分けて観察できます。これは良い／悪いを決める分類ではありません。

残った形には、次の違いがあります。

ページを縦に貫く連続した空白
セクション間の帯
カード内に閉じた空白
要素間の細い通路
片側だけに残る大きな空白
画像の中で文字を置ける空間

さらに、包む／分ける／通す／止める／圧迫する／開放するという関係の質を記します。残った形は、背景色ピクセルの連結領域として計算したものと、知覚上の空間として指したものを分けます。

「余白が多い」だけでなく、どの空白がどこへ続き、何を分け、何をつないでいるかを書きます。

空白率は意味を説明しない

画面の 70% が空白でも、必要な情報が端へ追いやられ、探索しにくい場合があります。空白率 20% でも、比較タスクに適した高密度な表かもしれません。面積の数値と、まとまり、階層、タスクを分けます。

レスポンシブで空白の形は変わる

デスクトップの左右余白は、モバイルで上下の間へ変換される場合があります。単純にすべて半分にすると、タッチ対象、段落、セクション間の関係が変わります。幅を変えながら、残った形を再び見ます。

9.4 反復と変化がリズムを作る

カードが同じ幅、同じ内部配置、同じ間隔で並ぶと、反復する単位が見えます。途中で一つだけ大きなカードが入れば、反復が途切れ、注意や意味の例外になる可能性があります。

本章でいうリズムは、次の反復と変化を記述する造形語彙です。

大きさ
間隔
形
色
タイポグラフィ
整列
内容の長さ
画像の切り抜き

心拍や音楽の拍と同じ生理・時間現象として定義しません。スクロールによって順に現れる Web では時間的な経験も生まれますが、まず何が何回、どの間で反復するかを指します。

等間隔だけがリズムではない

8px 刻みの間隔スケールは一貫した値を作れます。しかし、すべてを等間隔にすれば、関係の強弱が消えます。セクション内は短く、セクション間は長くする周期や、見出し前後の非対称な間もリズムを作ります。

例外を意図として読む

注目プログラムだけ幅が 2 倍なら、その変化は強い手がかりになります。意図された切れ目か、内容都合で壊れたレイアウトかを確認します。例外をすべて消すのでも、目立つから残すのでもありません。

9.5 密度が高いことと、混乱していることは同じではない

ダッシュボードには多くの数字、グラフ、表、フィルターがあります。マーケティングページより見た目の密度が高く見えます。しかし、監視や比較のタスクでは、同時に多くの情報が見えることが役立つ場合があります。

密度を少なくとも四つに分けます。

計数前に単位を固定します。ピクセル密度はビューポート内の二値化後占有率、要素密度は注釈した知覚単位数、情報密度はタスクに必要な項目数、操作密度はタブ停止位置やポインター対象の数として本書内比較します。値は閾値ではなく、同じ注釈規則の画面を比べる記録です。

ピクセル密度、インク密度

画面のうち、文字、画像、境界線、色面などが占める割合です。二値化条件によって値が変わります。

要素密度

ビューポート内にいくつの要素や部品があるかです。DOM ノード数とは同じではありません。

情報密度

意味のある項目、比較軸、状態、関係がどれだけ含まれるかです。数え方にはタスクと領域の定義が必要です。

操作密度

操作可能な対象、選択肢、同時に判断するコントロールの数と配置です。

密度が高いという観察から、認知負荷が高いと即断しません。第11章で扱う記憶・処理条件、利用者の熟練、探索／監視／学習タスクを確認します。

低密度でも迷う

一画面に一つのボタンしかなくても、ラベルが曖昧で前の情報を覚える必要があれば難しいかもしれません。高密度でも、まとまり、整列、比較軸が明確なら効率的な場合があります。

9.6 画面の重心と視線の流れ

大きな暗い画像が右上にあり、左下には短い文字だけがある画面を見て、「右上が重い」と言うことがあります。視覚的な重さと釣り合いは、構成を話す有用な語彙です。

ただし、視覚的な重さは物理質量のように一つの式で決まるとは限りません。次が候補になります。

面積
位置と中心からの距離
明度／コントラスト
色
形と向き
細部と質感
顔や意味のある画像
文字の量と意味
動き

重心計算は重ね合わせる見方の一つ

ピクセルや明度から画像の重心を計算できます。研究でも釣り合いを数理化する試みがあります。しかし、その点を「人間が感じる正しい重心」とはしません。幾何学上の中心、計算点、観察者が指した釣り合いの点を別の層で比べます。

計算ではビューポート内のラスタ画像を固定サイズへ変換し、透明度を背景へ合成し、sRGB の相対輝度から重みを作る一方式を使います。切り抜き、背景、式を変えれば点も変わります。釣り合いの点は、参加者が「最も釣り合う中心」として一回指した座標と確信度を記録します。初見報告は、3 秒提示後に最初に気づいた要素名を答える別タスクです。

「視線が流れる」を観察へ戻す

視線計測なしに、実際の眼球軌跡を知ったとは言えません。次のように書き換えます。

設計意図として、タイトル→日時→申込ボタンの順を想定した。私は初見で画像→タイトル→日時と報告した。タスクでは日時を 6 秒で発見した。

意図、初見報告、視線データ、タスク結果を分けます。

視線計測を行う場合も、注視、サッカード、視線の軌跡、関心領域、タスク、調整品質を記録し、視線を注意や理解と同義にしません。

F 型／Z 型をテンプレートにしない

Web で特定の読み取りパターンが観察される研究や実務報告はありますが、ページ、言語、タスク、デバイス、参加者を越えた普遍軌道ではありません。F 型に配置すれば必ず読まれる、とは教えません。

9.7 画像と文字は、互いの意味を変える

「静かな夜の演奏会」という見出しに、暗いステージ写真を添える場合と、笑顔の観客写真を添える場合では、同じ言葉の受け取り方が変わります。

画像と文字の関係を観察します。

同じ意味を反復する
文字にない情報を補う
意図的な緊張や矛盾を作る
画像が背景装飾として働く
キャプションが画像の読み方を限定する
切り抜きによって主題や方向が変わる

「顔が向いた先へ必ず視線が行く」と法則化しません。顔、視線方向、文字位置、タスク、文化、切り抜きを分けて確かめます。

写真上の文字の問題を構成だけにしない

写真上の文字は、構成、コントラスト、レスポンシブ時の切り抜き、画像読み込み、代替テキスト、内容更新の問題を持ちます。デスクトップで空いていた場所が、モバイルの切り抜きで顔や明るい部分と重なることがあります。ブレークポイントごとに固定スクリーンショットだけを見るのではなく、幅を連続的に変えます。

9.8 グリッドは秩序を作る道具であって正解ではない

グリッドを使うと、列、間隔、整列を反復できます。しかし、グリッドを引いただけで意味の階層や釣り合いが生まれるわけではありません。

四つの層を分けます。

内容の意味上のまとまり
DOM 順
CSS グリッドのトラックと配置
画面で知覚される整列とまとまり

これらは関係しますが、同一ではありません。意味上近い二要素が別の列へ離れ、グリッド上は美しく揃っても関係が弱く見えることがあります。

内容がトラックを変える

CSS グリッドには、固定、可変、内容に応じたトラックサイズがあります。長い名前、翻訳、ズーム、画像の縦横比で実際に使われるサイズが変わります。デザインツールの 12 カラムの重ね表示と、ブラウザが計算したトラックを同一視しません。

見える順序と読む順序

CSS で見た目の位置を変えても、DOM、キーボードフォーカス、支援技術の読み順が同じように変わるとは限りません。レスポンシブでカードを並べ替えるとき、視覚上の順序だけを最適化しません。

グリッドから外れる意図

一つの画像が列を越える、引用が外へ張り出すなど、グリッドから外すことで例外を作れます。ずれをすべてエラーとせず、意味、表現、はみ出し、レスポンシブでの結果を確認します。

9.9 同じ内容を異なる意図で三案作る

良い構成を一案だけで探すと、最初の配置を少しずつ修正し続けがちです。同じ内容から、意図の異なる三案を作ります。

A　静かな鑑賞

画像と余白を大きく取り、同時に見える操作を減らします。作品を眺める時間を作る意図です。代わりに、日時の短時間探索は遅くなるかもしれません。

B　短時間探索

日時、会場、プログラムカテゴリを先に比較できる構成です。情報密度は高くなりますが、階層と整列を強くします。祝祭的な驚きは弱くなるかもしれません。

C　祝祭的な発見

大きさの大きな変化、画像の切り抜き、リズムの切れ目を使います。発見の楽しさを意図しますが、反復可能性、読み順、レスポンシブの安定が課題になります。

三案は良い／悪い／最良ではありません。意図、得るもの、失うもの、向くタスクを対応させます。

レスポンシブは別案ではなく同じ設計の状態

デスクトップとモバイルで見た目が変わっても、内容の優先順位、見出し構造、タスク、状態はつながります。三案それぞれで、幅、文字拡大、長い内容を試します。

9.10 問い――部分ではなく、全体として何が起きているか

図 F09 の三案を、最初は意図ラベルを隠して見ます。

操作と記録の順序

A／B／C の提示順を参加者ごとに入れ替える
各案を 3 秒見て、最初に気づいた要素を報告する
開催日時を探し、完了時間と誤りを記録する
釣り合いの点と確信度を記録する
矩形化、残った形、グリッドの重ね表示を順に見る
モバイル、200% 文字拡大、長い名前へ一軸ずつ変える

記録表は「条件／全体の観察／意図の推定／タスク結果／代替仮説／変更する一軸」の 6 列です。専用ツールがなくても、印刷した透明グリッド、矩形化画像、空白を塗るメモ、ビューポート枠で同じ順序を行えます。

問い

最も大きな面、最も長く続く空白はどこか
何が何回、どの間隔で反復するか
どこでリズムが切れ、その理由は何か
ピクセル、要素、情報、操作のどの密度か
何を「重い」と感じ、どの形・位置が関係したか
設計意図、初見報告、タスク結果を分けられるか
グリッド、DOM、見える整列はどう違うか
モバイルと 200% 文字拡大で全体の関係はどう変わるか

答えの例

八つの問いへの評価観点は、次の対応です。

最大面と最長空白を、ビューポート比と始点・終点で記す
反復単位、回数、間隔列を記す
切れた箇所と、意味上の例外／レイアウト事故という代替仮説を書く
ピクセル／要素／情報／操作の計数単位を選ぶ
「重い」要素と、面積・位置・明暗・細部などの根拠を指す
意図、初見報告、視線、タスクを別記録にする
DOM、見える順序、読み順、フォーカス順を並記する
モバイル／ズームで失われた関係と、維持すべき内容の優先順位を書く

具体例にすると、次のようになります。

B 案ではプログラム一覧がビューポートの 58%、左側の連続余白が幅 32px でヘッダー下から一覧末まで続く。
カードは 6 回反復し、内部間隔は 8／16px、カード間 16px、カテゴリ間 40px である。
3 件目だけ 2 カラム幅でリズムが切れる。注目項目の意図か、長いタイトルによるグリッド事故かを確認する。
「高密度」はピクセル占有率 43% を指す。情報項目数やタブ停止位置の多さとは別記録にする。
右上画像を重いと評した根拠はビューポート比 42%、暗い面、細部量、中心からの距離である。
意図はタイトル→日時→申込ボタン、初見報告は画像、日時探索は 5.8 秒だった。視線は未測定である。
見える順序は画像→タイトルだが、DOM／読み順／フォーカス順はタイトル→日時→リンクである。意図した差か確認する。
390px ではヒーロー領域下の空白が 180px となり日時が次のビューポートへ移った。内容の優先順位を保つため、画像の高さとセクション間隔を別々に試す。

B 案では、日時と会場の行が同じ列とベースラインで 6 件反復し、カード間 16px、カテゴリ間 40px で周期が分かれる。情報項目は多いが、比較軸が縦に連続している。高密度という観察だけから混乱とは結論しない。出演日時を探すタスクの時間と誤りを A／B／C で比べる。

C 案では、右上の画像がビューポートの約 42% を占め、左側の文字群より面積と細部が大きい。私は「右上が重い」と評したが、これは釣り合いの評定であり、視線計測結果ではない。画像を固定して切り抜き／面積だけを変え、釣り合いの評定と日時探索を別に取る。

A 案の大きな余白は作品画像の周囲へ連続し、鑑賞の間を作る意図に見える。一方、モバイルでは画像下に長い空白が残り、日時が次のビューポートへ押し出された。デスクトップの余白値を縮小するのではなく、モバイルでの内容の優先順位に合わせて構成を再判断する。

別の答え方

最初に見たものが画像だった理由は、構成の重心だけでなく、顔、動き、個人的関心、読み込み順かもしれません。静止矩形化、画像差し替え、タスク変更で代替仮説を比べます。

よくある考え方

Z 型で視線を申込ボタンへ流し、黄金比と 12 カラムグリッドで釣り合いを取る。

注意点

パターン、比率、グリッドを人の行動と美的品質の保証にしています。何をどの条件で観察し、どのタスクを改善するかがありません。道具は候補を作りますが、答えを代行しません。

必須セルフチェック

面積、位置、反復、空白を全体の観察として書ける
視覚的な重さ、釣り合い、視線、タスクを分けられる
同じ内容の三案を、意図とトレードオフで比較できる

一人で学ぶ場合は、自分の初見報告を測定済みの一般傾向にしません。翌日に提示順を変えて再観察し、結果を「自分・この画面・このタスク」の記録として残します。複数参加者を比較する場合は、目的、記録内容、途中終了、匿名化、画像／視線データの保存期間を説明し、同意を得ます。

発展セルフチェック

占有率、情報項目、操作対象を別々に記録できる
グリッドトラック、DOM、見える順序、フォーカス順を確認できる
レスポンシブを縮小でなく構成の状態として評価できる

参考

Locher et al. (2001), “Artists' Use of Compositional Balance for Creating Visual Displays.” 抽象要素の配置制作と釣り合いを扱う研究です。Web の公式にはしません。https://doi.org/10.2190/EKMD-YMN5-NJUG-34BK
McManus, Stöver, and Kim (2011), “Arnheim's Gestalt theory of visual balance.” Center of Mass による解釈と限界を扱います。https://pubmed.ncbi.nlm.nih.gov/23145250/
Locher, Overbeeke, and Stappers (2005), “Spatial Balance of Color Triads in the Abstract Art of Piet Mondrian.” 色面の釣り合い評定を扱う専門研究です。https://doi.org/10.1068/p5033
W3C, CSS Grid Layout Module Level 2. グリッドトラック、内容に応じたサイズ、配置を確認する仕様です。https://www.w3.org/TR/css-grid/
W3C, CSS Box Alignment Module Level 3. Alignment の仕様上の意味を確認できます。https://www.w3.org/TR/css-align-3/
W3C WAI, Understanding SC 1.4.10: Reflow. ズームとリフローの達成条件を確認します。https://www.w3.org/WAI/WCAG22/Understanding/reflow.html
“Eye Tracking Scanpath Analysis Techniques on Web Pages.” 視線軌跡の分析法を扱う調査論文です。F／Z 型の万能則ではありません。https://www.mdpi.com/1995-8692/9/1/2
Arnheim, Rudolf, Art and Visual Perception. 視覚的な釣り合いを考える歴史的理論書です。現代 Web UI の公式としてではなく、McManus らの検証研究と併読します。
Müller-Brockmann, Josef, Grid Systems in Graphic Design. モダニズムのグラフィックデザインにおけるグリッド実践を知る資料です。CSS グリッド仕様やレスポンシブの正解集ではありません。
Wong, Wucius, Principles of Form and Design. 反復、リズム、形などの造形語彙を学ぶ入口です。心理学的法則とは区別します。
Barthes, Roland, “Rhetoric of the Image.” 画像と文字の関係を考える歴史的資料です。視線計測研究ではありません。

検索キーワード: pictorial balance visual weight、composition center of mass perception、visual rhythm graphic design、information density dashboard、web scanpath task eye tracking、CSS Grid intrinsic sizing reading order

第 I 部統合ケース　同じ内容から、異なる三つの画面を読む

第1章から第9章まで、画面を見るための言葉を一つずつ学びました。近接、整列、類同、境界、動き、タイポグラフィ、色、構成。ここで一度、それらを同じ画面へ戻します。

統合するとき、知っている概念を全部当てはめる競争にはしません。一つの画面へ「近接」「認知負荷」「コントラスト」と多くのラベルを貼っても、何が起きているかが明確になるとは限らないからです。

本ケースでは、同じ文化祭情報から三つの画面を作ります。

A　静かな文化施設として、作品との出会いを支える
B　チケットを探して購入する EC として、比較と操作を支える
C　運営業務画面として、状態監視と変更・回復を支える

ここで「同じ内容」とは、イベントという共通対象が同じであることです。三案の画面へ同じ項目とコントロールを無理に置く意味ではありません。

層	三案で共通	案ごとに異なる
共通対象	ID、タイトル、日付、会場、出演者、説明、価格、空き状況、画像、状態履歴	なし
表示データ	共通対象から導出	A は作品解説、B は購入可否、C は監査情報／担当者を表示
主要タスク	イベントを特定し日時を説明する	A は鑑賞、B は購入、C は状態更新・回復
操作	リンク／ボタンの基礎規則	購入、編集、監視などの案固有操作
必要な状態	ローディング、空、エラー	カート、権限、競合などの案別状態

実装では、共通データと案ごとの追加データを分けます。作品解説、購入情報、運営情報を一つの画面都合へ混ぜると、「同じ内容」を比べているのか、案ごとの目的を比べているのかが分からなくなるためです。どの項目を表示し、省略し、導出したかを記録します。

したがって、異なる目的の間で直接比べられるのは、共通タスクの日時発見、内容理解、基礎的なアクセス、共通対象の正確さなどに限定します。購入時間と監視効率を同じ点数にしません。案別タスクは各目的内の受入条件で評価します。

三案を同じ評価軸で順位づけません。A へ「情報密度が低いから良い」、C へ「カードが多いから悪い」と言うことはできません。目的、タスク、利用者、状態が違います。

このケースの必修は三つです。

同じ画面を、知覚・造形・意味・実装・タスクの層に分けて読む
「使いやすい」と「表現が目的に適切」を別々に評価してから統合する
原則名を答えにせず、代替仮説と確認方法まで書く

六つの順序で読む

九章分のチェックリストを一度に当てません。次の順序を一つずつ行います。

構造: 読まずにまとまり、距離、整列、境界を見る
意味: 役割、状態、タイポグラフィ、色が意味をどう示すか見る
時間: ローディング、動き、操作前後、失敗を見る
全体: 大きさの関係、余白、リズム、密度、釣り合いを見る
壊れにくさ: レスポンシブ、ズーム、長文、フォント／画像失敗を見る
仮説: 一つの問題を選び、代替説明、一軸変更、確認指標を書く

必修では、B 案の「残席を見落とす」という一問題を六つの順序で最後まで追います。A／C の全項目は発展比較です。

五つの層との対応は、構造＝知覚／造形、意味＝意味／造形、時間＝意味／実装、全体＝造形、壊れにくさ＝実装／タスク、仮説＝全層の統合です。層は観察対象、順序は読む手順です。

1　三案を、まず名前なしで見る

最初は A／B／C の意図を隠します。各画面を 3 秒見て、最初に気づいた要素を一つ書きます。次に 30 秒見て、何の画面だと思ったか、何ができそうかを書きます。

観察の例

A では大きな写真と短いタイトルがビューポート上部の約 70%を占める。購入ボタンは見えていない。

B では日時、価格、残席、購入ボタンが一つのカード内にあり、同じ構成のカードが四件反復する。

C では状態列、更新時刻、担当者、エラーバッジ、編集コントロールが表の同じ列へ並ぶ。

「A は洗練」「B は使いやすい」「C はごちゃごちゃ」は評価です。最初は面積、位置、数、反復、見える状態を書きます。

3 秒報告の限界

3 秒で残ったものは、短時間提示後の報告です。ページ理解、タスク成功、普遍的な視線順を測ったことにはなりません。提示順、画像、既知のブランドなどにも影響されます。

2　内容を読まずに、知覚される構造を見る

通常表示をグレースケール、ぼかし、矩形化します。文字の意味を減らし、面積、まとまり、階層を見ます。

A

画像と大きな余白が主な面を作り、文字は左下へ小さく集まっています。静かな鑑賞という意図に対応する可能性があります。ただし、日時探索タスクには必要情報が次のビューポートへ出る仮説があります。

B

同じ大きさのカードがグリッド上に反復し、価格と空き状況だけがアクセント色になっています。比較単位は見えますが、すべての購入ボタンが同じ強さなら、選択前の主要操作が四つあるとも解釈できます。

C

画面の大半を表が占め、行と列の反復が強い構造を作ります。高密度ですが、監視タスクでは同時比較を助けるかもしれません。密度の高さと混乱を同一視しません。

一つの加工を真実にしない

ぼかしで消える差は、小さいサイズや低コントラストの手がかりを探す資料になります。しかし、通常視力の読者が実際にそう見ているわけではありません。矩形化も文字の意味と字形を意図的に捨てます。加工ごとに、何を残し、何を失ったかを書きます。

3　距離、整列、境界を重ねる

次に、間隔の図、整列線、見える境界、意味上のまとまりを別の層で重ねます。

距離・Alignment・Regionを示す図。 — 図 I-3　距離・Alignment・Region

近いから同じまとまりとは限らない

B の価格と隣カードのタイトルが、自カード内の説明より近ければ、カード境界線がまとまりを補っているかもしれません。近接と共通領域が競合する条件です。「カードだから一まとまり」とマークアップ名から決めず、距離と境界を指します。

C では、列の整列が比較軸を作ります。一つの長いイベント名で行の高さが増え、状態の水平線が崩れても、列比較は保たれる場合があります。1px のずれではなく、どの連続がタスクに必要かを見ます。

DOM、意味、見えるまとまり

A のヒーロー領域全体が一つの section でも、画像とタイトルが離れすぎれば別まとまりに見えるかもしれません。C の表ラッパーが多数の DOM ノードを持っても、知覚上は列という一つの比較軸になります。

四つの層を記録します。

DOM のコンテナ
意味上のまとまり
画面で見える境界
近接・整列で知覚するまとまり

一致しないこと自体をエラーにしません。タスクに必要な関係が伝わるかを確認します。

4　役割、状態、一貫性を読む

ボタン、リンク、状態、選択中、無効、エラー、ローディングを一覧にします。

Role・State・Consistencyを示す図。 — 図 I-4　Role・State・Consistency

A では、作品名リンクと次作品ナビゲーションが同じ文字スタイルかもしれません。B では、購入可能・残席少・売切が色付きバッジで示されます。C では、警告と失敗のアイコンが同じ形かもしれません。

「同じ役割は同じ見た目」を確認した後、「違う役割が同じ見た目になっていないか」も見ます。さらに例外が意図を持つかを確認します。

状態は静止画一枚では足りない

B の購入ボタンは通常、ホバー、フォーカス、押下中、ローディング、成功、失敗を持ちます。C は更新中、競合、権限不足、保存失敗を持ちます。A にも画像読み込み、音声再生、ページ遷移があります。

完成状態だけでなく、操作前→きっかけ→処理中→完了／失敗→回復を状態表にします。色や動きだけで状態を伝えず、文字、アイコン、プログラム上の状態、フォーカスを確認します。

5　タイポグラフィと色を一緒に見る

タイポグラフィと色を別のスタイルパネルで設計しても、画面では同時に働きます。

Typography・Colorを示す図。 — 図 I-5　Typography・Color

A　表現の調子

見かけの字面が小さく、行間が広く、彩度の低い配色なら、静かな印象に関係するかもしれません。ただし「明朝体＝文化的」「低彩度＝上品」という性格表にはしません。字形、間隔、面積、文脈を指します。

B　比較と操作

価格、日付、空き状況の階層が短時間探索を助ける仮説があります。コントラスト比を測るだけでなく、どの情報を比較し、誤読せず、操作へ進めたかを確認します。

C　密度の中の識別

小さい文字、状態色、行背景が同時に使われます。色だけで状態を伝えず、ラベル、アイコン、模様を加えます。200% 文字拡大や間隔上書きで表が切れないかを確認します。

フォントとテーマが変わる

Web フォント失敗、代替フォント、明るいテーマ／暗いテーマ／強制色で、階層と状態が残るかを三案とも確認します。ブランド表現が変わることと、内容／操作が失われることを分けます。

6　動きを目的と副作用に分ける

三案で異なる動きを使います。

A: 作品間のページ遷移。空間と余韻を表現する
B: カートへ追加した因果と完了を示す
C: ライブ状態が更新された場所を示す

どれも「アニメーション」と呼べますが、目的は違います。開始／中間／終了、継続時間、面積、距離、反復を記録し、動きの約束を書きます。

動きを減らす設定では、A は即時切替と位置ラベル、B は静止したカート件数と完了文、C は更新行の文字／マーカーを残します。動きを消して意味まで消さないこと、通常状態でも反復がタスクを妨げないことを確認します。

7　構成として全体へ戻る

再び画面全体へ戻り、大きさの関係、残った形、リズム、密度、釣り合いを見ます。

A の評価例

大きな画像と連続する余白が鑑賞の意図へ対応している。一方、購入タスクの日時は次のビューポートにある。表現は目的に適切かもしれないが、チケット購入の効率で B より優れるとは言えない。

B の評価例

カードの反復と価格の整列が比較を支える。購入ボタンが四つ同時に強い点は、各カードから購入するタスクには自然かもしれない。「主要操作は一画面に一つ」というルールで減らさず、タスクの流れを確認する。

C の評価例

高い情報密度／操作密度は監視と編集に必要である。エラー、警告、更新済みが同じ視覚的な重さで競合するなら、状態の優先順位を階層へ翻訳する。余白を増やすだけで同時比較を壊さないようにする。

表現と使いやすさを別にしてから統合する

まず二つの表を作ります。

観点	記録
表現	目的との対応、調子、リズム、画像と文字の関係、意図した例外
タスク	完了、時間、エラー、理解、回復、アクセシビリティ

最後にトレードオフを判断します。表現が強くてもタスクが完了できなければ調整が必要です。効率が高くても、文化施設のアイデンティティや作品の扱いが目的と反するなら、それも設計上の問題です。

8　ブラウザで壊し、条件を変える

一枚の完成スクリーンショットで統合判断を終えません。

次を一軸ずつ試します。

390／768／1280px
200% 文字拡大
名前と説明を 2 倍の長さにする
日本語／英語混在
画像失敗
Web フォント失敗
空、ローディング、エラー
動きを減らす設定
暗いテーマ、強制色
キーボードのみ

A の画像中心構成、B のカードグリッド、C の表は、同じ方法では崩れません。ブレークポイントの数字から考えるのではなく、関係が壊れる場所を見ます。

順序を確認する

見える順序、DOM 順、スクリーンリーダーの読み順、フォーカス順を並べます。レスポンシブで見た目を入れ替えても、意味と操作の順序がタスクに合うかを確認します。

9　原則を適用するのでなく、仮説を作る

一つの画面に、複数の説明候補があります。

B で残席を見落とした。

色だけだから区別しにくい
価格の視覚的な重さが強すぎる
空き状況とイベントタイトルの距離が遠い
カードの反復で例外が埋もれた
「残席」のラベルを理解していない
ローディング後に位置が変わった

概念は候補を増やします。答えを自動的に一つへ絞りません。

仮説の形にします。

私は、B 案で残席ラベルが価格より小さく、低コントラストで、カード右端へ離れていることを観察した。階層、近接、色だけに依存していることの複数要因が見落としに関係する可能性がある。まず位置と文字を固定してコントラストだけを変え、次に色を固定して距離だけを変え、残席確認タスクの正答を比べる。

B 必修トラックの連続記録

順序	残席見落としについて記録すること
構造	残席ラベルとイベント／価格の距離、整列、境界
意味	空き状況の役割、売切／残席少状態、文字・アイコン・色
時間	在庫ローディング後の出現、位置変化、更新フィードバック
全体	カード反復内の例外、価格との視覚的な重さ、密度
壊れにくさ	モバイル、ズーム、長いタイトル、強制色、ローディング失敗
仮説	候補、最初の一軸、指標、反証条件

最初の一軸は、観察から直接操作でき、ほかの条件を固定しやすく、重大な失敗を増やさず、仮説間を最も区別できるものを選びます。この例では、文字／位置を固定して色差だけを変えれば、色だけに依存しているという仮説を先に調べられます。ただしプログラム上の状態欠落などの基礎品質の失敗は、実験せず先に修正します。

10　問い――三案を、同じ物差しで裁かずに比べる

操作順

意図を隠して 3 秒報告
30 秒の自由記述
各案の主要タスクを実行
F02〜F07 の重ね表示を一つずつ見る
意図を公開して表現を評価
F08 の条件を一軸ずつ試す
観察→概念候補→仮説→確認を書く

同じ人が A／B／C を続けて行うと、共通内容を学習します。三案の比較では提示順を入れ替え、共通タスク用に同等難度のイベントセットを三組用意します。一人の自習では、速度を案間の公平な実験結果とせず、操作手順を学ぶ記録に限定します。30 秒自由記述は 3 秒提示と別のイベントを使うか、学習済みであるとラベルします。

問い

三案で最初に知覚するまとまりは何か
距離、整列、境界のどれがまとまりを支えるか
同じ役割／状態は一貫し、違う役割は区別されるか
タイポグラフィと色は何の調子と階層を作るか
動きは何を伝え、何を妨げる可能性があるか
大きさの関係、余白、リズム、密度、釣り合いは目的へどう対応するか
表現の適切さとタスクの結果はどう違うか
レスポンシブ／失敗条件で何が失われるか
一つの問題にどんな代替仮説があるか
次に一軸だけ何を変え、何を確認するか

答えの例

十問への評価観点は次の対応です。

まとまり名ではなく、構成要素と境界を指す
距離、線、領域のうち観察できた手がかりを数値／位置で示す
役割×状態×見た目の表の一致と例外を書く
印象語を字形、間隔、色の役割、面積へ戻す
動きの約束と注意／理解／タスク／不快の候補を分ける
全体を見る語彙を目的の意図と循環させず、画面上の形から記述する
表現評定と共通／案別タスク指標を別表にする
条件表のどの状態で、何の関係・内容・操作が失われたか書く
同じ観察に最低二つの概念／デザイン以外の要因を挙げる
固定条件、変更する一軸、確認指標、反証条件を書く

B の残席問題で具体化すると、次のようになります。

カード内でイベント概要と購入情報の二つのまとまりが見える
残席は価格から 24px、タイトルから 48px 離れ、右端へ整列される
購入可能／残席少／売り切れは色だけが変わり、文字の役割が一貫しない
価格は 20px・太字、残席は 12px・低明度で階層が異なる
在庫更新時にバッジが後から現れ、カードの高さが変わる
同じカード反復内で残席少だけが例外だが、大きさの差がない
表現は整然としているが、残席確認タスクの誤りが生じた
モバイルでバッジが次行へ移り、強制色で色相差が消える
色だけ、距離、ラベル理解、ローディング後のずれの候補がある
まず色相以外を固定して文字＋アイコン有無を変え、正答率を比べる

結果が変わらなければ、色だけが主因という仮説は弱まり、距離やラベル理解を次に調べます。

C 案は要素数とタブ停止位置の数が多いが、状態、更新時刻、担当者が列の整列で反復し、監視タスクの比較軸は明確である。私は「ごちゃごちゃ」と評価する前に、ビューポート内の要素密度、タスクに必要な情報項目、操作対象を別々に数える。エラー行発見の時間と誤りを確認する。

A 案のタイポグラフィと大きな余白は、静かな鑑賞という目的へ対応して見える。しかし、開催日時を探すタスクでは次のビューポートまでスクロールが必要だった。表現を全て B 案のように高密度化せず、日時の位置または要約だけを一軸で変える。

B 案の売切状態は赤バッジだけで示される。コントラスト比を満たしても、色そのものへ依存する。売切 文字とアイコンを追加し、カードの見える順序を固定した条件で、購入可能イベントの選択エラーを確認する。

よくある考え方

A は余白が多く洗練、B は UX が良く、C は認知負荷が高い。

注意点

三つの異なる目的とタスクを、スタイルの好みで順位づけています。「UX」「認知負荷」も、何を観察し、誰が何をする条件かがありません。

必須セルフチェック

知覚・造形・意味・実装・タスクの層を分けて記録できる
表現の適切さとタスク結果を別々に評価できる
原則名から代替仮説と一軸比較へ進める

参考

本ケースの理論的な参考は、第 1〜9 章の各エビデンスと章末参考を正本とします。新しい法則を追加せず、どの観察がどの章へ戻るかをエビデンス対応表で追跡します。

第 II 部　人間は、そんなに処理できない

第 I 部では、人間が画面をまとめ、揃い、差、色、文字、画像、動き、構成として知覚する仕組みを見ました。第 II 部では、注意、記憶、判断、運動へ進みます。

ここで気をつけたいのは、うまく使えなかった理由を、すぐに利用者の「能力不足」へ戻さないことです。見落とした、覚えられなかった、選べなかった、押し間違えた。そのどれもが、利用者だけの性質で決まるわけではありません。課題、情報の出し方、既有知識、時間、入力装置、姿勢、周囲の環境との組合せで起こります。

「認知負荷」でまとめない

画面が難しく見えるとき、「認知負荷が高い」と言えば説明できた気になります。しかし、その中には異なる現象が混ざっています。

必要な情報へ注意を向けられない
前の画面の値を頭に保持しなければならない
選択肢の違いを比較できない
操作対象が小さく、正確に狙えない
待ち時間や処理状態が分からない

原因が違えば、確かめ方も変更案も違います。本部では、注意、記憶、再生と再認、選択、運動をいったん分けて観察します。最後に、実際のタスクの中で再び組み合わせます。

実験結果は、条件とともに読む

心理学や人間工学の研究は、Web デザインを考える強い手がかりになります。一方、実験で得られた数値を、そのままメニュー数、ボタン寸法、入力項目数の絶対ルールにはできません。

研究を読むときは、少なくとも次を確認します。

誰が参加したか
何を見て、何を操作したか
どの課題を与えられたか
何を測定したか
どの装置と環境を使ったか
どの範囲まで結論を広げられるか

本書の比較図でも同じです。「良い例」を眺めて終わらず、固定した条件、変えた条件、観察した結果を記します。

人間と画面の間を見る

第 II 部で問うのは、「人間は何個まで覚えられるか」だけではありません。

この画面は、誰に、何を、どの時間だけ保持させているのか。

この選択肢は、数が多いのか。それとも違いが比較できないのか。

このボタンは、小さいのか。それとも操作領域、距離、入力装置との組合せに問題があるのか。

利用者を評価するのではなく、人間と画面の間に作られた処理条件を見ます。それが、第 II 部の出発点です。

第10章　人間は、全部を同時には見られない

画面には、見出し、画像、ボタン、補足、告知、ナビゲーション、エラー、広告が同時に存在します。しかし、ビューポートに入っているものが、同じ強さで処理されるわけではありません。

本章では「目立たせる技法」を覚える前に、何をもって「見た」と言うのかを分けます。画面内に存在したこと、目がそこへ向いたこと、注意したこと、あとで報告できたこと、意味を理解したこと、正しく操作できたことは別です。

この章の必修は三つです。

「見えた」を、存在、注意、報告、理解、行動へ分ける
視覚的顕著性と情報の重要度を同一視しない
「メリハリがない」を、比較可能な観察へ書き換える

10.1〜10.2 で一つ目、10.3〜10.5 で二つ目、10.6〜10.8 で三つ目を扱います。視線計測、50 ミリ秒提示、計算による顕著性マップは発展です。特別な装置がなくても、3 秒の短時間提示、探索タスク、一変数比較で必修を完了できます。

この章で見るもの

同時に表示されていても処理されない情報

短時間提示で測れることと測れないこと

大きさ、色、コントラスト、動き、顔

視覚的階層と優先順位

複数の主要操作

顕著性、探索、理解、タスク成功の違い

10.1 見えていても、注意しているとは限らない

申込ページの上部に「受付は本日 17 時まで」と表示されています。利用者は画面を開き、申込ボタンを押し、入力を始めました。その後で締切を尋ねると答えられませんでした。

このとき「締切を見ていない」と言いたくなります。しかし、少なくとも次を区別できます。

締切はビューポート内に存在した
目がその領域に向いた
その文字へ注意を向けた
文言を直後に報告できた
意味を理解した
締切を考慮して行動した

区分	記録の候補	言えること	まだ言えないこと
画面内の存在	DOM、スクリーンショット、ビューポート	対象が提示範囲にあった	目や注意が向いた
視線位置	条件を記録した視線計測	眼球が対象領域へ向いた	注意した、理解した
注意	手がかり、報告、成績等から限定的に推論	指定した理論とタスク内の仮説	真偽値として注意を確定する
直後報告	自由再生、再認、質問	指定した質問へ報告できた	最初に視線が向いた、深く理解した
理解	言い換え、適用問題、選択理由	指定内容をタスク上使えた	別の状況でも理解している
行動	探索時間、選択、完了、エラー	指定タスクで起きた行動	内的な理由、一般的能力

最初の一つはスクリーンショットで確認できます。二つ目には視線計測が必要です。注意そのものは単純な一層として直接読み取れず、課題と理論を定めて複数の手がかりから推論します。一つを測って、残りまで証明したことにはできません。

注意は能力不足の言い換えではない

人間がすべてを同時に処理しないことは、怠慢や能力不足ではありません。目的に関係するものを選ぶことで、行動に必要な処理を進めています。日時を探す人と、出演者を探す人では、同じ画面でも選ぶ情報が変わります。

Simons と Chabris の実験では、参加者が映像内のパスを数える課題に取り組むと、途中に現れる予期しない出来事を報告しない場合がありました。この現象は非注意性盲目を考える代表例です。ただし、Web 利用者も同じ割合でバナーを見落とす、という法則ではありません。刺激、課題、期待、質問方法が違います。

課題によって見落としが変わるを示す図。 — 図 10-2　課題によって見落としが変わる

10.2 3 秒で何が残るか

画面を 3 秒だけ提示し、隠したあとで尋ねます。

何のページだと思いましたか
最初に思い出したものは何ですか
申込方法は分かりましたか
どの文言を覚えていますか

これは、初期の理解や報告を比べるための有用なプローブです。しかし、3 秒は人間の認知能力を分ける普遍的な境界ではありません。2.9 秒では分からず、3.0 秒なら分かるわけではありません。

Lindgaard らの研究では、非常に短い提示後にも Web ページの視覚的魅力を評定でき、その評定に一貫性が見られました。ここから「50 ミリ秒で Web サイトを理解する」とは言えません。測られたのは限定された刺激に対する視覚的魅力の評定であり、内容理解、信頼、操作成功とは別です。

3 秒テストの記録

比較するなら、次を固定または記録します。

参加者へ伝えた課題
表示前の画面と開始位置
デバイス、ビューポート、ズーム
提示時間
アニメーションや画像読込の状態
隠した後の質問と順番
自由回答か選択式か
同じ画面を以前に見たか

自由再生で出なかった情報を、選択肢から再認できることがあります。「思い出せなかった」と「見れば分かる」も分けます。結果は診断名ではなく、次の比較を作る材料です。

質問も一つの得点へまとめません。「何のページか」は目的推定、「最初に思い出したもの」は自由再生、「申込方法は分かったか」は自己評価、「覚えた文言」は記憶報告です。50 ミリ秒条件をブラウザで試す場合は表示フレーム、リフレッシュレート、事前読込、マスク、実測時間が必要であり、元研究の再現とは呼びません。

10.3 大きさ、色、コントラスト、動き、顔

画面の一部は、周囲との差によって目立ちます。大きい、明暗差が大きい、一つだけ色が違う、動いている、人物の顔がある、といった特徴は注意の候補になります。

顕著性の変数を一つずつ変えるを示す図。 — 図 10-4　顕著性の変数を一つずつ変える

重要なのは、「赤は目立つ」のように属性単体で覚えないことです。赤いボタンが赤い背景上にあれば差は小さくなります。大きな画像が並ぶ画面では、大きさだけで一つを区別できません。動きも、常時動く要素が複数あれば競合し、読み取りを妨げます。

顕著性は関係です。対象と周囲、同時に見える要素、時間変化、利用者の課題との関係で考えます。

顔や動きを万能な誘導装置にしない

顔は社会的に意味のある刺激であり、動きは変化を知らせます。しかし、顔が必ず最初に見られる、視線方向へ必ず誘導される、アニメーションなら必ず通知に気づくとは言えません。画像内容、切り抜き、課題、文化、予測、周辺の強さが関わります。

動きは注意以外の条件も持ちます。意味のない反復は読む作業を妨げ、前庭障害等の症状を引き起こす可能性があります。prefers-reduced-motion への対応や停止手段は、誘導効果とは別に確認します。

10.4 視覚的階層は重要度の翻訳である

視覚的階層とは、ただ見出しを大きくすることではありません。内容や操作の優先順位を、大きさ、位置、間隔、太さ、色、コントラスト、画像、動き等の差へ翻訳した関係です。

この語彙は Web だけの発明ではありません。絵画の構図、新聞や書籍の版面、ポスター、広告、標識などは、媒体ごとの目的と制約の中で読む順序や強弱を編集してきました。固定された紙面の手法をそのままレスポンシブな画面へ移すのではなく、ビューポート、状態、操作、読み順の変化を含めて借ります。階層は自然に発見される唯一の順序ではなく、制作者が内容を選び、関係づけた編集結果です。

翻訳の前に、誰にとって、どの時点で重要かを確認します。

事業者が知らせたい新商品
利用者が今探している配送状況
法的に必要な注意
入力エラーの回復
次へ進む主操作

これらは同時に重要でも、同じ強さにする必要はありません。エラーは通常時には存在せず、発生時だけ局所的に優先されます。配送状況は購入前より購入後に重要です。状態とタスクを含めて優先順位を組み立てます。

利用者・時点	内容	放置したリスク	必要な反応	画面上の候補	確認方法
初めて申込む人・入力前	締切	受付終了後に入力する	期限を理解する	フォームの前に締切を置く	締切確認タスク
入力中・送信後	エラー	修正箇所が分からない	エラーへ戻る	概要と項目を関連づける	回復完了と誤修正
購入済み・配送中	配送状況	問合せが増える	現在地を確認する	注文単位で状態を示す	注文探索タスク

図 F05-C では、この表を完成画面へ戻します。締切をフォーム直前に置き、締切と申込ボタンの間を 8px、次のセクションまでを 32px にします。これらの値は正解ではなく、優先順位を位置と距離へ翻訳した比較候補です。初期案と同じタスクで確かめます。

観察から確認までの判断手順

利用者、時点、主課題、エラー／回復条件を特定する
内容の優先順位を表にする
現在のサイズ、位置、間隔、コントラスト、動きを観察する
優先順位との不一致を仮説にする
一変数だけ変える
探索、理解、操作、回復のどれで確認するか決める
ページ全体と別状態へ戻り、副作用を見る

最初に見えるものは最重要か

ブランドイメージを最初に感じ、その後で申込ボタンを見つける設計はあり得ます。最初に見えるものと、最初に操作すべきものが同じとは限りません。問題は順番そのものではなく、目的に必要な情報へ到達できるか、誤解や見落としを生まないかです。

10.5 主要ボタンが三つある画面

同じビューポート内に、同じ強い色のボタンが三つあります。「主要ボタンは一つにする」というレビューだけでは足りません。

図 10-6　三つの Primary Button

三つが「申込む」「資料請求」「相談する」という競合する次の一手なら、利用者は優先順位を読み取りにくい可能性があります。一方、商品カードごとに「詳細を見る」が一つずつある一覧なら、各カードの範囲で同じ操作を反復しているだけかもしれません。

ここでいう主操作、つまり primary action は、利用者がその作用範囲で次に行う中心的な操作です。デザインシステムの primary という見た目のバリエーションとは分けます。確認する観点は数より作用範囲です。

ページ全体の主タスクは何か
セクションごとの主タスクは何か
同時に見えるボタンは同じ決定を競うか
操作の結果と取り消しにくさは同程度か
カードやダイアログの境界は知覚できるか
キーボードフォーカスやスクリーンリーダーでも関係が伝わるか

必要なら、ラベル、まとまり、位置、段階的開示、ボタンスタイルを変えます。色を弱くするだけが解決ではありません。

10.6 「メリハリがない」を観察へ変える

「メリハリがない」は違和感の入口としては役立ちますが、変更箇所を決められません。

「メリハリがない」を書き換えるを示す図。 — 図 10-7　「メリハリがない」を書き換える

次のように書き換えます。

ページタイトル 32px、セクション見出し 28px で、大きさの差が小さい
本文、補足、更新日が同じ色と太さで、役割差が見えにくい
三つの操作が同じ塗りボタンで、同時に競合して見える
ヒーロー画像の明暗差が申込ボタンより大きい
セクション間と項目内の gap がともに 24px で、まとまりの階層が距離に現れていない
エラー文が補足文と同じ位置、色、アイコンで、状態変化を区別しにくい

これで初めて「Title を 40px にする」「補足を薄くする」などの候補を作れます。ただし、値の変更は仮説です。一つだけ変え、同じ条件で比べます。

10.7 顕著なら見つかるとは限らない

画面中央で動く赤いバナーは目立ちます。しかし、利用者が探しているのは右上の「領収書を発行」です。バナーが先に注意を引けば、目的の対象はむしろ見つけにくくなるかもしれません。

視覚探索では、対象と紛らわしい候補の類似、要素数、配置、探索戦略、事前に知っている形が関わります。「一つだけ赤い」は色を手がかりに探す課題では有効でも、「請求」という意味を探す課題を必ず助けるわけではありません。

Itti と Koch らの計算モデルは、画像内の局所的な差から、刺激の特徴だけで生じるボトムアップな顕著性を予測する考え方を示します。顕著性マップは有用な仮説道具ですが、利用者の課題、知識、意味理解をすべて含む地図ではありません。ヒートマップ風の画像を作って、実際の視線データと呼んではいけません。

調べ方を選ぶ

知りたいことに対応して方法を選びます。

知りたいこと	手がかりになる方法
何が画面内に存在したか	DOM、スクリーンショット、ビューポート記録
最初に何を報告したか	短時間提示後の自由回答
どこへ眼球が向いたか	条件を記録した視線計測
対象を見つけたか	探索タスク、時間、誤選択
内容を理解したか	説明、適用問題、行動
目的を達成したか	タスク完了、エラー、時間、観察

どの方法にも取りこぼしがあります。複数の結果が一致しないことも、設計を考える材料です。

10.8 問い――最初に見えるものは、最重要か

イベント申込ページを 3 秒見たあと、次を記録します。

問い

最初に報告した要素は何ですか。
このタスクで最も重要な情報は何ですか。
両者は同じですか。違うなら、それは問題ですか。
画面上のどの差が報告へ関係した可能性がありますか。
別のタスクなら、どの要素が重要になりますか。
仮説を確かめるため、何を一つだけ変えますか。

答えの例

最初に報告されたのは出演者の顔写真でした。申込タスクで必要な締切とボタンは、写真より面積と明暗差が小さく、写真の直下に埋もれて見えます。写真の切り抜きまたはコントラストを抑え、締切とボタンを近接させると、申込に必要な情報を見つける時間が短くなる可能性があります。同じ内容、タスク、ビューポートで比較します。

これは実測結果ではなく、回答文の形式例です。自分の記録へ置き換えるときは、六問を次の観点で確認します。

最初の報告: 誰が、どの提示条件で、どの質問へ答えたか。視線とは呼ばない。
最重要: 利用者、時点、タスク、リスクを明記する。
一致の評価: 違いが探索、理解、操作、回復を妨げる条件を書く。
画面上の差: サイズ、位置、間隔、コントラスト等を比較対象つきで記す。
別タスク: 同じ画面でも優先順位が変わる反例を一つ挙げる。
確認: 固定条件、変更する一軸、指標、仮説を反証する結果を書く。

別の答え方

顔写真が最初でも、イベントの内容を理解してから申込む順序としては妥当かもしれません。問題は初見の順ではなく、申込を決めた後に締切とボタンを探索できるかです。自由観察ではなく「申込期限を確認して申し込む」タスクで調べます。

よくある考え方

ボタンをもっと目立たせます。

注意点

何に対して、どの変数で、どのタスクを助けるために目立たせるのかがありません。ボタンだけを強くすると、エラー、価格、締切との関係を壊す可能性もあります。

セルフチェック

「見た」を、存在、視線、注意、報告、理解、行動へ分けられる
顕著性と情報の重要度を別に説明できる
曖昧な「メリハリ」を観察文と検証可能な仮説へ書き換えられる

参考

Simons & Chabris (1999), “Gorillas in our midst,” DOI: 10.1068/p281059 — 入口〜専門。方法とタスク条件を読み、Web 上の見落とし率へ一般化しません。
Itti & Koch (2001), “Computational modelling of visual attention,” DOI: 10.1038/35058500 — 専門。ボトムアップな計算モデルのレビューです。モデル出力を実測視線にしません。
Folk, Remington & Johnston (1992), “Involuntary covert orienting is contingent on attentional control settings,” DOI: 10.1037/0096-1523.18.4.1030 — 専門。タスク構えと注意捕捉を考える入口です。
Lindgaard et al. (2006), “Attention web designers: You have 50 milliseconds to make a good first impression!,” DOI: 10.1080/01449290500330448 — 入口〜専門。視覚的魅力評定の実験であり、内容理解の研究として引用しません。
W3C, WCAG 2.2 Understanding SC 2.2.2／2.3.3 — 入口。動きの停止と安全性を確認する公式資料であり、注意誘導効果の証明ではありません。
検索キーワード: selective attention、inattentional blindness、visual salience、attentional capture、visual search、first impression、task set

第11章　人間は、一度にたくさん覚えられない

長いフォーム、項目の多いダッシュボード、候補が並ぶ設定画面を見て、「情報量が多いから認知負荷が高い」と言うことがあります。しかし、画面に百項目あっても検索と比較が容易な場合があります。反対に、項目が三つだけでも、前画面の値を覚え、換算し、更新しながら選ぶなら難しくなります。

本章で数えるのは、画面上の箱ではありません。利用者がタスク中に、頭の中で何を保持し、更新し、変換しなければならないかです。

本章では共通の判断手順を使います。タスクの流れを時間順に書き、保持・更新・変換・参照を記録表にし、画面へ残す候補を一つ選びます。内容、タスク、知識、状態を固定して比較し、完了、エラー、戻り、再確認と副作用を見ます。結果が変わらなければ、記憶以外の仮説へ戻ります。

この章の必修は三つです。

画面上の項目数と、記憶しながら処理する内容を分ける
7±2 や 4 チャンクを UI の個数制限へ変換しない
「認知負荷が高い」を、保持・更新・変換を含む観察と仮説へ書き換える

この章で見るもの

区切りが読み取りと照合を助ける条件

短期的な保持と、保持しながら行う処理

Miller と Cowan の研究が扱った課題

知識と熟達がチャンクを変える仕組み

フォームとダッシュボードで画面へ残せる情報

認知負荷理論を UI へ借りるときの限界

11.1 電話番号の区切りが助けるもの

0312345678 と 03 1234 5678 を比べます。後者は、読み上げる位置、写した位置、桁数を照合しやすくなる可能性があります。空白を入れれば人間の記憶容量が増えるわけではありません。課題に使えるまとまりと手がかりが画面上に残ります。

見た目の区切りとデータ構造

電話番号を三つの入力欄へ分割すると、見た目のまとまりは明確になります。一方、貼り付け、モバイルの自動入力、選択、修正、スクリーンリーダーでの移動が複雑になる場合があります。一つの入力欄で表示だけ整形する方法もあります。

判断するには、何を助けたいかを特定します。

読み上げる
紙から写す
桁数を確認する
全体を貼り付ける
国番号を選ぶ
間違った部分だけ直す

「チャンク化したから良い」ではなく、どのタスクのどのエラーを減らす仮説かを書きます。

11.2 短期記憶とワーキングメモリ

6 桁の確認コードを一時的に覚えて別欄へ入力する課題と、そのコードを覚えたまま価格を足す課題を比べます。どちらも短時間の記憶を使いますが、後者は保持と処理を同時に行います。

短期記憶は、情報を短い時間保持する働きを指す文脈で使われます。ワーキングメモリは、保持しながら理解、推論、計算、更新などを行う仕組みを説明する概念です。理論モデルは一つではなく、両者の境界も用語の立場によって異なります。

Web デザインで重要なのは、脳内の部品名を画面へ貼ることではありません。タスクを時間順に書きます。

プラン A を選ぶ
次の画面で人数を入力する
前画面にだけあった一人当たり価格を思い出す
合計を計算する
予算内か判断する

この流れでは、プラン、単価、人数、途中の計算結果を保持・更新します。プランと単価を要約として残せば、利用者は見比べられます。ただし、要約が古い、折りたたまれている、スクリーンリーダーで遠いなら、画面へ残しただけでは助けになりません。

図 F02 の A、B、C は、保持だけ、保持しながら処理、情報を画面へ残した処理という異なる状況の説明図です。三面を提示時間だけの因果比較にはしません。画面へ残す効果を比べるなら、B と C で加算タスク、コード、提示、参加者割付を揃え、コードの表示だけを変えます。

11.3 Miller の 7±2 は何を測ったか

「Miller の法則により、メニューは 7 項目以下にする」という説明を見かけます。Miller の 1956 年の論文は、その Web デザイン規則を実験したものではありません。

Miller 原典と誤変換を示す図。 — 図 11-3　Miller 原典と誤変換

論文では、音の高さなどを区別してラベル付けする絶対判断と、刺激列を直後に再生する記憶範囲など、異なる研究が論じられています。情報を馴染みのある単位へ再符号化するチャンク化も重要な話題です。題名の 7±2 だけを切り取り、画面要素の上限へ移すと、課題も測定も失われます。

メニュー項目が 12 個でも、すべてが見え、意味のある分類と明確なラベルがあり、利用者が目的語を知っていれば見つけやすいことがあります。6 個でも、曖昧なラベルを覚えて階層間を往復するなら難しくなります。

数を減らす前に、次を観察します。

全候補は同時に見えるか
思い出すのか、画面から探せるのか
分類名を理解できるか
階層を移動すると前の候補が消えるか
選択後に比較へ戻れるか
タスクに不要な候補をフィルターできるか

11.4 Cowan の 4 チャンクは「4 個まで」ではない

Cowan は、声に出さず頭の中で繰り返すリハーサルや、長期記憶によるまとまり化等の影響を抑えた条件を検討し、容量限界をおおむね 3〜5 チャンクと論じました。ここから「カードは 4 枚まで」とは言えません。

Cowan の 4 チャンクを示す図。 — 図 11-4　Cowan の 4 チャンク

項目とチャンクは同じではありません。F B I C I A N H K は、ある人には 9 文字、別の人には FBI、CIA、NHK という三つの馴染みあるまとまりになります。どの単位が一チャンクになるかは、知識、言語、経験、課題で変わります。

また、研究上の推定値には条件があります。提示時間、保持時間、妨害課題、順序を答えるか、項目を答えるか、リハーサルをどのように抑えるかによって成績は変わります。「4」は人間一般の固定枠数でも、画面上の安全な個数でもありません。

11.5 チャンクは、見た目だけでは作れない

境界線で四項目を囲み、見出しを付ければ、視覚上のまとまりはできます。しかし、利用者にとって意味ある一単位になるとは限りません。

注文管理の熟練者は、「未決済」「入金済み・未出荷」「配送事故」の状態を、次に行う業務と結び付けて見ます。初心者には、ステータスコード、配送会社、決済種別が別々の値に見えるかもしれません。熟練者のまとまりは、色付きカードだけで作られたのではなく、反復経験と領域知識に支えられています。

Chase と Simon のチェス研究は、熟達者が意味ある盤面配置をまとまりとして捉える一方、ランダム配置ではその優位が小さくなることを示す古典的な入口です。これは「専門家ならダッシュボードを何個でも覚えられる」という証明ではありません。意味ある関係と既有知識が記憶の単位を変える可能性を考える資料です。

図 F05 の「初心者」「熟練者」は、実測前の架空人物ではありません。実施時は、業務経験、使用頻度、用語理解、対象タスクの経験を記録し、参加者自身のまとまり方と理由を採取します。経験年数だけで能力を固定しません。

UI が知識を育てる

知識依存だから設計できない、ということではありません。一貫したラベル、状態と操作の対応、凡例、例、履歴、段階的な開示は、利用者が規則を学ぶ手がかりになります。ただし、初回から熟練者の略語だけを見せれば、学習前の利用者を置き去りにします。

11.6 長いフォームで頭に保持させているもの

長いフォームの問題を項目数だけで説明しません。利用者が頭に残すものを「保持台帳」へ書き出します。

段階・必要時点	出所／参照	保持・更新・変換	リスク	画面へ残す候補・鮮度	副作用・反証
プラン選択後・人数入力時	前ステップのプラン名と料金	プランを保持、人数と合計を更新、一人当たり→合計	誤プラン、計算エラー	常時表示する概要。選択変更時に同期	画面占有。戻りやエラーが減らなければ記憶仮説を再検討
住所入力・入力直前	項目ラベルと入力規則	規則を保持、未入力を更新、表記を変換	形式エラー	例と局所エラー。検証時に更新	説明過多。エラー率が同じならラベルや自動補完を疑う
確認・送信前	入力値と料金計算	変更箇所を保持、合計を更新、税別→税込	誤送信	差分と計算根拠。全変更後に再計算	重複表示。確認時間だけ増えるなら構成を再検討
エラー後・修正時	エラー概要と該当項目	エラー箇所を保持、修正済みを更新、コード→意味	未修正、値消失	概要と項目を関連付け、最新状態を示す	フォーカス跳躍。回復が改善しなければ規則自体を疑う

この保持台帳は章全体で使う観察メモです。「保持」は今見えないが後で同じ形で必要な内容、「更新」は状態に応じて置き換える内容、「変換」は単位・表記・計算・コードと意味の対応、「参照」は画面上で見直せる出所です。必要時点、リスク、鮮度、占有、プライバシー、重複、読み順、通知増加、反証条件まで記します。

画面へ情報を残すことには副作用があります。概要が画面を占有し、モバイルで本文を圧迫するかもしれません。自動計算の根拠が見えなければ、数字を信頼できません。すべてを表示するのではなく、必要な時点に、対象と近く、最新状態で残します。

実装と接続する

選択内容を次画面の見出しや概要へ残す
入力規則をプレースホルダーだけに置かない
エラーを項目とプログラム上も関連付ける
エラー後も正しい入力値を失わない
合計の更新をテキストでも通知する
ステップ数より、戻れることと現在地を示す

複数ステップに分ければ自動的に負担が減るわけではありません。前ステップが見えなくなり、比較のために往復するなら、保持要求が増える場合があります。

11.7 ダッシュボードは情報が多いから難しいのか

ダッシュボードには数値、グラフ、警告、表が多数あります。これを単に「情報過多」と評価すると、業務に必要な比較対象まで消す危険があります。

Dashboard の三つの Taskを示す図。 — 図 11-7　Dashboard の三つの Task

同じダッシュボードでもタスクを分けます。

監視: 変化や異常に気づく
探索: 一件の注文を見つける
比較: 六店舗の値と推移を比べる
更新: フィルターや期間を変え、結果を追う
判断: 閾値と業務知識を使って操作を選ぶ

監視には同じ位置と安定した更新規則が助けになるかもしれません。探索には検索、フィルター、明確なラベルが必要です。比較では値を同時に見える状態へ残すことが重要です。情報を別ページへ隠すと、一画面は静かでも記憶から比較することになります。

初心者と熟練者

初心者には用語説明と例が必要で、熟練者には密度と操作速度が重要かもしれません。どちらかを「人間に優しい」唯一の画面にしません。段階的な開示、表示プリセット、詳細切り替え等で異なる知識状態を支える候補を作ります。

11.8 認知負荷理論を UI 評価へ持ち込むとき

認知負荷理論は、物事を理解するための知識構造であるスキーマの獲得を目的とする、学習と問題解決の研究から発展しました。教材の説明、例題、問題解決手順をどう設計するかという文脈があります。

Web 画面へ応用を考えることはできます。しかし、「カードが多いから外在的負荷」「業務が難しいから内在的負荷」と画面部品へラベルを貼れば診断が終わるわけではありません。学習目標がない短い購入タスクと、知識獲得を目的にする教材では、評価したい結果が違います。理論内の分類も更新と議論があります。

本章の保持台帳は認知負荷理論の正式な分類表ではありません。また、人間工学上の作業負担や主観的な難しさとも同義ではありません。使う理論、タスク、測定を明記します。

まず観察の言葉へ戻します。

認知負荷が高い。

ではなく、

利用者は前画面のプラン名と単価を保持し、現在画面の人数で合計へ変換し、予算と比較する必要がある。プラン名と単価を現在画面へ残すと、前画面へ戻る回数と計算エラーが減る可能性がある。

と書きます。この仮説なら比較できます。

一つの数値で測れない

完了時間、エラー、戻り、二重課題成績、主観評定、生理指標は、それぞれ異なる手がかりです。時間が短くても不正確かもしれず、本人が簡単だと答えても重要なエラーが残ることがあります。知りたい現象に合わせ、複数の記録を選びます。

11.9 問い――利用者は何を覚えたまま操作するのか

イベント申込の流れを、プラン選択、情報入力、確認の順に見ます。

問い

各段階で、画面から消えるが後で必要になる情報は何ですか。
利用者は何を保持し、更新し、変換しますか。
それは初心者と経験者でどう違う可能性がありますか。
どの情報を画面へ残せますか。
外在化すると、どんな副作用がありますか。
何を測れば仮説を疑えますか。

答えの例

プラン選択後、プラン名と一人当たり価格が消えます。利用者は人数入力中も単価を保持し、合計へ変換し、予算と比較する必要があります。入力画面へプラン名、単価、自動更新する合計を残すと、前画面へ戻る回数と計算エラーが減る可能性があります。固定するのはプラン、価格、タスク、参加者の事前知識です。概要の有無を変え、完了、エラー、戻りを記録します。

六問への回答では、消える情報と必要時点、保持・更新・変換・参照の区別、知識差の確認方法、外在化する一変数、副作用、固定条件、指標、仮説を支持しない結果が揃っているか確認します。

別の答え方

経験者は価格帯を知っており、Plan 名だけで合計を概算できるかもしれません。それでも、料金改定後や割引条件では既有知識が誤りになります。熟練者向けに情報を消すのではなく、表示密度や展開状態を選べる案を比べます。

よくある考え方

項目を 4 個ずつに分けます。

注意点

4 個という数が、タスク上の一チャンクとは限りません。ステップを増やして前の情報を隠すと、保持と往復が増える可能性があります。

セルフチェック

画面の項目数ではなく、保持・更新・変換する内容を列挙できる
Miller と Cowan の数値を、メニューやカードの上限にしていない
外在化の変更、確認指標、副作用、反証条件を説明できる

参考

Miller (1956), “The Magical Number Seven, Plus or Minus Two,” DOI: 10.1037/h0043158 — 原典。絶対判断、記憶範囲、再符号化を分けて読みます。
Cowan (2001), “The magical number 4 in short-term memory,” DOI: 10.1017/S0140525X01003922 — 専門。要旨だけで「4 個ルール」にせず、統制条件と 3〜5 という議論を読みます。
Baddeley & Hitch (1974), “Working Memory,” DOI: 10.1016/S0079-7421(08)60452-1 — 専門。歴史的モデルの原典であり、唯一の理論とはしません。
Chase & Simon (1973), “Perception in Chess,” DOI: 10.1016/0010-0285(73)90004-2 — 専門。熟達、意味ある配置、ランダム配置の差を確認します。
Sweller (1988), “Cognitive Load During Problem Solving,” DOI: 10.1207/s15516709cog1202_4 — 専門。学習とスキーマ獲得の文脈から読みます。
Scaife & Rogers (1996), “External cognition,” DOI: 10.1006/ijhc.1996.0048 — 専門。外的表現がタスクを助ける仕組みを考える HCI 資料です。
検索キーワード: short-term memory、working memory、chunking、memory span、cognitive load theory、expertise、external cognition

第12章　人間は、覚えるより見つける方が得意

知っている人の名前が出てこないのに、名簿を見ればすぐ分かることがあります。検索語を正確に思い出せなくても、候補を見れば目的のものを選べることがあります。

この違いを、再生（recall）と再認（recognition）という言葉で考えます。ただし、本章の結論は「入力させず、全部候補にする」ではありません。候補を探し、似たものを区別し、正しいと判断することにもコストがあります。

この章の必修は三つです。

操作中に頭から生成させている情報を見つける
手がかりを見せる案と、候補を識別するコストを一緒に評価する
再生より再認を、心理学の絶対法則ではなくユーザビリティ上の仮説として使う

12.1〜12.2 では課題の違い、12.3〜12.5 では Web 上の手がかりと状態、12.6〜12.8 では経験則の射程、コスト、比較方法を扱います。読むだけなら各節の観察表、試すなら F03 と F05、他者を観察するなら同意と実測手順を使います。

各例では、記憶要求→手がかり→識別／判断コスト→比較という判断手順を使います。まず頭から生成している内容と必要時点を書き、手がかり候補を一つ選びます。候補集合、ラベル、順序、鮮度、プライバシーを確認し、一軸だけ変え、完了、エラー、時間、副作用を見る。結果が改善しなければ、記憶以外の仮説へ戻ります。

心理学上の課題語	UI で観察する語
自由再生	ラベルやコマンドを頭から生成する
手がかり再生	頭文字、カテゴリ、文脈から生成する
再認	提示候補と記憶を照合する
手がかり／符号化文脈	入力時点で見えていた情報、学習経験
探索・識別・判断	候補を探し、属性を区別し、確定する

右列は左列の直接測定値ではありません。UI の行動を心理学用語で診断せず、タスク条件を明記します。

この章で見るもの

自由に思い出す課題と、候補から選ぶ課題

CLI、コマンドパレット、ショートカット

オートコンプリートと検索候補

最近使った項目、履歴、パンくず、ステップ表示

ラベル、プレースホルダー、説明、エラー

候補過多、曖昧さ、古さ、プライバシー

12.1 名前を思い出すことと、顔を選ぶこと

「昨日会った担当者の名前を書いてください」と言われると、頭の中から名前を生成します。顔写真と名前が並ぶ名簿から選ぶなら、候補と記憶を照合します。

名前を思い出す／顔から選ぶを示す図。 — 図 12-1　名前を思い出す／顔から選ぶ

前者は自由再生、後者は再認に近い課題です。間に、姓の最初の文字を示す手がかり再生もあります。実際の UI は、この三つを組み合わせます。

図 F01 は自由再生と顔候補の成績を競わせる実験ではありません。顔、名前、入力形式、候補集合が同時に変わる説明図です。厳密に比較するなら、学習時の刺激、対象、回答形式、妨害候補、遅延を揃えた別の実験計画が必要です。

再認は候補があれば必ず成功するわけではありません。写真が古い、似た人が多い、名前が同じ、候補に対象がない場合があります。誤った候補を「見覚えがある」と選ぶこともあります。何を手がかりとして示し、何を区別できる情報にするかが重要です。

12.2 CLI と GUI は何を覚えさせるか

会場を作成する CLI で、利用者はコマンド名、オプション、順序、引用符を思い出します。コマンドパレットなら、venue と入力した時点で候補と説明を見られます。

CLI は再生、GUI は再認、と二分はできません。CLI にもシェル補完、履歴、ヘルプがあります。GUI にも、隠れたジェスチャー、アイコンの意味、深いメニュー位置を思い出させる場合があります。

熟練者は短いコマンドやショートカットを再生できるため、候補を順に探すより速いかもしれません。初学者には候補と説明が学習を支えます。両者をつなぐ設計があります。

メニューにショートカットを併記する
コマンドパレットで検索と実行を一つにする
最近使ったコマンドを示す
--help と例をその場で取得できる
入力途中に構文候補を示す

「再認へ置き換える」だけでなく、覚えた人が速く進める経路も残します。

12.3 オートコンプリートと検索候補

会場名を正確に思い出せない利用者が shi まで入力します。候補に「市民会館」「新宿文化センター」「潮見ホール」が現れれば、綴り、語彙、検索範囲の手がかりになります。

オートコンプリートと検索候補は、単に入力を短くする機能ではありません。

利用できる語彙を見せる
表記揺れを吸収する
検索対象の範囲を教える
同名候補へ住所等の識別情報を加える
過去の検索語や人気候補を示す

ただし、候補の出所を混ぜると判断しにくくなります。「登録済み会場」「過去の検索」「一般的な候補」は、意味と選択後の結果が違います。セクション、ラベル、説明で区別します。

Combobox は見た目だけではない

編集可能なコンボボックスには、入力値、ポップアップの開閉、現在候補、選択値、キーボード操作、読み上げがあります。下矢印で候補へ移り、Escape で閉じ、Enter で確定したとき、入力値がどうなるかを状態として設計します。

IME 変換中に候補更新してよいか、ネットワーク待ちの古い応答を捨てるか、タッチでキーボードが開いた狭いビューポートに何件表示するかも確認します。WAI-ARIA APG はパターンの入口ですが、実際のブラウザと支援技術の組合せで検証します。

12.4 最近使った項目、履歴、パンくずリスト

これらはすべて「前のものを見せる」機能ではありません。答える問いが違います。

手がかり	答える問い	例
最近使った項目	最近使った対象は何か	最近編集したイベント
履歴	どの順で行動したか	閲覧・変更履歴
パンくずリスト	情報構造のどこにいるか	組織 > イベント > 申込
ステップ表示	手続きのどこまで進んだか	2 / 4 情報入力

パンくずリストは、ブラウザの戻る履歴とは限りません。利用者が辿った順ではなく、現在位置の階層を示す場合があります。ステップ表示も、完了済みステップへ戻れるか、分岐で総ステップ数が変わるかを別に設計します。

最近使った項目は再探索を助けますが、古い項目を選ぶ、共有端末に機微な名前が残る、別アカウントの履歴が混ざるリスクがあります。保持期間、削除、保存範囲、同期を仕様にします。

12.5 消えるプレースホルダーが奪う手がかり

メールアドレス入力欄に name@example.com とだけ表示されています。入力を始めると文字は消えます。入力後、その欄が「連絡先メールアドレス」か「公開用メールアドレス」か、形式例が何だったかを画面から確認できません。

図 12-5　消える Placeholder

ラベル、例、説明、値、エラーは役割が違います。

ラベル: 何を入力する欄か
例: どのような値か
説明: 必須条件や形式
値: 利用者が入力した内容
エラー: 現在値の何が受け付けられないか

プレースホルダー一つにまとめると、入力前にしか見えない手がかりになります。永続するラベルを置き、必要な説明を入力前から見えるようにし、エラーを該当項目へ関連付けます。

フローティングラベル、つまり入力中に小さく移動するラベルも、動けば自動的に解決するわけではありません。縮小後の可読性、値との区別、アニメーション、自動入力、ズーム、支援技術を確認します。

12.6 「再生より再認」の出自と射程

「再生より再認」は、Nielsen のユーザビリティ経験則の一つとして広く知られています。要素、操作、選択肢を見える状態にし、画面間で情報を覚えさせず、必要情報を容易に取得できるようにする考え方です。

これは記憶研究のすべてを一文に要約した心理学法則ではありません。再生と再認は、学習方法、手がかり、文脈、紛らわしい候補、遅延、回答基準が異なる課題です。再認に失敗し、別の手がかりからは再生できる現象も研究されています。

UI へ戻すと、候補は常時表示だけではありません。

必要情報を現在画面へ残す
ヘルプや履歴から容易に取得できる
初学者には候補、熟練者にはショートカットを用意する
入力途中に範囲と構文を示す

画面を候補で埋めるのではなく、必要な時点で取得できる手がかりを設計します。

12.7 再認にも探索と判断のコストがある

明確な 5 候補から一つを選ぶ場合と、似たラベルの 30 候補から選ぶ場合では、同じ再認課題とは言いにくいほど探索と判断が変わります。

候補を見るとき、利用者は次を行います。

対象が候補内にあるか探す
ラベルや属性を読み、似たものを区別する
候補の出所と新しさを判断する
選択後の結果を予測する
プライバシー上表示してよい候補か判断する

候補が多い場合は、検索、カテゴリー、フィルター、並び替え、セクション、属性表示が必要かもしれません。これらは第13章の選択と探索へつながります。

再生を残した方がよい場合もあります。機密情報を候補に表示したくない、自由な新規入力を妨げたくない、熟練者のコマンド入力が速い、学習そのものが目的、といった条件です。再生と再認のどちらかを勝者にしません。

12.8 問い――この操作は、何を思い出させているか

会場選択の流れを観察します。

記憶要求台帳

時点	頭から生成するもの	画面の手がかり	識別するもの	判断	リスク
検索開始	会場名・綴り	なし	なし	検索語を決める	入力できない
候補表示	追加文字	名前候補	同名会場の住所	正しい対象か	誤選択
再訪	前回の会場	最近使った項目	最新／古いイベント	再利用してよいか	古い選択、プライバシー

問い

利用者は何を頭から生成しますか。
どの手がかりを画面へ置けますか。
候補から何を識別し、判断しますか。
手がかりの古さ、誤り、プライバシーには何がありますか。
再生を残す経路は必要ですか。
何を一つ変え、何を測りますか。

答えの例

利用者は会場の正式名称と綴りを生成しています。2 文字入力後に登録済み会場を 5 件示し、同名候補へ市区町村を加えると、検索語の入力エラーと検索時間が減る可能性があります。候補集合、順序、タスク、事前知識を固定し、候補なし／ありで完了、誤選択、時間を記録します。候補が古く誤選択が増えれば仮説は支持されません。

六問への回答では、次を一対一に確認します。

生成する文字列や概念と、必要になる時点が具体的か。
手がかりの出所、表示時点、取得方法が書かれているか。
対象と紛らわしい候補を区別する属性があるか。
鮮度、保存範囲、削除、共有端末、機微性を確認したか。
自由入力、ショートカット、新規作成など再生経路を残す理由があるか。
固定条件、変更する一軸、指標、副作用、仮説を支持しない結果があるか。

別の答え方

新しい会場を登録するタスクでは、既存候補が新規入力を妨げるかもしれません。「既存から選ぶ」と「新規作成」を分け、自由入力経路を残します。

よくある考え方

ドロップダウンにすれば覚えなくてよい。

注意点

候補集合、ラベル、順序、識別情報、キーボード、プライバシーが未定です。大量のドロップダウンは探索を増やす場合があります。

セルフチェック

頭から生成する情報と、候補から識別する情報を分けられる
手がかりの有無だけでなく、探索、誤選択、古さ、プライバシーを評価できる
再認を絶対的な正解にせず、再生を残す条件と反証方法を示せる

参考

Nielsen, “Recognition Rather Than Recall: Memory in User Interfaces” — 入口。ユーザビリティ経験則として読み、心理学の単一法則にしません。
Tulving & Thomson (1973), “Encoding specificity and retrieval processes,” DOI: 10.1037/h0020071 — 専門。手がかりと符号化文脈を扱います。
Gillund & Shiffrin (1984), “A Retrieval Model for Both Recognition and Recall,” DOI: 10.1037/0033-295X.91.1.1 — 専門。再生と再認の理論モデルです。
W3C WAI-ARIA APG, Combobox Pattern — 実装の入口。キーボード、フォーカス、ポップアップ、現在候補を確認します。
W3C WAI Forms Tutorial, Form Instructions — ラベル、説明、プレースホルダーを分ける公式資料です。
WAI-ARIA APG, Breadcrumb Pattern — 階層ナビゲーションの意味づけと aria-current を確認します。
NIST Privacy Framework 1.0 — 履歴や最近使った項目のプライバシーリスクを洗い出す入口です。法的助言の代替ではありません。
検索キーワード: free recall、cued recall、recognition memory、retrieval cue、recognition rather than recall、combobox、autocomplete、breadcrumb

第13章　人間は、選択肢が増えると判断に時間がかかる

3 択、30 択、300 択。数だけ見れば、後者ほど難しそうです。しかし、知っている操作を押す、目的の会場を探す、好みのプランを比べるのは異なるタスクです。

本章では、選択肢数、情報量、探索、分類、属性比較、選好形成を分けます。Hick–Hyman Law を「メニューを減らす法則」にせず、選択肢が多いことで選択を避けたり満足が下がったりする Choice Overload とも区別します。

この章の必修は三つです。

選択反応、既知項目の探索、好みの比較を分ける
個数を減らす前に、ラベル、分類、検索、比較可能性を見る
変更後に、時間だけでなくエラー、先延ばし、満足、副作用を確認する

本章では、タスクを分類し、現在の候補集合・ラベル・順序・手がかりを記録し、原因候補を一つ選び、一軸だけ変え、対応する結果と副作用を測る、という判断手順を使います。

13.1 3 択、30 択、300 択で何が変わるか

三つのボタンから指示された一つを押す課題、30 件から既知の会場を探す課題、300 のプランから好みを形成する課題を並べます。

3 択・30 択・300 択を示す図。 — 図 13-1　3 択・30 択・300 択

一つ目は刺激と反応の対応、二つ目は探索、三つ目は属性比較と選好形成を含みます。件数とタスクが同時に変わるため、三面の成績を「数の効果」として直接比較しません。

観察するときは、まず選択コスト台帳を作ります。

時点	タスク	候補集合	手がかり	判断	結果
操作選択	指示へ反応	3 操作	位置・ラベル	対応する操作	反応時間、エラー
会場探索	既知対象を探す	30 会場	検索、分類	対象一致	探索時間、誤選択
プラン比較	好みを作る	300 プラン	属性、並び替え、比較表	トレードオフ	選択、先延ばし、満足

13.2 Hick–Hyman Law がモデル化したもの

簡単に言えば、学習された複数の刺激―反応対応から一つを選ぶとき、不確実性が大きいほど反応時間が長くなる関係をモデル化します。

Hick–Hyman の式を示す図。 — 図 13-2　Hick–Hyman の式

等確率の n 択なら、情報量は log₂(n) bits と表せます。より一般には各選択肢の確率 pᵢ を使い、Entropy H = Σpᵢlog₂(1/pᵢ) を考えます。反応時間はしばしば RT = a + bH の形で表されます。

式の意味は「8 項目なら 3 秒」ではありません。a と b は課題、参加者、装置、刺激―反応の対応しやすさ、練習等に依存します。Hick と Hyman の実験は、意味を読みながらウェブサイトをナビゲーションする課題ではありません。

Hyman が確率を変えた点も重要です。よく現れる刺激を予測できる場合と、すべてが同確率の場合では情報量が違います。実際の UI でも、利用頻度、既有知識、位置の安定性は均等ではありません。

7±2 は Miller の記憶研究から広まった数字です。Hick–Hyman は選択反応時間です。ナビゲーションはラベルの意味を読み、情報構造を予測し、探索します。三つを一つの「7 個ルール」にしません。

12 項目でも、利用者の語彙に合う明確なラベルが同時に見えれば探せるかもしれません。6 項目でも「Solutions」「Resources」のような重なるラベルを階層間で覚えるなら迷います。

数を変える前に、次を見ます。

対象を事前に知っているか
ラベルから行き先を予測できるか
分類は互いに区別できるか
現在地と戻り道が残るか
検索できるか
頻用操作の位置が安定しているか

13.4 Choice Overload は同じ話ではない

Choice Overload は、選択肢が多い条件で選択しない、満足が下がる、後悔が増える等の結果を扱う研究領域です。選択反応時間のモデルとは同じではありません。

Choice Overloadを示す図。 — 図 13-4　Choice Overload

Iyengar と Lepper の研究は代表的ですが、そこから「6 択が正解」とは言えません。Scheibehenne らのメタ分析では平均効果はほぼゼロで、研究間の分散が大きいと報告されました。領域、選好の明確さ、属性の比較可能性、時間、推奨、結果が関わります。

反応時間、購入、先延ばし、満足、後悔を一つの「迷いスコア」にしません。何を改善したいかを先に決めます。

13.5 検索できる 100 件と、分類のない 30 件

同じ 100 件が一列に並ぶ画面と、同じ 100 件を名前で検索できる画面を比べます。A/B では検索の有無だけを変えます。さらに B/C で分類だけを加え、検索効果と分類効果を混ぜません。

ただし、検索は対象の語彙を生成できる人を助けます。名前を知らず、条件から探す人には分類やフィルターが必要です。誤字、別名、表記揺れ、検索結果なし、古いデータも確認します。

「100 件でも検索できるから問題ない」とも言えません。比較タスクでは、検索結果から一件ずつ開くより、属性を同時に並べる方がよい場合があります。

13.6 カテゴリー、絞り込み、並べ替えの役割分担

カテゴリー・絞り込み・並べ替えを示す図。 — 図 13-6　カテゴリー・絞り込み・並べ替え

カテゴリー: 情報空間を意味のある階層やまとまりとして辿る
フィルター: 条件に合わない候補を除き、集合を狭める
並び替え: 同じ集合の順序を変える

「東京」はカテゴリーにもフィルターにもなり得ます。重要なのは部品名ではなく、利用者のタスクに何をさせるかです。フィルター適用中の条件、結果件数、解除方法を見せます。並び替えは現在の基準と昇順／降順を示します。

カテゴリーを深くすれば、前の候補を覚えて往復するコストが増えます。複数カテゴリーに属する対象もあります。分類は世界の唯一の正解ではなく、タスクのための情報編集です。

13.7 Progressive Disclosure は隠せばよいのか

詳細設定を折りたたむと、最初の画面は短くなります。しかし、必要な操作部品が見つからない、複数セクションを比較できない、エラーが閉じた中に隠れる場合があります。

Progressive Disclosureを示す図。 — 図 13-7　Progressive Disclosure

全表示、折りたたみ、ステップ化のトレードオフを見ます。

発見できるか
全体像を把握できるか
前後を比較できるか
戻った後に状態が残るか
直接リンクできるか
エラー発生時に対象を開けるか
キーボードとスクリーンリーダーで状態が分かるか

隠す量ではなく、必要な時点と取得コストを設計します。

13.8 主要操作を一つにする条件

同じ画面に「購入」「資料請求」「相談」が同じ強さで並び、同じ利用者の次の一手を競うなら、優先順位が未定義かもしれません。一方、業務テーブルの各行に「承認」がある場合は、行ごとの並列操作です。

Primary Actionを示す図。 — 図 13-8　Primary Action

数ではなく範囲、結果、取り消しにくさ、タスクを確認します。主要スタイルを一つに減らしても、ラベルが曖昧なら迷いは残ります。複数操作を消すと、頻繁な業務が遅くなる場合もあります。

13.9 問い――減らすべきは選択肢か、迷いか

問い

これは選択反応、探索、比較、選好形成のどれですか。
候補数以外に何が違いますか。
カテゴリー、フィルター、並び替え、検索のどれがタスクを助けますか。
何を隠すと、何を思い出させますか。
結果は時間、エラー、選択、満足のどれですか。
一つだけ何を変え、どんな結果なら仮説を疑いますか。

答えの例

利用者は既知の会場を 30 件から探索しています。候補数だけでなく、ラベルの先頭が切り詰められ、検索がありません。全件を削る前に、完全な会場名を表示し検索を一つ追加すると、探索時間と誤選択が減る可能性があります。データ、対象、順序、タスクを固定します。時間が変わらない、または検索結果なしが増えるなら、語彙や分類の別仮説を検討します。

六問への回答では、タスク分類、候補数以外の観察、選んだ支援、隠した情報、結果、一軸変更と反証条件が一対一に書かれているか確認します。

この例では、1 は既知対象の探索、2 はラベル切り詰めと検索不在、3 は検索、4 は何も隠さない、5 は探索時間と誤選択、6 は完全ラベルだけを変え、改善しなければ語彙仮説を疑う、という対応です。

別の答え方

利用者が名前を知らず条件から探すなら、検索追加だけでは助かりません。地域と収容人数のフィルター、属性比較を優先します。

よくある考え方

選択肢を 7 個以下にします。

注意点

7 の根拠、タスク、ラベル、分類、結果がありません。減らした候補が別階層へ隠れ、往復を増やす可能性があります。

セルフチェック

選択反応、探索、比較、選好形成を分けられる
Hick–Hyman と Choice Overload を同じ法則にしていない
個数以外の一軸変更、結果、副作用、反証条件を書ける

参考

Hick (1952), DOI: 10.1080/17470215208416600 — 原典。選択反応課題とエラー条件を読みます。
Hyman (1953), DOI: 10.1037/h0056940 — 原典。確率と系列依存による情報量を確認します。
Proctor & Schneider (2018), DOI: 10.1080/17470218.2017.1322622 — 専門レビュー。対応しやすさと現代的説明への入口です。
Iyengar & Lepper (2000), DOI: 10.1037/0022-3514.79.6.995 — Choice Overload の代表研究。三つの研究の結果を分けます。
Scheibehenne et al. (2010), DOI: 10.1086/651235 — メタ分析。平均効果と異質性を確認します。

第14章　人間は、小さく遠いものを狙うのに時間がかかる

小さな閉じるアイコンを「見えるから押せる」と判断してはいけません。見た目の 16px、実際にポインターイベントを受け取る範囲、キーボードフォーカスの範囲は別です。さらにマウス、タッチ、キーボードでは操作が違います。

本章では Fitts’s Law を、ボタン寸法の正解ではなく、距離と進行方向の幾何学的な幅から、狙った移動を考えるモデルとして扱います。到達点の分布から推定する実効幅 Wₑ は、実測後の別指標です。

この章の必修は三つです。

見た目、操作領域、フォーカス範囲を分ける
距離、幅、入力方式、姿勢、隣接する対象を記録する
推奨数字の出自と例外を確認し、実機で行うタスクで確かめる

判断は、入力方式とタスクを決め、見える範囲／操作領域／フォーカス範囲の三範囲を測り、開始点・距離・進行方向の幾何学幅・隣接する対象を記録し、一軸だけ変え、運動時間とエラーを確認する順で行います。探索やアイコン理解にかかった時間は運動時間と分けます。

14.1 指先とマウスポインターの違い

マウスは画面上のポインターを間接的に動かします。タッチは指で直接触れ、接触点を指が覆います。キーボードは空間を狙わずフォーカス順を移動します。

同じボタンでも、机上のマウス、移動中の片手タッチ、キーボードでは問題が違います。ポインター移動時間、遮蔽、手の届き方、フォーカス順を一つのスコアにしません。

14.2 Fitts’s Law がモデル化した運動

簡単に言えば、対象が遠く、進行方向の幅が小さいほど、正確に到達する時間が長くなりやすい関係です。

HCI では MT = a + b log₂(D/W + 1) の形がよく使われます。D は開始点から対象までの距離、W は接近方向の幾何学的な幅です。観測された到達点の分布から求める実効幅 Wₑ は別の量で、CSS 幅と同一視しません。a と b は参加者、デバイス、タスク等から推定します。

Fitts の 1954 年研究は反復する狙った移動です。初めて見るアイコンの意味理解、対象発見、危険な操作の確認時間まで一式で予測する式ではありません。

14.3 小さな閉じるボタンを狙う

16px の×アイコンでも、上下左右に 14px の padding を加えれば 44px のボタン領域を作れます。この方法はレイアウトを変えます。図 F03-B ではレイアウトを固定するため、絶対配置した透明の重なりで操作領域だけを 44px へ広げ、padding 案は F05-A で別に扱います。

図 14-3　Close Button

ただし、透明な操作領域が隣の操作へ重なると、どちらがイベントを受けるか不明瞭になります。広げた範囲がカード全体のクリック、テキスト選択、スクロールと競合する場合もあります。

DevTools で getBoundingClientRect() を見ても、疑似要素、イベント委譲、重ねた透明領域、transform が関わることがあります。実際のイベント対象とフォーカス枠も確認します。

14.4 画面端と角が持つ特殊な幅

デスクトップ環境のポインターは画面端を越えないため、端に密着した対象は接近方向の許容範囲が境界により拡張されると説明されます。これは到達点から推定する Wₑ と同じ意味で「実効幅」と呼ばず、境界条件として記述します。

しかしウェブページの表示領域の端が、常に物理的な画面端とは限りません。ブラウザの外枠、ウィンドウ、スクロールバー、複数ディスプレイがあります。タッチでは指が端を越え、OS ジェスチャーやケース形状と競合します。「角は無限大」をすべてのデバイスへ適用しません。

14.5 `padding` と `min-width`／`min-height`

padding は内容の周囲を広げ、レイアウトにも影響します。min-width と min-height は最小の箱を確保します。疑似要素で透明領域を広げる案はレイアウトを変えませんが、重なり、重なり順、フォーカス枠、イベント対象を別に確認します。

小画面で対象を大きくすると、ツールバーが折り返し、内容を覆うかもしれません。対象サイズだけ合格させず、折り返し後のレイアウトと読む順序へ戻ります。

14.6 対象を大きくする以外の改善

頻繁に行う操作を作業対象へ近づける
隣接する危険な操作との間隔を広げる
キーボードショートカットを用意する
コンテキストメニューや行操作で移動を短くする
誤操作を取り消せるようにする
低頻度の操作を消すのではなく取得可能にする

距離を短くすると画面が重複操作だらけになる副作用もあります。ショートカットは発見可能性、取り消しは回復可能性を別に確認します。

14.7 推奨サイズの数字を絶対ルールにしない

WCAG 2.2 SC 2.5.8 は Level AA で 24×24 CSS px または間隔等の例外を定めます。Android 資料には 48dp という案内があります。これらは単位、目的、範囲、例外が違います。

24 CSS px は物理的な 24px とは限りません。dp、pt、CSS px を相互に数字だけ換算して唯一の安全値にしません。適合基準を満たすことと、特定利用状況で十分に操作できることも分けます。

14.8 問い――このアイコンは本当に押しにくいか

問い

見える範囲、操作領域、フォーカス範囲は何 px ですか。
開始位置からの距離と接近方向の幅はどこですか。
マウス、タッチ、キーボードで何が変わりますか。
隣接する対象、ジェスチャー、誤操作の重大さはどうですか。
大きくする以外に何を変えられますか。
どのタスクと指標で確かめますか。

答えの例

アイコン自体は 16px ですが、ボタンの操作領域は 44×44 CSS px です。見た目だけから「小さく押せない」とは言えません。一方、隣の削除ボタンまで 4px で、透明領域が重なっています。アイコンを拡大する前に重なりをなくし、同じタッチ操作のタスクで誤った隣接対象、完了時間、修正を記録します。

六問への回答では、三つの範囲、D と W、入力方式別のタスク、隣接リスク、選んだ一軸、運動時間／エラー／回復を対応させます。キーボードでは D と W を測らず、フォーカス移動回数、順序、表示、実行エラーを記録します。

別の答え方

キーボードでは操作領域よりフォーカス順とフォーカス表示が問題かもしれません。スクリーンリーダーでは、読み上げられる名前と対象の範囲を確認します。

よくある考え方

44px にすれば安全です。

注意点

単位、プラットフォーム、入力方式、間隔、例外、利用状況がありません。数字は確認の入口であり、人の行動の保証ではありません。

セルフチェック

見た目と操作領域を区別できる
Fitts’s Law の D、W、タスク条件を説明できる
ガイドラインの数字と実機タスクを別の根拠として扱える

参考

Fitts (1954), DOI: 10.1037/h0055392 — 原典。装置、反復タスク、速度―正確性のトレードオフを読みます。
MacKenzie (1992), DOI: 10.1207/s15327051hci0701_3 — HCI でのモデル、式、比較方法のレビューです。
WCAG 2.2 SC 2.5.8 Target Size (Minimum) — 公式基準。例外と CSS px を含めて読みます。
Android Accessibility Help, Touch target size — 48dp 案内の目的とプラットフォームを確認します。
Microsoft, Guidelines for targeting — タッチ対象、間隔、デバイス差の公式入口です。

第 II 部統合ケース　同じ操作を、異なる身体と環境で試す

第 10〜14 章では、注意、記憶、再生と再認、選択、狙った移動を分けて見ました。実際の操作では、それらが同時に起こります。本ケースではイベントを探し、プランを選び、申込み、エラーを直す同じ流れを、異なる利用状況で観察します。

目的は「どの入力方式が一番よいか」を決めることではありません。人、タスク、道具、物理環境、社会的環境の組合せによって、どこに不適合が生まれるかを記述します。

四つの利用状況

机上のノート PC とマウス。静かな室内、安定回線。
移動中の片手タッチ。眩しさ、振動、回線変動、時間圧。
ノート PC のキーボード。ポインターを使わず、フォーカス順とショートカットで操作。
スクリーンリーダーとキーボード。名前、役割、状態、読み順／フォーカス順から構造を得る。

これらは人物の能力を固定したペルソナではありません。同じ人でも時間、疲労、怪我、デバイス、場所によって条件が変わります。

四条件は入力方式だけを変えた因果比較ではありません。とくに片手タッチ条件は姿勢、振動、眩しさ、回線も異なる条件の束です。まず各条件内で問題を見つけます。入力方式だけの効果を比べる場合は、環境、タスク、デバイスを固定した別比較を作ります。

共通タスク

来週土曜、東京都内、車椅子席あり、残席 2 以上のイベントを探し、一般プランを 2 枚申込み、郵便番号エラーを修正して完了する。

データ、アカウント、開始状態、成功条件は共通です。入力方式に合わせて操作手順は変わります。マウスの移動時間とスクリーンリーダーの読み上げ時間を一つの速さで直接比較しません。

共通なのは目的と成功状態です。方式別タスクは、マウスなら対象をクリック、タッチならタップ、キーボードならフォーカス移動後に実行、スクリーンリーダーなら構造と名前を取得して実行することです。

四つの利用状況と共通 Taskを示す図。 — 図 II-1　四つの利用状況と共通 Task

観察台帳

段階	注意	保持・更新	再生／手がかり	選択	到達・操作	環境
イベント探索	更新・残席	日付、条件	会場名／フィルター	候補集合	検索、フォーカス	眩しさ、回線
プラン選択	価格・席種	枚数、合計	プラン説明	属性比較	行／ボタン	時間圧
入力	ラベル、規則	前の選択	例、オートコンプリート	候補確認	入力欄移動	姿勢、振動
エラー回復	要約、項目	修正済み状態	規則を再取得	修正操作	フォーカス／タッチ	フィードバック

「認知負荷が高い」「タッチは難しい」で終わらず、誰が何を保持し、どの手がかりを取得できず、どの対象で何が起きたかを書きます。

エラーを三つに分ける

起こりやすさ: 条件下でエラーが生じる可能性
重大さ: 起きた結果の損失や危険
回復可能性: 気づき、元へ戻し、正しく完了できるか

小さなボタンの押し損ねと、支払確定の誤操作を同じ一件として数えません。取り消しできる選択と、取り消せない送信も分けます。

分母も記録します。押し損ねは試行または操作機会、ナビゲーションエラーはタスク、回復成功は注入したエラー、通知欠落は期待した状態変化を分母にします。少人数の比率を母集団確率にしません。

エラーの起こりやすさ・重大さ・回復可能性を示す図。 — 図 II-2　エラーの起こりやすさ・重大さ・回復可能性

同じ画面を四つの経路で通る

マウスでは対象発見後のポインター移動、タッチでは遮蔽と隣接誤操作、キーボードではフォーカス順と表示、スクリーンリーダーでは名前、役割、状態、まとまり、フィードバックを記録します。

環境条件も補助記録へ残します。ビューポート、ズーム、文字サイズ、向き、入力装置、握り方、姿勢、照度の代理記録、騒音、振動、ネットワーク条件、時間制限、休憩、疲労の自己報告です。これらを人の恒常的な属性にしません。

改善案を一つずつ比べる

観察から、次の候補が出たとします。

フィルターの適用状態を結果見出しへ残す
プラン名と合計を入力画面へ残す
同名会場へ市区町村を加える
タッチ対象の重なりをなくす
エラー要約から該当入力欄へ移動できるようにする

一度に全部変えると、どれが何を助けたか分かりません。一つを選び、対象とする利用状況、タスク、指標、副作用、反証条件を書きます。その後で別の利用状況へ戻り、改善が新たな不適合を作っていないか確認します。

統合ループは、観察→複数の代替仮説→一軸介入→方式固有の指標→反証→別条件での副作用確認です。スクリーンリーダーでは、規格上の名前／役割／状態点検、特定ブラウザ／支援技術での動作確認、利用者のタスク観察を別の証拠として保存します。

問い

問題を個人の能力ではなく、どの組合せとして記述できますか。
四条件で、測れるものと直接比較できないものは何ですか。
エラーの起こりやすさ、重大さ、回復可能性はどう違いますか。
一つだけ変えるなら何ですか。
その変更は別の入力方式へどんな副作用を生みますか。
どんな結果なら仮説を疑いますか。

答えの例

移動中の片手タッチで、閉じる操作と削除操作の操作領域が重なり、振動時に削除が選ばれました。これは「利用者の指が不器用」ではなく、姿勢・振動・隣接対象・回復不能な操作の組合せです。重なりだけをなくし、同じデバイスとタスクで隣接誤操作を確認します。マウスでツールバーが広がり主作業を圧迫するなら、副作用として再設計します。

代替仮説には、対象の重なり、振動、ラベルの取り違え、危険操作の近接、回復手段の欠如があります。まず重なりだけをなくし、誤操作が残れば振動やラベルの仮説へ進みます。すべてを「タッチだから」でまとめません。

独習では一条件を選び、I02〜I05 の空欄記録へ観察だけを書き、代替仮説を二つ挙げ、I06 の一変更を選びます。人を観察しない場合は自分の結果を一般化せず、画面条件と状態の検査までを成果にします。

セルフチェック

人、タスク、道具、環境を分けて記録した
入力方式ごとに適切な観測変数を選んだ
エラーの頻度だけでなく重大さと回復を評価した
一軸変更を別の利用状況へ戻して確認した

第 III 部　人間は、勝手に予想する

初めて開く Web サイトでも、私たちは完全に白紙ではありません。左上のロゴ、下線のあるテキスト、虫眼鏡、歯車、カート、入力後のエラー。過去に使った別の画面から、「おそらくこう動く」という予測を持ち込みます。

予測は操作を速くします。毎回すべてを試さなくても、見た目、位置、言葉、反復から次の結果を見積もれるからです。一方、過去の経験と異なる結果が返ると、ためらい、誤操作、再学習が起こります。

第 III 部では、次を分けて見ます。

利用者がすでに持つ仕組みへの理解と予測
画面内の反復から学ぶ局所的な規則
操作後に返る状態とフィードバック
制作者が知りすぎているために見えなくなる問題

一貫性を守れば、すべてが使いやすくなるわけではありません。独自性を消すことも目的ではありません。慣習を借りれば学習を短縮できますが、対象利用者がその慣習を知らない場合があります。例外は重要な状態を知らせますが、例外だらけなら規則を学べません。

本部では、「直感的」「普通こうする」「一貫していない」という評価語を、経験、手がかり、予測、結果、学習へ分解します。そして、初回の成功、ためらい、誤操作、再試行、学習後の変化から仮説を確かめます。

第15章　人間は、知っている使い方を持ち込む

初めてのサイトでも、ロゴを押せばホームへ戻る、下線付きテキストはリンク、虫眼鏡は検索、カートには選択した商品が入る、と予測します。初体験の画面にも、過去の経験を持ち込みます。

本章では「直感的」を、利用経験、表示された手がかり、予測、初回操作、学習へ分解します。

この章の必修は三つです。

利用者が持ち込む予測と、その経験源を記録する
メンタルモデル、概念モデル、実装、システムイメージを分ける
慣習と独自性を価値、学習コスト、リスクで比較する

判断は、経験の根拠を記録し、予測群と自然行動群を別参加者へ割り付け、結果と予測の差を記録し、再試行と保持後の再訪で学習を確認する順で行います。別セッションでも初回接触は復元できません。

15.1 初めてのサイトも、完全な初体験ではない

ロゴ、リンク、検索、設定、カートの意味は、形だけから自然に分かるのではありません。別サイト、OS、アプリ、業務、言語、文化での経験が関わります。

観察前に「普通は分かる」と決めません。自然な初回行動を観察する群には、予測質問を先にしません。予測を尋ねる群は別参加者へ割り付けます。同じ人を別セッションにしても初回接触は戻らないためです。

15.2 メンタルモデルは頭の中の UI 図ではない

メンタルモデルは、システムがどう働き、操作の結果がどうなるかを理解・予測するための不完全な表象です。精密な内部実装を知る必要はなく、誤りや矛盾を含むこともあります。

概念モデル、実装システム、システムイメージ、メンタルモデルを示す図。 — 図 15-2　概念モデル、実装システム、システムイメージ、メンタルモデル

デザイナーの概念モデル: どんな概念と関係でシステムを説明するか
実装されたシステム: 内部状態、データ、処理、実際の振る舞い
システムイメージ: UI、ヘルプ、ラベル、フィードバック等を通じて利用者に提示される情報
利用者のメンタルモデル: 経験とシステムイメージから形成する理解と予測

画面を見ただけで「利用者のメンタルモデルはこうだ」と断定しません。予測、説明、操作、エラー後の修正から限定的に推論します。

15.3 慣習はどこから生まれるか

Convention の層を示す図。 — 図 15-3　Convention の層

慣習には層があります。

Web 全体で広く見られるリンクやナビゲーション
OS やデバイスのプラットフォーム慣習
EC、会計、医療等の領域慣習
組織内で学習された業務手順
アクセシビリティ API と標準操作部品の振る舞い

層は衝突します。Web では戻る操作が履歴を戻しても、業務の流れでは未保存データを失うかもしれません。モバイルのスワイプは、スクリーンリーダーのジェスチャーと競合する場合があります。対象利用者と文脈を特定します。

15.4 Jakob’s Law を「他サイトをまねる法則」にしない

Jakob’s Law は、利用者が多くの時間を他のサイトで過ごし、そこで形成した期待を持ち込むという UX 経験則です。

Jakob’s Law の射程を示す図。 — 図 15-4　Jakob’s Law の射程

これは学術的な自然法則でも、競合の見た目をコピーする許可でもありません。何が共有された期待かを調べる出発点です。対象者が初めてインターネットを使う、特殊な業務に熟達している、異なるプラットフォームを使う場合、期待は違います。

借りる候補は、外観そのものより、操作、結果、状態、キーボード、戻り方です。

15.5 独自 UI が要求する学習

独自の操作部品を使うには、少なくとも次の段階があります。

独自 UI の学習 Costを示す図。 — 図 15-5　独自 UI の学習 Cost

操作できるものを発見する
意味を推定する
操作方法を見つける
結果を予測する
結果から規則を更新する
次回まで覚える

一度説明すれば終わりではありません。説明を読む必要があるか、失敗が回復可能か、次回に保持されるかを観察します。

15.6 独自性を使う場所、慣習を借りる場所

ブランドの色、タイポグラフィ、画像、動き、語り口には独自性を持たせられます。購入、閉じる、戻る、エラー回復等の基礎操作を独自化すると、学習コストとリスクが高くなる場合があります。

価値はブランド識別、物語理解、製品固有機能の達成、コストは発見・意味推定・操作・保持に必要な試行、リスクは失敗頻度ではなく結果の重大さと回復可能性まで含めて記録します。

しかし境界は固定ではありません。新しい操作が製品価値そのもので、安全に試せ、フィードバックが明確なら学ぶ価値があるかもしれません。価値、頻度、失敗の重大さ、回復、対象者を表にします。

15.7 「直感的だった」をどう確かめるか

「説明なしでできた」だけでは不十分です。過去に同じパターンを使った可能性があります。

初回成功、最初の操作、ためらい、誤操作、ヘルプ、結果予測を記録します。次に再試行と学習後の速度を分けます。初回は失敗しても一度で学べる UI と、毎回迷う UI は違います。

F07 では初回、到達基準を満たすまでの練習、直後再試行、24 時間後の保持試行、同じ規則を別内容へ使う転移試行を分けます。到達は説明なしで 2 回連続成功と定義します。説明あり／なしを混ぜず、同じ参加者の初回を再生成しません。

ためらいは主観的なラベルにせず、一定時間操作がない、ポインターが往復する、フォーカスが戻る、候補を開閉する等、タスクごとに操作的に定義します。

15.8 問い――利用者は何を知っている前提か

問い

この操作は、どの過去経験を前提にしていますか。
利用者は操作後に何が起こると予測しますか。
画面は何を手がかりとして示していますか。
独自性の価値と失敗リスクは何ですか。
別の対象者なら前提はどう変わりますか。
初回、再試行、学習後に何を測りますか。

答えの例

ロゴがホームへのリンクであるという Web 経験を前提にしています。しかしこのロゴは押せず、ホームは独自ジェスチャーで開きます。利用者はロゴを押して変化がなく、ジェスチャーを発見できない可能性があります。ロゴを標準リンクにする案と、ジェスチャーを残して見える操作部品を加える案を比べ、初回操作、完了、ヘルプ、再試行を記録します。

六問への対応は、1 Web のロゴ経験、2 ホームへ戻る予測、3 ロゴとジェスチャーの手がかり、4 没入表現の価値とナビゲーション失敗リスク、5 展示経験やプラットフォームが異なる対象者、6 初回・到達基準・24 時間保持・転移です。別仮説として、ロゴのコントラスト、ページがすでにホームである可能性、読み込み遅延も残します。

別の答え方

展示用の没入型サイトでは、ロゴが常時ナビゲーションになると表現を損なうかもしれません。Escape、メニュー、ブラウザの戻る等の回復経路を残し、鑑賞者と鑑賞タスクで確認します。

よくある考え方

直感的ではないので普通の UI にします。

注意点

誰のどの経験、どの予測、どの失敗かがありません。普通という言葉で文化、プラットフォーム、領域の差を消しています。

セルフチェック

メンタルモデルを頭の中のスクリーンショットとして扱っていない
慣習の層と対象者の経験を説明できる
独自性の価値、学習コスト、リスク、初回／学習後の確認方法を示せる

参考

Norman (1983), “Some Observations on Mental Models” — 原典。メンタルモデルが不完全で変化する点を読みます。
Norman (1986), “Cognitive Engineering” — 概念モデル、システムイメージ、利用者の理解を考える入口です。
Staggers & Norcio (1993), DOI: 10.1006/imms.1993.1028 — HCI におけるメンタルモデル概念のレビューです。
ISO 9241-110:2020 — 利用者の期待への適合を文脈とともに読みます。
Nielsen Norman Group, Jakob’s Law — UX 経験則として読み、模倣の法則にしません。

第16章　人間は、同じ規則が続くと思う

同じ形の扉に同じ取っ手が続けば、次の扉も同じ方法で開くと予測します。Web でも、青い文字を何度か押して移動できれば、次の青い文字もリンクだと考えやすくなります。反復は、説明文がなくても画面の規則を示す手がかりになります。

ただし、違うものが一つあれば、必ず重要だとは限りません。状態を示す意図的な差かもしれず、別カテゴリーかもしれず、実装漏れかもしれません。本章では、反復から推測される規則と例外を観察し、例外を意図・状態・事故のどれかに早合点せず検討します。

この章の必修は三つです。

反復している属性と、そこから予測される規則を分けて記録する
視覚的顕著性、注意、記憶、理解、選択、行動を同じ効果にまとめない
例外の理由と意味を、見た目、実装、行動で確かめる

判断には共通の八段階を使います。反復の範囲と回数を記録し、予測した対応を書き、例外の物理差と出現条件を記録します。次に複数仮説を残し、データ、部品、状態、イベント、アクセシビリティ情報を監査します。何を改善し何を測るかを決め、一属性だけを変え、目的指標、副作用、反証条件を置きます。最後に通常／例外状態、入力方法、再訪時を確かめます。

本章では、視覚的顕著性を周囲との差、注意を処理資源が向いたこと、再認を以前見た項目だと判断すること、理解を意味や結果を説明できること、選択を候補を選ぶこと、と分けます。一つを測って他も証明したことにはしません。

16.1 反復から次を予想する

日常の系列から次を予想するを示す図。 — 図 16-1　日常の系列から次を予想する

駅の案内、棚のラベル、楽譜の拍、横断歩道の信号には反復があります。私たちは、色、形、間隔、位置、順序を手がかりに次を予測します。しかし、観察された反復と頭の中で推測した規則は同じではありません。

たとえば三つの案内板が同じ高さにあっても、「同じ高さは同じ階の情報」という規則なのか、「設置器具が共通」という事情なのかは、見ただけでは決まりません。まず「同じ高さが 3 回続く」と観察し、次に「同じ階を示す可能性がある」と解釈します。

16.2 UI の規則は、反復によって見える

UI では、タイポグラフィ、角丸、余白、色、アイコン表現、位置、挙動が反復します。同じ見出し階層に同じ文字スタイル、同じ操作に同じボタン、同じ区切りに同じ間隔が続くと、利用者は画面内の語彙と文法を推測できます。

ここで見るのはトークンの値だけではありません。「青なら操作できる」「右端なら行の操作」「太字なら現在地」のように、表現と役割の対応を見ます。同じ値でも役割が違えば規則ではなく偶然かもしれません。異なる値でも、状態差という上位の規則に従っている場合があります。

観察: 何が何回、どの文脈で同じか
推測された規則: その反復から次に何を予測するか
実装仕様: 部品、バリエーション、トークン、状態条件に何が定義されているか

三つを分けると、「一貫性がない」を調査可能な言葉へ変えられます。

16.3 一つだけ違うものが強く見える

孤立項効果と顕著性を分けるを示す図。 — 図 16-3　孤立項効果と顕著性を分ける

同質な項目群の中に異なる項目があると、その項目の記憶成績が変わる場合があります。この研究史に関連する言葉が**孤立項効果（Von Restorff effect）**です。

これは「一つだけ色を変えれば必ず最初に見られ、理解され、押される」という法則ではありません。視覚的に際立つこと、視線が向くこと、後で思い出すこと、意味を理解すること、選ぶことは別の現象です。課題、提示時間、項目間の関係、既有知識によって結果は変わります。

Web では、まず差を物理的に記録します。色相、明度、面積、位置、余白、動きのどれが違うのか。その後、注意、記憶、理解、選択のどれを問題にしているかを決めます。

16.4 CTA、Danger、Selected、Notification

例外に見える差には、優先行為、危険、状態、カテゴリー、実装事故など異なる理由があります。CTA、破壊的操作、選択中の項目、未読通知には差を設ける理由がありますが、四つは同じ「目立つボタン」ではありません。

CTA は、タスク内で優先する行為を示します。
危険表示は、結果の重大さと回復可能性を伝えます。
選択状態は、集合内の現在の選択状態を示します。
通知は、新しい出来事や未処理状態を知らせます。

色だけに意味を預けません。テキスト、アイコン、位置、形、ラベルを組み合わせ、実装上の状態も同期させます。現在地には文脈に応じて aria-current、選択可能なウィジェットの選択状態には対応する役割と aria-selected を使います。ネイティブ HTML で意味と振る舞いを満たせる場合は、それを優先します。見た目が違うことと、支援技術へ状態が伝わることは別々に点検します。

16.5 予測誤差が学習を更新する

青い文字をリンクだと予測して押したのに何も起きなければ、予測と結果に差が生じます。この差を手がかりに、利用者は「この青はリンクではない」「押せる範囲が文字ではなく行全体だ」など、規則を更新するかもしれません。

本章では予測誤差を、脳内機構の万能説明にしません。ここでは研究理論の実証ではなく、予測と結果の差を記録する本書の観察枠です。

操作前に何が起きると予測したか
実際に何が起きたか
直後にどこで止まり、戻り、別の操作をしたか
次の同型画面で行動が変わったか

予測を先に質問すると自然な初回行動を変える可能性があります。明示予測系列では、同じ参加者に予測を尋ね、その質問の影響を受けた初回と次試行を追います。自然行動系列では、別の参加者に事前質問をせず、初回と次試行を追います。この系列では事前予測を直接測っていません。二系列の結果をつないで一人の学習過程にしません。

16.6 例外は強いので節約する

主要、セール、新着、警告、選択中がすべて異なる強い色で並ぶと、どの差がどの意味か学びにくくなります。問題は単なる色数ではありません。差と意味の対応が競合しています。

また、通常状態の規則が十分に反復される前に例外を置くと、何から外れたのか分かりません。例外を減らすときは、数だけでなく、役割の重複、同時に見える範囲、出現頻度、失敗時の影響を調べます。「一画面に例外は一つ」のような固定数にはしません。

ここでいう「節約」は固定の予算ではなく、同時に見える差と意味の競合を調べる比喩です。F06-C も実証済みの正解ではなく、比較する設計案の一つです。

16.7 一貫性のために例外を消さない

意図、状態、別カテゴリー、事故を示す図。 — 図 16-7　意図、状態、別カテゴリー、事故

一貫性は、すべてを同じ見た目にすることではありません。同じ条件には同じ規則を適用し、条件が違うなら、その差を説明できることです。

危険な削除と安全な保存、選択中と未選択、エラーと通常、ブランド上の焦点は、同じにすると意味を失います。反対に、同じ部品の一つだけ角丸が違うなら、実装漏れかもしれません。例外を見つけたら、少なくとも四つの仮説を残します。

意図された強調
状態を示す差
別カテゴリーを示す差
設計または実装上の事故

16.8 問い――この違いには説明可能な理由があるか

問い

商品カードが 12 件並び、一つだけボタンの色、角丸、ラベルが違います。

何が反復し、何が違いますか。
反復からどんな規則を予測しますか。
意図、状態、別カテゴリー、事故を最低限の候補として、ほかにどんな仮説がありますか。複数が同時に成立しますか。
何を改善したいですか。そのために顕著性、注意、記憶、理解、選択、完了のどれを確かめますか。
DOM、部品、トークン、状態データの何を確認しますか。
利用者の行動でどう確かめますか。

答えの例

11 件では「青、角丸 8px、『カートに入れる』」が反復し、一件だけ「赤、角丸 16px、『今すぐ購入』」です。私は、商品カードの末尾は同じボタンで同じ操作を提供するという規則を予測しました。しかし差は期間限定 CTA という意図、在庫警告という状態、予約商品という別カテゴリー、旧部品の残存という事故のどれでも説明できます。

まず商品種別と在庫状態を確認し、部品名、バリエーション、トークン、イベントを比較します。権限、地域要件、実験条件、移行途中という仮説も残し、各仮説を支持／反証するデータを書きます。強調意図なら、何を増やしたいのかを購入完了率のように定め、誤購入率、取消率、他商品発見率を各対象機会数で割って併記します。視線が向いたことだけを成功にしません。

別の答え方

予約商品なら通常商品と操作の結果が異なるため、差には理由があります。ただし色と角丸とラベルを同時に変えると、どの差が何を伝えるか分かりにくいかもしれません。カテゴリーラベルを加え、ボタンの基本文法は共有する案も比較できます。

よくある考え方

Von Restorff effect で赤いボタンが目立つので、売上が上がります。

注意点

孤立項の記憶研究から、注意、意味理解、クリック、購入を直接予測しています。目的指標と副作用を定め、実際の行動で確かめる必要があります。

さらに二つの答えの例

リンクと補助テキストが同じ青: 反復は青いテキスト 8 件、例外は操作できない補助テキスト 2 件です。「青はリンク」を予測します。ブランド色の共有、実装漏れ、無効状態、下線による別規則を仮説にし、DOM 要素、フォーカス可能性、下線、ポインター／キーボード操作を監査します。18 歳以上の Web 利用者を対象とするリンク探索タスクで、まず補助テキストの色だけを変えます。最初に正しいリンクを選んだ人数／タスク開始人数と、補助テキストへの誤操作数／操作機会数を記録します。下線の有無だけで発見差を説明できれば、青の共有が主要因という仮説は弱まります。

選択と通知が同じバッジ: 六つのタブ中、選択中の一件と未読の二件が同じ丸印です。「丸印は選択中」を予測します。共通の注意喚起、状態設計の衝突、旧部品、未読と選択の同時成立を仮説にします。選択は tab の aria-selected とタブパネル、未読は状態データと読了条件を監査します。まず未読バッジへ「未読 3 件」というテキストだけを加えます。対象タブを説明できた人数／質問人数、未読タブを説明できた人数／質問人数、誤選択数を別に記録します。テキスト追加後も二タスクの差がなければ、丸印の競合が主要因という仮説は弱まります。

答えを比べる評価観点

三つの回答例を同じ八項目で照合します。観察と推測を分けたか、反復の範囲と回数を書いたか、最低二つの仮説を残したか、各仮説の支持／反証データを示したか、実装と意味論を監査したか、一属性だけを変えたか、目的指標・分母・副作用を示したか、反証条件と別条件での再確認を示したか、です。すべて埋めることが正解ではなく、未測定と判断不能を明示することも評価します。

一人で確かめる／人を見て確かめる

一人なら、紙上で観察・解釈・評価を別色にし、DevTools でデータ属性、部品名、バリエーション、トークン、イベント、アクセシビリティツリーを追います。実装へ触れられなければ、通常／ホバー／フォーカス／選択／エラーの画面比較から限定的な仮説だけを作ります。

人を観察する場合は、明示予測系列か自然行動系列の一方を選びます。同意を得て個人情報を匿名化し、いつでも中止できるようにします。一人の結果を一般化せず、質問による誘導と観察できなかった事実も記録します。

セルフチェック

観察された反復と、推測した規則を分けて記述できる
孤立項効果を「目立たせる法則」として使っていない
例外について複数仮説を残し、見た目・実装・行動の確認方法を示せる
一属性だけの変更、目的指標、副作用、反証条件を示せる

参考

von Restorff (1933), Über die Wirkung von Bereichsbildungen im Spurenfeld — 孤立項研究の原典です。独語で難度は高く、研究条件の確認に使います。
Hunt (1995), “The subtlety of distinctiveness: What von Restorff really did” — 原研究が単純な「目立つものは覚える」という話ではないことを整理したレビューです。
ISO 9241-110:2020 — 利用者の期待への適合を、利用文脈とともに読む規格です。
WAI-ARIA 1.2 — aria-current、aria-selected 等の状態と適用される役割を確認する規範的仕様です。
WCAG 2.2, 1.4.1 / 4.1.2 — 色だけに依存しないこと、名前・役割・値を伝えることを確認します。

第17章　人間は、自分の行動に反応を期待する

照明のスイッチを押しても光らなければ、押せていないのか、故障か、遅れているのかを判断できません。Web でも、ボタンを押した後に変化がなければ、利用者はもう一度押し、戻り、諦めるかもしれません。

本章ではフィードバックを、押した瞬間のアニメーションだけでなく、受付、処理中、成功、失敗、回復まで続く状態の情報として見ます。

この章の必修は三つです。

操作前から完了後までの状態と遷移を列挙する
見える状態、操作可能性、支援技術へ伝わる状態を同期する
遅延、失敗、取消、再試行を含む条件で確かめる

判断には八段階を使います。利用者の行為と期待結果を決め、クライアント、通信、サーバー、永続化、別クライアントの状態を列挙します。受付、処理中、確定、失敗、取消、結果不明、回復の遷移を書き、各状態の見える情報、操作可能性、支援技術へ伝わる状態、通知を対応させます。次に重複、順序逆転、再読込、別タブを注入し、複数原因を残します。UI 表示、操作制御、サーバー処理を一軸ずつ変え、完了、重複、データ損失、回復、状態理解、副作用を確かめます。

状態は一列の排他的なラベルではありません。ホバー／フォーカス／アクティブという入力状態、有効／無効という操作可能性、編集中／処理中という処理状態、成功／エラー／不明という結果状態は同時に成立し得ます。

17.1 Switch を押したのに何も起きない

日常の Switch と結果を示す図。 — 図 17-1　日常の Switch と結果

行為の直後に必要なのは派手な動きではなく、入力が受け取られたか、何が変わったかを知る手がかりです。音、抵抗、光、位置、テキスト、振動など複数の経路があります。

「反応がない」を観察語へ変えます。押した瞬間の見た目が変わらない、フォーカスが見えない、送信後もボタンが操作可能、処理中のテキストがない、成功後もデータが変わらない、というように時点と属性を記録します。

17.2 フィードバックとアニメーションは同じではない

Feedback の目的と手段を示す図。 — 図 17-2　Feedback の目的と手段

アニメーションは変化を時間的につなぐ手段です。フィードバックは、行為を受け取ったこと、処理、結果、次の可能な操作を知らせる役割です。色、テキスト、アイコン、音、振動、フォーカス移動、内容更新でもフィードバックを作れます。

アニメーションがあっても、何を処理し、成功したか分からなければ十分ではありません。アニメーションを止めても意味が伝わるか、prefers-reduced-motion で動きを減らしたときに状態が残るかを確認します。

17.3 ボタンを押す前から完了後まで

通常、ホバー、フォーカス、アクティブは入力との関係を示します。無効、ローディング、成功、エラーはドメイン条件や処理結果とも関係します。同じ平面のスタイル見本として並べるだけでは、どこからどこへ移るかが分かりません。

状態表には、開始条件、利用可能な操作、DOM 属性、見える表現、通知、終了条件、失敗時の遷移を書きます。ホバーがないタッチ、ポインターを使わないキーボード、音声出力も含めます。

17.4 通信遅延の間に何が起きるか

送信と結果の間が延び、画面が変わらないと、利用者が二つの出来事を結び付けにくくなったり、再操作したりする可能性があります。ただし、知覚された因果、再押下、重複リクエスト、重複した業務処理は別の仮説と結果です。遅延だけから順に起きるとは断定しません。

単にボタンを無効にすれば解決とは限りません。何を待っているか、取消せるか、入力データは保たれるか、再試行は同じ処理を重複させないかを設計します。注文や決済では、クライアント側のボタン制御だけでなく、サーバー側の冪等性や処理 ID も必要です。

通信を高速なまま確認せず、遅延、オフライン、タイムアウト、応答順序の逆転、サーバー成功後に応答だけ失われる条件を試します。

応答が失われた場合、クライアントからは成功か失敗か分からない結果不明になります。再試行で新しい処理を始めるのか、同じ処理 ID を再照会するのかを分けます。検索の再実行と決済の再実行では影響が違います。

17.5 ローディング表示は何を伝えるか

図 17-5　Spinner と Progress の情報差

ローディング表示には、少なくとも開始、継続中、進行量、残り見込み、取消可能性があります。スピナーは処理中を示せても、何割終わったかは示しません。全体量と完了量を測れるなら進捗を示せますが、架空の 99%を長く見せると予測を壊します。

スケルトン UI は内容の概形を先に示す手段です。処理完了の保証ではなく、レイアウトシフトを抑える設計とも関係します。実際の内容と異なる骨格、終わらない反復、複数領域の別々の待機に注意します。

F05 は同じタスクの因果比較ではなく、アップロードとページ読込という異なる待機タスクに応じた手段の分類です。アップロード内でスピナーと実測進捗を比べる系列と、ページ読込で全体スピナーと領域別スケルトンを比べる系列を接続して効果を推定しません。

17.6 Optimistic UI の期待と回復

Optimistic UI は、サーバーの成功確定前に手元の表示を成功状態へ進める方式です。即座に見えても、成功した事実を早く作る技法ではありません。

失敗したら、元へ戻す、再試行を促す、未同期として残す、利用者に選ばせる等の回復が必要です。金銭、在庫、権限、共同編集の競合など、誤った成功表示の影響が大きい操作には慎重さが要ります。

操作 ID、手元の仮状態、サーバー版、更新番号を対応させます。古い失敗応答で新しい成功を巻き戻さず、直後の別操作、再読込、別タブ、オフライン時の待ち行列、権限変更と整合させます。巻き戻し、未同期保持、再試行の選択は、業務上のリスク、回復可能性、競合解決方法で決めます。

比較するときは、成功率だけでなく、失敗が発覚するまでの時間、データ損失、重複、回復完了、利用者が状態を正しく説明できるかを見ます。

17.7 見える状態と支援技術へ伝わる状態

視覚・DOM・読み上げの同期を示す図。 — 図 17-7　視覚・DOM・読み上げの同期

色やスピナーが変わっても、支援技術へ状態が伝わるとは限りません。WCAG 2.2 の Status Messages は、フォーカスを移さずに提示される操作結果、待機、進行、エラー等が、役割やプロパティを通じて判定できることを求めます。

すべての更新を alert にすると割込みが増えます。通常の結果には文脈に応じて status や output、緊急で時間的に重要な情報には alert を検討します。更新先のコンテナは更新前から存在させる必要がある場合があり、ブラウザ／OS／スクリーンリーダーの組合せで確認します。

ネイティブの disabled はフォーカスや送信にも影響します。無効理由を知る経路が失われないかを確認します。見た目、操作可能性、DOM 状態、アクセシビリティツリー、読み上げを別々に監査します。

17.8 状態表を作り、欠けを探す

画面のスクリーンショット一枚では、待機や失敗を見落とします。商品登録フォームを例に、状態表を作ります。

状態	きっかけ	見える表示	操作	支援技術へ伝わる状態	次
編集中	入力	入力値	編集・送信	value	送信中
送信中	送信	「保存中」	取消の可否	`aria-busy` 等を文脈で検討	成功／失敗
成功	2xx＋整合確認	「保存しました」	次へ	status message	編集中
入力エラー	入力検証	対象と直し方	修正	native validity／関連付け	編集中
未送信	オフライン等でリクエスト未到達	「送信できませんでした」	編集・再送	request state	送信中／編集中
失敗確定	サーバー拒否	「保存できませんでした」	修正・再試行	operation failed	送信中／編集中
応答タイムアウト	所定時間に応答なし	「結果を確認しています」	再照会	request timed out	結果不明
取消要求中	Cancel	「取消中」	二重取消を防ぐ	operation ID	取消確定／結果不明
結果不明	応答消失	「結果を確認中」	再照会	同じ操作 ID	成功／失敗／サポート
部分成功	複数処理の一部完了	完了と未完了	未完了だけ再試行	item 別 state	完了／結果不明
古い応答・競合	応答逆転／別クライアント更新	現在版と競合	再読込・選択	バージョン	編集中／解決済み

問い

操作前、受付直後、処理中、成功、失敗、回復に何がありますか。
各状態へ入る Trigger と出る条件は何ですか。
利用者は今何が起き、次に何ができると判断できますか。
ポインター、キーボード、タッチ、スクリーンリーダーで情報は一致しますか。
遅延、オフライン、二重送信、応答逆転で何が起きますか。
何を観察し、どの仮説を反証しますか。

答えの例

送信直後もラベルが「保存」のままでボタンを何度でも押せます。受付状態が見えず、二重送信の可能性があります。ただし原因はフィードバック不足だけでなく、クリック処理の未接続、通信開始前のメインスレッド停止、支援技術だけに通知がある場合もあります。

まずイベント、リクエスト ID、ボタン状態、DOM、アクセシビリティツリー、サーバーログを同じ時刻軸で確認します。ボタン文言だけを「保存中」へ変える案、重複操作をサーバーで同一処理へ束ねる案を別々に試します。タスク開始数を分母に二重送信率、完了率、回復率を記録し、キーボードと遅延条件でも確かめます。

別の答え方

処理が手元で瞬時なら、ローディングを挟むことでかえってちらつくかもしれません。結果データが即時に変わり、その変化を理解できるなら、別のフィードバックがすでに成立している可能性があります。

よくある考え方

スピナーを付ければ分かりやすくなります。

注意点

受付、進行、完了、失敗、回復のどれをスピナーが伝えるのかがありません。動きは意味、操作制御、重複防止、支援技術への通知を自動では満たしません。

さらに二つの答えの例

注文の応答が失われた: 画面はタイムアウトですが、サーバーには注文があるかもしれません。通信失敗、処理失敗、応答だけの消失、古い画面を仮説にし、処理 ID でサーバー状態を再照会します。「もう一度注文」を「注文状況を確認」へ変える比較と、サーバーの冪等性だけを変える試験は分けます。注入した応答消失件数を分母に結果確認率、重複業務処理率、回復完了率を記録します。サーバーが一件も受け付けていなければ応答消失仮説は反証されます。

別解: 検索のように再実行の影響が小さいタスクなら、新しい処理として再試行する方が早い場合があります。
よくある考え方: Timeout なら失敗なので、同じ注文をもう一度送ります。
注意点: リクエストのタイムアウトは、所定時間に応答がなかったという通信上の観察で、業務処理の失敗確定ではありません。再照会と新規再試行を分けます。

お気に入りの仮更新が失敗した: 手元では選択済み、サーバーでは未選択、別タブは古い状態です。拒否、古い応答、バージョン競合、オフライン時の待ち行列を仮説にします。操作 ID、クライアント版、サーバー版、タブ間同期を監査し、まず未同期ラベルだけを加えます。注入した拒否数を分母に状態説明正答、回復、直後の別操作が失われた件数を測ります。再読込後も全クライアントが同じ確定版を示せば不整合仮説は弱まります。

別解: 失敗をすぐ巻き戻さず未同期として残し、接続回復後に再送する方が意図を保てる場合があります。
よくある考え方: 失敗したら必ず元へ戻せば安全です。
注意点: 元へ戻す処理が、その後の別操作や新しいサーバー版を上書きすることがあります。処理の版を比較します。

見える成功が読み上げられない: 保存済みテキストは見えますが、アクセシビリティツリーにステータスがありません。更新コンテナの役割不足、更新時点、支援技術の組合せ、通知過多を仮説にします。まず適切なステータスの意味だけを加え、対象環境ごとに通知検出数／状態更新数とタスク中の理解を別に記録します。役割がツリーへ出ても通知されなければ、仕様適合だけで告知成功を証明できません。

別解: エラー修正のために操作を求める場合は、ステータス通知だけでなくエラー概要やフォーカス設計が必要かもしれません。
よくある考え方: role="status" を付ければ全員に必ず伝わります。
注意点: 仕様上の役割、特定環境での通知、利用者の検出と理解は別の証拠です。

共通 Rubric

各回答で、状態所有者、受付から回復までの遷移、最低二つの原因、クライアント／サーバー監査、一軸変更、分母付き指標、副作用、反証条件を確認します。未測定は空欄にし、推測で埋めません。

セルフチェック

操作前から回復までの状態と遷移を列挙できる
フィードバックとアニメーション、視覚状態とプログラム上の状態を分けられる
遅延・失敗・入力方法を変え、分母付き指標と反証条件を示せる
結果不明、取消、競合、古い応答から安全に回復する経路を示せる

参考

ISO 9241-110:2020 — Self-descriptiveness を、状態と利用 Context から読みます。
WCAG 2.2, SC 4.1.3 Status Messages — フォーカスを移さない状態更新の要件です。
WAI-ARIA 1.2 — status、alert、aria-busy の規範的定義です。
ARIA Authoring Practices Guide, Alert pattern — Informative な実装例であり、規格そのものではありません。
HTML Living Standard — button、disabled、output、progress を確認します。

第18章　人間は、自分が知っていることを忘れられない

答えを知った後に問題文を読むと、手がかりが最初から目立っていたように見えます。画面を作った人には、ボタンの意味、次のページ、業務用語、例外条件がすでに分かっています。その知識を一時的に持たない状態へ戻ることはできません。

前者は、結果を知った後に事前の予測可能性を高く見積もる後知恵バイアスに関係します。後者の、知識を持つ人が知識のない他者を予測する難しさが知識の呪いです。関係し得ますが、同じ概念ではありません。制作中の反復接触や馴化とも分けます。

本章では「作者は慣れている」を、後知恵バイアス、知識の呪い、確証バイアス、馴化、専門家の盲点へ安易にまとめません。作者の知識、反復接触、検証仮説、初見者の経験を別々に記録します。

この章の必修は三つです。

画面が前提とする知識を列挙する
作者の意図、自己評価、利用者の発言と行動を別の根拠にする
一人の観察から複数仮説を作り、対象者とタスクを変えて確かめる

判断には八段階を使います。対象者、タスク、状態、利用状況を定め、作者が知る用語・業務・遷移・例外・回復を列挙します。画面がいつ何を提示するか対応させ、欠けた前提と対象者が既に持つ知識を分けます。自然行動、発言、実装、作者の意図を別に記録し、停止や誤操作へ複数仮説を作ります。認知概念は診断名でなく候補にし、一つの手がかりだけを変え、対象範囲、反証、副作用を確認します。

18.1 答えを知った後では、問題文が簡単に見える

謎解きの答えを見た後、同じ手がかりが明白に感じられることがあります。これは後知恵バイアスに関係する例で、知識の呪いそのものではありません。答えを見る前の自分の判断を内観だけで復元できません。

知識の呪いは、自分が持つ知識を差し引いて、知識の少ない相手の判断を予測する難しさを考える概念です。Camerer らの研究は経済予測の実験であり、「専門家は必ず初心者を理解できない」という人格診断ではありません。Web では、前提知識の候補を見つける仮説として使います。

18.2 作者には見えて、初見者には見えない前提

前提は一種類ではありません。

「SAML」「SKU」等の用語知識
ロゴやアイコン、ジェスチャー等の操作慣習
前ページで入力したデータ
申請、承認、請求等の業務手順
権限、契約、地域による条件
エラー時の回復方法
支援技術や入力方式で異なる操作

作者は設計資料、実装、会議、過去版から知っています。利用者には画面を通じて何が提示されるかを分けます。「説明した」ではなく、どの時点で、どの表現から、何を知れるかを記録します。

18.3 知識の呪い、確証バイアス、馴化を分ける

似た失敗にも異なる説明があります。

知識の呪い: 作者の知識を持たない人の判断を見積もる問題
後知恵バイアス: 結果を知った後に事前の予測可能性を再構成する問題
確証バイアス: 「この導線で分かる」という仮説に合う根拠へ偏る問題
馴化: 反復刺激に対する反応低下
専門家の盲点: 初学者の学習に必要な中間段階を見積もる問題

画面を見て「作者は確証バイアスに陥った」と診断しません。レビュー記録に反対根拠を探していない、同じ通知への反応が反復で低下した、といった観察と手順が必要です。

馴化は、単に見慣れた、飽きた、注意不足という日常語ではありません。反復刺激による反応低下で、感覚順応や疲労とは区別されます。作者が同じ画面を 100 回見た事実だけでは証明できません。

18.4 「私は迷わない」が証拠にならない理由

作者と初見者の Evidence 差を示す図。 — 図 18-4　作者と初見者の Evidence 差

作者は正しい操作、画面遷移、データの意味を知り、何度も成功しています。「私は迷わない」は、その知識を持つ作者がタスクを完了できる根拠です。初見者も迷わない根拠ではありません。

逆に「初見者は絶対に迷う」とも決めません。領域に熟達した利用者なら、作者より早く意味を推測するかもしれません。誰が、何を知り、どのタスクで、どの状態を見たかを揃えます。

18.5 翌日見る、別表現にする、説明なしで見せる

翌日に見る、印刷する、読み上げる、順序を変える、テキストだけにする、説明なしで同僚へ見せると、新しい違和感を発見できることがあります。

しかし翌日の作者も、意味と正解を知っています。時間を置く方法は反復接触の直後効果を弱める可能性はあっても、初見を復元しません。別表現も新しい観察手段であり、利用者行動の代替ではありません。

一人でできる方法では、まず前提知識一覧を隠し、画面から得られる手がかりだけを別欄に写します。次に不足を仮説として残します。

18.6 他人の行動から前提の穴を見つける

説明せずにタスクを依頼し、停止、戻る、誤操作、読み飛ばし、ヘルプ、質問、完了を記録します。「分かりました」という発言と、その後の行動は別欄にします。

停止は知識不足とは限りません。読んでいる、考えている、別の通知に気を取られた、運動操作が難しい可能性もあります。観察から直ちに認知概念へ飛ばず、画面の手がかり、経験、タスク文、デバイス、状態という別仮説を残します。

作者の意図は説明せず、終了後に利用者が何を予測していたかを尋ねます。質問によって初回行動を変えないため、自然行動の後に聞きます。

18.7 初心者一人を「ユーザー」にしない

一人の観察でも、未知の停止や前提を発見できます。しかし「一人が迷ったから全員が迷う」「初心者ができたから問題ない」と一般化できません。

年齢や職種だけで分類せず、領域経験、同種 UI 経験、言語、デバイス、支援技術、直前のタスクを記録します。対象者、タスク、文脈の範囲を明示し、反復して観察します。少人数では頻度推定より、問題候補と仕組みの仮説を得ることを重視します。

観察には同意、匿名化、途中中止、データ保存期間を定めます。参加者を「テスト対象」ではなく、設計仮説を確かめる協力者として扱います。

同僚や部下へ依頼すると、断りにくさや評価への不安が生じます。参加しなくても不利益がないこと、録画範囲、閲覧者、保存期間、削除方法を事前に伝えます。安全、法令、業務上必須の情報は隠しません。「説明しない」は自然な初回行動を観察する範囲だけに限定し、危険があれば中止します。オンボーディングの効果を調べる場合は、説明ありの別条件として評価します。

18.8 問い――この画面は何を知っている人向けか

問い

権限申請画面に「SCIM 対象外はオーナー承認後に IdP 側でプロビジョニングしてください」とあります。

どの用語、業務、操作、状態の知識を前提にしていますか。
その知識は画面のどこから得られますか。
作者が知っていることと、対象者が持つ可能性のある知識は何ですか。
五概念のどれが仮説候補ですか。各概念に必要な根拠のうち、何が未観察ですか。
停止や誤操作にはどんな別仮説がありますか。
一人で何を監査し、誰のどんな行動で確かめますか。

答えの例

SCIM、オーナー、IdP、プロビジョニングという用語と、承認後に別システムへ移る業務順序を前提にしています。画面には用語説明、移動先リンク、現在の承認状態がありません。作者は社内手順と次のシステムを知っていますが、初回申請者は知っているとは限りません。

知識の呪いは候補ですが、画面だけから作者の認知状態を診断できません。用語を説明済みだという設計仮説に合う成功例だけを見ているなら確証バイアスの検討対象になります。停止には文章の長さ、権限不足、リンクの視認性、処理待ちも考えられます。

まず用語、業務順序、状態、移動先の各前提と、画面上の手がかりを対応させます。用語説明だけを加える案と、次の操作を加える案を分けます。初回申請者と管理経験者を別群として、最初の操作、停止、誤遷移、完了、次の状態説明を記録します。

別の答え方

対象が Identity 管理者だけなら専門用語は共有されている可能性があります。初学者向けへ全て言い換えると、精度と作業速度を損なうかもしれません。対象者を広げるのか、用語集を参照可能にするのかを文脈で決めます。

よくある考え方

専門用語が多いので、知識の呪いです。

注意点

用語が多いという画面上の観察から、作者の認知状態を診断しています。対象者が用語を知る可能性、別の阻害要因、実際の行動を確認していません。

さらに三つの答えの例

空状態の次操作を作者だけが知る: 画面は「まだプロジェクトがありません」とだけ示し、作成ボタンはヘッダーの ＋ です。作者は社内慣習を知ります。初見者の停止には前提不足、アイコン識別、権限不足、ボタンがビューポート外という仮説があります。＋ へ「プロジェクトを作成」というラベルだけを加え、作成権限のある初見者の正しい初回操作数／タスク開始数と誤操作を記録します。ラベル追加後もボタンへ到達しなければ、意味だけが主要因という仮説は弱まります。別解として熟達者向けの高密度画面では短いアイコンを維持し、空状態内にも同じ操作を置けます。よくある考え方は「翌日見れば初見に戻れる」です。作者は次操作の知識を保持するため、初見根拠にはなりません。

作者が通知の見落としを馴化と呼ぶ: 初見参加者が一回目の通知を読まず、作者は「見慣れて無視した」と説明しました。しかし初回なので反復刺激への反応低下は観察されていません。コントラスト、出現位置、タスク中の注意、スクリーンリーダー通知、文章理解を仮説にします。位置を固定して通知テキストの見出しだけを変え、通知検出数／提示機会数と内容説明を分けます。反復提示で同じ刺激への反応が段階的に低下し、新刺激へ反応が戻る等の手順がなければ馴化を主張しません。よくある考え方は「一人が見落としたので文言を簡単にする」です。原因未特定のまま介入しています。

見出しだけの変更は通知の発見・理解を検討する一軸比較であり、馴化の検証ではありません。馴化を検討するなら同じ刺激の反復、反応指標、刺激特異性、時間後の回復を別手順で観察します。

業務熟達者だが UI 慣習に不慣れ: 承認業務は理解していますが、横スワイプで操作を出すモバイル UI で停止しました。業務知識不足ではなく、ジェスチャー経験、可視手がかり、支援技術との競合、運動条件が候補です。見えるボタンだけを追加し、同じ業務経験層で操作発見、完了、誤操作を記録します。別解として頻繁に使う熟達者にはジェスチャーとボタンを併存させられます。「専門家なら全員分かる」は領域経験と UI 経験を混同しています。

一人で使う前提台帳

作者が知ること	画面の手がかり	対象者の既有知識仮説	未提示	確認方法
次のシステム	承認後テキストのみ	管理者は知るかもしれない	リンク	初回操作とタスク後質問

紙上監査、翌日の自己レビュー、他者の自然行動、行動後質問、説明ありオンボーディングを別の根拠として記録します。

共通評価観点

主回答と追加三題を、前提と手がかり、対象者経験、観察と推論、最低二仮説、追加根拠、一軸介入、分母、副作用、反証条件の九項目で照合します。独学で一人を観察するときは、頻度や認知機構の実証ではなく、問題候補と次の仮説を得る範囲に限定します。

セルフチェック

前提知識と画面から得られる手がかりを対応させられる
五概念を分け、画面だけから作者を診断していない
一人の観察の価値と一般化の限界を説明できる
一属性の介入、分母、副作用、反証条件を示せる

参考

Camerer, Loewenstein & Weber (1989) — 知識の呪いを経済実験の文脈で読む原典です。
Fischhoff (1975) — 結果知識が事前判断の見積りへ与える影響を扱う古典です。
Nickerson (1998) — 確証バイアスという現象群を整理したレビューです。
Rankin et al. (2009) — 馴化の定義と行動的特徴を更新した無料のレビューです。
Nathan & Petrosino (2003) — 教員養成 Context の専門家の盲点研究です。

第 III 部統合ケース　規則を学び、例外に出会い、回復する

第 15〜18 章では、過去経験からの予測、反復が作る規則、行為へのフィードバック、作者と利用者の知識差を見ました。実際の Web 利用では、それらが時間の中で重なります。

本ケースでは、架空の権限申請サービス「Michi Access」を初めて使い、申請を繰り返し、例外に出会い、通信障害から回復し、翌日に再訪する流れを追います。

目的は、利用者の頭の中を物語として決めることではありません。各時点の画面、操作、状態、発言、実装を分け、どの概念が説明候補になり、何がまだ未観察かを記録します。

到達目標は、一つの時刻付き観察から第 15〜18 章を横断する複数仮説を作り、追加根拠、実装監査、一軸介入、反証、別段階への副作用まで追跡できることです。

共通タスクと二つの観察系列

閲覧権限を申請し、オーナー承認後に IdP 設定を完了する。途中で一件の例外申請と応答消失が発生する。

全段階で固定するのは、画面条件、画面文法、タスク目標です。アカウント、カテゴリー、緊急性、権限、内容、ネットワーク障害は試行ごとの条件として記録します。統合物語では連続して見せますが、観察研究で全障害を一人へ必ず順番に注入する設計ではありません。

自然行動系列: 事前に予測を尋ねず、最初の操作から観察する。
明示予測系列: 別参加者に、操作前の予測を尋ね、その質問の影響下で操作を追う。

二系列をつないで一人の心的更新にしません。初回、同セッション内の反復、24 時間後の保持、別内容への転移も別試行として記録します。

共通 Task、二系列、三時点の設計を示す図。 — 図 III-1　共通 Task、二系列、三時点の設計

第 1 段階　初回――持ち込まれた期待と作者の前提

ロゴ、ボタン、パンくずリスト、承認という語から、利用者は過去の Web、プラットフォーム、業務経験を持ち込みます。一方、作者は SCIM、IdP、オーナー、承認後の別システムを知っています。

観察台帳を分けます。

根拠	記録
画面	見えるテキスト、名前、役割、状態、リンク
作者	前提知識、意図、概念モデル
自然行動	最初の操作、停止、戻り、完了
回顧発言	操作後の予測説明
実装	ルート、権限、状態、イベント

「初見者は用語を知らない」「管理者なら分かる」と決めず、領域経験、同種 UI 経験、言語、デバイス、支援技術を記録します。

初回の五つの Evidenceを示す図。 — 図 III-2　初回の五つの Evidence

第 2 段階　反復――規則を学ぶ

三件の通常申請では、青いボタンは申請、右端の山形アイコンは詳細、承認後は次操作リンクが現れる、という表現と役割が反復します。

観察された反復と、推測された規則と、実装仕様を分けます。三回続いたから全員が学習したとはしません。次の同型画面で最初の操作が変わるか、規則を説明できるか、24 時間後も保持するかを別に確認します。

同じ通知への反応が減っても、直ちに馴化と呼びません。刺激の反復、反応指標、刺激特異性、回復を観察する手順が必要です。

反復、推測規則、実装仕様を示す図。 — 図 III-3　反復、推測規則、実装仕様

第 3 段階　例外――何が違い、なぜ違うか

四件目は subject_type=contractor、urgency=urgent、permission=read の権限申請です。契約者種別、緊急性、危険度、権限は別データ項目で、どれが赤、ラベル、角丸へ対応するかは監査前には未確定です。差は意図された優先、危険状態、別カテゴリー、ブランド表現、実験条件、権限、旧部品残存のどれでも説明でき、複数が同時に成立する場合もあります。

まず色、角丸、ラベル、位置、動きという物理差と出現条件を記録します。データ、部品、バリエーション、トークン、権限、機能フラグを監査します。顕著性、注意、理解、選択、完了を一つの「目立った」にまとめません。

改善候補は一軸ずつ比べます。カテゴリーラベルだけを加える案、ボタン文法だけを揃える案を別案にします。ブランド上の価値、学習コスト、誤申請リスク、回復可能性を並べます。

例外の物理差、七仮説、一軸介入を示す図。 — 図 III-4　例外の物理差、七仮説、一軸介入

第 4 段階　待機と失敗――結果不明から回復する

申請ボタンを押し、サーバーでは処理が成功しましたが、応答だけが失われます。クライアントにはタイムアウトが見えます。これは失敗確定ではなく、結果不明です。

受付、処理中、成功、失敗、取消要求中、結果不明、再照会、回復を状態表にします。リクエスト ID、操作 ID、冪等性キーを同義にしません。新しい申請を再試行する前に、同じ操作を再照会します。

フィードバックはアニメーションだけではありません。「申請状況を確認中」という見えるテキスト、操作可能性、プログラム上の状態、ステータス通知を同期します。役割があること、特定環境で通知されたこと、意味が理解されたことは別の根拠です。

結果不明と回復の状態機械を示す図。 — 図 III-5　結果不明と回復の状態機械

第 5 段階　再訪――保持と転移を分ける

24 時間後の保持試行では同じアカウント／内容／規則を使います。その後の転移試行で、規則を固定してアカウント／内容だけを変えます。時間間隔と内容変更を一条件へまとめません。作者は正解を知ったままなので、再訪した作者の自己評価を初見根拠にしません。

初回操作、タスク固有の到達基準、即時再試行、24 時間後の保持、別内容への転移を分けます。二回連続成功はこの画面条件の運用基準で、人間一般の学習成立条件ではありません。初回で失敗して一度で学べた UI と、毎回迷う UI を区別します。一人の保持を全利用者へ一般化しません。

文化、世代、プラットフォーム、支援技術で期待が異なる可能性は、文脈別の仮説です。人物属性を原因とせず、利用履歴、入力方法、提示された手がかり、実装状態を確認します。

初回から再訪までの Evidence 境界を示す図。 — 図 III-6　初回から再訪までの Evidence 境界

予防、検出、影響緩和、回復

エラーをゼロにするだけが設計ではありません。

予防: 誤解されるカテゴリー差や重複操作を減らす。
検出: 受付、競合、結果不明を利用者とシステムが知る。
影響緩和: 入力データを保持し、重複業務処理を防ぐ。
回復: 再照会、修正、取消、サポートへ到達できる。

どの層を変えたかを分けます。ボタンラベルの変更はサーバー冪等性を作らず、冪等性は状態理解を自動で作りません。

一本の観察を四章で読む

時点	観察	横断仮説	追加根拠	一軸介入	反証・副作用
T+18s	四件目で入力なし。その後戻る	慣習と予測の不一致／三件の反復規則との衝突／受付状態の誤読／契約者用語・権限前提／読解・外部中断	行動後発言、ボタンイベント、権限、ネットワーク	契約者ラベルだけ追加	ラベル後も停止／通常申請の密度増加
T+31s	送信後に再度送信	受付フィードバック不足／イベント重複／応答消失／サーバー処理不明／作者だけが再照会手順を知る	操作／リクエスト／サーバーログ、DOM、状態	見える受付テキストだけ追加	利用者試行で再押下が変わらない

時刻は記入形式を示す例の値で、利用者の実測結果ではありません。実調査では元イベントを保存し、何秒を「迷い」とする普遍的閾値を置きません。

統合手順は、観察→四章横断の複数仮説→必要根拠→状態所有者別の実装監査→一軸介入→反証→別段階・入力方式・対象者への副作用確認です。

問い

いま観察した事実を、第 15〜18 章のどの複数概念で説明できますか。
仮説を見分けるため、画面、行動、発言、実装、サーバーの何が必要ですか。
誰が、どの状態を、いつ知れる／知れないですか。
一つだけ何を変え、何を固定しますか。
どの結果なら仮説を弱め、別段階や入力方式へ何を悪化させますか。
ブランド価値、学習コスト、領域リスク、回復をどの根拠源から記録しますか。

答えの例

四件目で停止したという一つの観察に、過去のボタン慣習との不一致、三件で推測した規則との衝突、フィードバック不足、契約者用語・権限の前提、読解や通信という仮説を残します。観察は操作が一定時間なかったことと戻る操作だけで、原因はまだ不明です。行動後発言、権限、ネットワーク、部品バリエーションを追加します。

申請後のタイムアウトは失敗確定ではありません。同じ操作 ID を再照会し、サーバー成功なら完了状態へ同期します。「再送」ラベルだけを「状況を確認」へ変える案と、サーバーの冪等性を加える案は別に検証します。結果不明注入数を分母に確定到達率、重複業務処理率、状態説明を記録します。

別解として、緊急申請が法的・業務的に異なるカテゴリーなら、差を消すより理由を明示する方がよい場合があります。よくある説明の「一貫性がない」「フィードバックがない」「初見者には難しい」だけでは、対象、時点、状態、根拠が不足します。

別の観察例 1――承認後に次へ進まない

観察は、承認済み表示の後に同じページを往復し、IdP 設定へ到達しなかったことです。承認でタスク完了と予測した、反復した青ボタンを次操作と認識しなかった、状態更新を検出できなかった、IdP という前提を作者だけが知る、リンクがフォーカス順外という仮説を残します。行動後発言、アクセシビリティツリー、フォーカス順、ルート、権限を追加根拠にします。次操作リンクの見えるラベルだけを変え、到達率を承認済み試行数で割ります。到達が変わらずフォーカス順が壊れていれば、文言仮説は弱まります。よくある考え方は「承認済みと出ているので分かる」です。状態の検出、意味理解、次操作は別です。

別の観察例 2――再訪で通常申請も止まる

観察は、24 時間後の同一内容の保持試行で通常申請の前に戻ったことです。規則を保持しなかった、初回はヘルプに依存した、例外の赤ボタンが通常規則を更新した、アカウント状態が変わった、単に中断されたという仮説があります。接触履歴、ヘルプ、開始時の画面記録、行動後説明、部品版を確認します。ヘルプ表示だけを固定して保持試行を再設計し、正しい初回操作／保持試行数と副作用のヘルプ依存を記録します。内容を変える転移試行は別にします。「翌日できないので UI が直感的でない」だけでは、保持、状態差、追加接触を分けていません。

独習と倫理

紙上では記入済みログを根拠の層と四章の仮説へ分類します。一人では架空の画面条件を操作し、機能点検と自分の行動を別にします。他者観察では、自然行動か明示予測の一系列、一つの障害注入だけに限定します。

自由意思、同意、休止・中止、録画／音声／操作ログの別同意、仮名化、閲覧者、保存期間、撤回を定めます。同僚・部下が断っても不利益を受けないようにし、安全情報を隠しません。応答消失と権限例外は架空環境だけで注入し、実アカウントや本番環境へ接続しません。

共通評価観点

観察と推論、四章横断の最低二仮説、必要根拠、知識と状態の所有者、一軸介入、分母、反証、副作用、一般化範囲を確認します。

セルフチェック

初回、反復、例外、失敗、再訪を別試行として記録した
画面、作者、自然行動、回顧発言、実装を分けた
例外に複数仮説を残し、一軸介入を選んだ
失敗確定と結果不明、再照会と再試行を分けた
ブランド価値と学習コスト、リスクを単一スコアにしなかった

第 IV 部　Web デザイナーは、どう見るか

ここまで、近接、注意、記憶、期待、フィードバック等の名前を知りました。しかし、名前を画面へ貼ればレビューが完成するわけではありません。

「これは近接の原則です」「認知負荷が高いです」「知識の呪いです」という言葉は、観察を省略すると結論だけを強くします。第 IV 部では、理論を答えとして当てるのではなく、違和感を第三者が確かめられる記録へ変えます。

三つの根拠

画面: 距離、位置、色、文字、状態、変化として何が見えるか。
コード: DOM、CSS、データ、部品、イベント、ネットワークに何が実装されているか。
人: 何を予測し、どこで止まり、何を操作し、結果からどう回復するか。

三つは互いの代わりではありません。CSS 値が揃っていても視覚的に揃うとは限らず、画面が分かりやすそうでもタスクを完了できるとは限りません。一人が完了しても、すべての利用者へ一般化はできません。

観察、解釈、評価

第 IV 部では、記録を三つへ分けます。

観察: 第三者が同じ条件で確認できる記述。
解釈: なぜ起きたかについての仮説。
評価: 目的や価値に照らした判断。

分ける目的は、評価や美的判断を捨てることではありません。どこで事実から仮説へ進み、何を大切にして判断したかを話せるようにするためです。

一つの変更で一つの仮説を見る

比較するときは、可能な範囲で一つだけ変えます。余白、ラベル、順序、状態表示を同時に変えれば、どの仮説が支持されたか分かりません。

実務では複数変更を含む完成案も必要です。その場合は、因果を調べる比較と、統合した設計案を分けます。改善、正解、ベストプラクティスという言葉を、測定前の案へ付けません。

第 IV 部の流れ

違和感を観察語へ変える
名前を使って複数仮説を作る
並べ、重ね、差を見る
ブラウザを動かして壊れる条件を見る
DevTools で実装を監査する
人の行動で仮説を限定的に確かめる
作り、見て、疑い、また作る

最終章では、第1章と同じ画面へ戻ります。模範解答を当てるのではなく、最初には持っていなかった観察語、仮説、確かめ方を使い、自分の目がどう変わったかを確認します。

第19章　「なんか変」を観察する

画面を見た瞬間の「なんか変」は、捨てなくてよい感覚です。ただし、そのまま修正指示にすると、何を、なぜ、誰のために変えるのかを共有できません。

本章では違和感を結論ではなく入口にします。観察、解釈、評価を分け、第 I〜III 部で得た言葉を使い、第三者が同じ条件で再確認できる短い記録へ変えます。最後には、好み、表現意図、価値判断を含む批評へ戻ります。

この章の必修は三つです。

評価語を、対象・位置・比較・状態・条件を含む観察へ書き換える
一つの観察に複数の解釈を残す
観察だけで終わらず、目的と価値に照らした評価へ戻る

実務では八段階で進めます。違和感を原文のまま保存し、URL、ビューポート、データ、状態、時刻、直前操作を残します。証拠源を画面、実装、行動、発言、作者資料へ分け、対象、位置、属性、比較相手、条件を観察文にします。不明、未測定、推測値を明記し、複数解釈を作ります。対象者、タスク、表現意図、価値に照らして評価し、一属性だけを変え、反証と副作用を確認します。

19.1 違和感は捨てず、結論を急がない

「なんか変」と感じたら、すぐに余白、色、フォントを変更せず、時刻、画面、ビューポート、状態、最初に気づいた場所を記録します。感覚は仮説を探す入口です。

変更を急ぐと、元の違和感を再現できず、複数条件を同時に変えやすくなります。スクリーンショット、URL、データ、操作直前の状態を保存し、「直したい」を別欄に置きます。

19.2 観察、解釈、評価

次の三文は違います。

観察: フォームのラベルと入力欄は 12px、入力欄と次のラベルは 8px 離れている。
解釈: 次のラベルが前の入力欄と同じまとまりに知覚される可能性がある。
評価: 項目単位で読み進める目的に対し、この距離関係は望ましくない。

観察にも視点の選択が入り、完全に中立ではありません。それでも、測った場所、比較相手、条件を示せば、他者が再確認できます。解釈には近接以外に、ラベルの書体、境界線、背景、読順という代替仮説を残せます。

19.3 「ダサい」「いい感じ」を一度禁止する

「ダサい」「いい感じ」は、個人の経験、文化、流行、ブランド期待を含む大切な反応です。しかし相手が次に何を観察すればよいかは示しません。

レビューに短い観察段階を設け、評価語をいったん退避して何を見たかを書きます。授業では 5 分を例にできますが、普遍的な時間ルールではなく、複雑な状態やアクセシビリティ監査にはさらに時間が必要です。その後に「このブランドは静かな信頼感を目指すので、強いグラデーションと跳ねる動きは意図から外れる」と評価へ戻ります。

「ダサいと言わないでください」と反応を退けません。「そう感じた言葉をまず残しましょう。画面のどこで、何と比べてそう感じましたか」と共同で分解します。退避は好みを消すためではなく、判断の道筋を共有する足場です。

19.4 距離、揃い、類同、強さを見る

第 I 部の観察 Lensを示す図。 — 図 19-4　第 I 部の観察 Lens

知覚については、次を観察します。

どの要素間の距離が、何と比べて近い／遠いか
左端、右端、中央、ベースラインのどこが揃う／ずれるか
同じ役割の見た目がどこで同じ／異なるか
境界線、背景、影がどのまとまりを重ねているか
大きさ、コントラスト、色、動きのどれが物理的に強い候補か。実際に何へ気づいたかは、発言、行動、視線など別の証拠で確かめる

「余白が足りない」ではなく、「ラベルと入力欄の距離 12px より、入力欄と次ラベルの距離 8px が短い」と書きます。値だけで善悪を決めず、関係を記録します。

19.5 情報量、選択、記憶、操作を見る

第 II 部の観察 Lensを示す図。 — 図 19-5　第 II 部の観察 Lens

処理については、利用者に何を保持、探索、比較、操作させるかを見ます。

現画面に前ページのプラン名が表示されず、タスク上はそれを参照する必要がある。記憶から再生したかは未測定である
100 件あるが検索とカテゴリーで候補を絞れる
同じ意味の選択肢が複数カテゴリーへ重複する
閉じるアイコンの見た目は 16px だが操作領域は 44px ある
エラー修正後に前の入力値が保持されない

「情報量が多い」と「認知負荷が高い」を同義にしません。情報が多くても構造と手がかりがあり、タスクに必要なら問題でない可能性があります。

19.6 規則、期待、状態、例外を見る

第 III 部の観察 Lensを示す図。 — 図 19-6　第 III 部の観察 Lens

予測については、反復、例外、操作前後を時間で見ます。

三つの青いテキストはリンクだが、四つ目は操作できない
同じ役割のボタンで一つだけ角丸が違う
送信後もラベル、操作可能性、状態が変わらない
タイムアウトだがサーバーでは成功済みかもしれない
作者だけが次のシステムを知っている

これらは観察または監査候補です。「確証バイアス」「知識の呪い」と作者を診断しません。データ、部品、状態、自然行動、発言を追加します。

19.7 曖昧なレビューを書き換える

三つのレビューを書き換えるを示す図。 — 図 19-7　三つのレビューを書き換える

「余白が足りない」

どの要素間か、比較相手は何か、その距離がどの関係を表せないかを書きます。

「UX が悪い」

誰が、どのタスクのどの時点で、何を予測し、何が起き、どう回復できなかったかを書きます。

「認知負荷が高い」

利用者が頭の中に保持する情報、同時に比較する候補、更新する状態、不要な処理を列挙します。画面の要素数だけを根拠にしません。

19.8 観察記録の粒度を揃える

短い記録には次を含めます。

［条件］で、［対象・位置］の［属性・状態］が、［比較相手］と［どう異なる］。

証拠源、対象 ID、取得方法、単位、根拠の状態も付けます。

証拠源	記録例	再確認方法
画面	箱の可視位置、色、表示状態	スクリーンショット、幾何情報
実装	DOM、CSS、アクセシビリティツリー、イベント、データ	DevTools、ログ
行動	操作、停止、戻り、完了	同意済みイベント記録
発言	予測、理由、評価	発言原文と質問時点
作者資料	意図、ブランド方針、仕様	目的資料、判断記録

観察済み、報告済み、仕様上の情報、推測、未測定を区別します。スクリーンショットだけで操作領域、読み上げ、理解、学習を断定しません。

例:

幅 390px、未入力エラー表示時、エラー概要から二つ目の項目へ移動すると、ラベルの可視矩形は固定ヘッダーの矩形と重なり、文字全体が画面に露出しない。

対象、位置、比較、状態、条件があれば、別の人が再現しやすくなります。矩形の重なりは幾何情報で確認できますが、利用者が読めなかったか、意味を理解できなかったかは行動や発言による別の測定です。

19.9 観察から、根拠のある批評へ戻る

観察だけを並べても、何を大切にするかは決まりません。マーケティングサイトでは驚きや余韻、業務システムでは速度とエラー回復、ミュージアムサイトでは没入や解釈の余地が重視されるかもしれません。

批評では、観察、複数解釈、表現意図、受け手の経験、目的、副作用を結びます。測定できない美しさ、違和感、文化的参照も議論できます。ただし、それらを心理学の法則で権威付けしません。

19.10 問い――評価を一語も使わずに画面を記述する

問い

商品登録フォームを見て、次の六問へ答えてください。

条件、証拠源、対象、位置、属性、比較相手は何ですか。
何が未測定、推測値ですか。
どんな別解釈がありますか。
誰のどのタスク、表現意図、価値に照らして評価しますか。
一つだけ何を変え、何を固定しますか。
どの結果なら仮説を弱め、どんな副作用を見ますか。

答えの例

幅 1280px、初期状態で、ページタイトル、セクション見出し、項目ラベルのフォントの太さがすべて 600、文字サイズ差は 24px、20px、18px です。主要操作と補助情報の背景は同じ青です。必須項目 8 件のうち、ラベルと入力欄の距離より入力欄と次ラベルの距離が短い箇所が 5 件あります。

これは視覚的階層、類同、近接で説明できる可能性があります。別仮説として、内容の語彙、読順、表示調整もあります。最重要タスクを見つけやすくすることが目的なら、文言、DOM 見出しレベル、太さ、余白、色を固定し、ページタイトルのフォントサイズだけを 24px から 32px へ変えます。自然閲覧時の最初の注視・操作は行動または視線として記録します。タスクを示して「指してください」と求めた結果は、課題誘導を受けた指示行動として別に記録します。サイズ変更だけで意味理解が改善するとは限りません。

別の答え方

この画面は、情報を等価に見せる静かな表現を意図しているかもしれません。強弱を増やす前にブランド意図とタスク頻度を確認します。

よくある考え方

余白とメリハリを増やせばよいです。

注意点

どの関係と目的を変えるかがなく、複数属性を同時に変更しています。

別題 1――送信中の画面

観察は、save-button のクリック後 5 秒間、見えるラベル、disabled、aria-busy、状態テキストが変わらず、リクエストは待機中です。5 秒はネットワーク条件の例の値で、迷いの測定ではありません。受付イベント未接続、表示更新漏れ、メインスレッド停止、意図的な即時再操作許可を仮説にします。まず見えるラベルだけを「保存中」へ変え、タスク開始数を分母に再押下と状態説明を記録します。別解として処理が即時ならローディング表示はちらつきを増やします。よくある考え方は「スピナーを付ける」ですが、受付、結果、重複処理、通知を同時には解決しません。

別題 2――検索結果

観察は、100 件の結果にカテゴリーフィルターが 4 つ、検索欄が 1 つあり、同じ商品が二カテゴリーへ現れます。件数が多いことだけでは問題を示しません。分類の重複、ラベル理解、検索語、タスク条件を仮説にします。一軸比較では、重複する 10 商品の secondary_category だけを削除し、商品数、順序、商品名、検索、レイアウト、ビューポートを固定します。対象商品発見数／探索タスク数と見落としを記録します。「選択肢を減らす」がよくある考え方ですが、必要な候補を消す副作用があります。

別題 3――文化施設の表現

観察は、ヒーロータイトルの可視矩形がビューポート下端と交差し、スクロール時に全体が現れ、背景動画は reduced-motion で静止画像になります。没入と発見の遅延を意図した可能性、レスポンシブ崩れ、鑑賞文脈、文化的・ブランド上の参照仮説を分けます。一軸比較では CSS の hero-title の inset-block-start だけを calc(100svh - 40px) から calc(100svh - 80px) へ変え、文言、書体、動画、スクロール、ビューポートを固定します。完了時間だけで価値を決めず、作者資料、鑑賞者の解釈、ナビゲーション達成、副作用を並べます。「読みにくいので上へ出す」だけでは表現意図を消します。

共通 Rubric

証拠源と取得方法、再確認可能な観察、未測定、最低二解釈、タスク／意図／価値による評価、一軸介入、分母、反証、副作用を確認します。

セルフチェック

対象、位置、比較、状態、条件を含む観察を書ける
観察、解釈、評価を別欄に置ける
曖昧語を分解した後、目的と表現意図を含む批評へ戻れる
画面、実装、行動、発言、作者資料を別根拠として記録できる

参考

第 I〜III 部の各章 — 概念名ではなく観察語と誤用上の注意へ戻ります。
ISO 9241-210:2019 — Context of use と Evaluation を確認する入口です。
WCAG 2.2 — プログラムから読み取れる状態等の仕様点検に使い、美的評価の答えにはしません。

第20章　名前を使って仮説を作る

「これは近接の原則です」「認知負荷が高いです」。名前を知ると、違和感を共有しやすくなります。しかし、名前を置いただけでは、何が起き、何を変え、どんな結果なら説明を見直すのかは分かりません。

本章では、概念を答えではなく検索可能な候補として使います。観察から複数の説明を作り、変更、予測、反証条件までを一つの仮説記録にします。同時に、測定できる因果の問いと、表現や価値を論じる解釈的な問いを分けます。

この章の必修は三つです。

概念名の前に、条件付きの観察を書く
最低一つの代替仮説と反証条件を残す
一軸介入で確かめる問いと、批評で考える問いを区別する

20.1 名前は答えではなく、検索可能な候補である

名前には、現象を再発見し、他者と共有し、先行研究を探す働きがあります。「近接」と知れば、距離がまとまりにどう関係するかを次の画面でも探せます。

一方、名前は視野を狭めます。一度「近接の問題」と呼ぶと、ラベルの語彙、読順、境界線、エラー状態を見落とすかもしれません。概念は観察から検索へ進む索引であり、画面に貼る診断ラベルではありません。

20.2 概念名だけの指摘が会話を止める

概念名だけのレビューを分解するを示す図。 — 図 20-2　概念名だけのレビューを分解する

本書では、概念名だけを置いて説明を終える発話や記録を、便宜的に「概念名だけの指摘」と呼びます。確立した心理学効果の名称でも、人に貼るラベルでもありません。

選択肢が多い。ヒックの法則です。

この文からは、候補数、分類、検索、利用者の知識、タスク、反応時間のどれを問題にしているか分かりません。次のように問い返します。

何を観察しましたか。
どの条件で起きましたか。
その概念が説明する範囲はどこですか。
別の説明はありますか。
何を変えると、何がどう変わる予想ですか。

20.3 観察から概念へ進む

Evidence から概念候補へを示す図。 — 図 20-3　Evidence から概念候補へ

まず根拠源を示します。

幅 1280px、初期状態で、ラベルと入力欄は 12px、入力欄と次ラベルは 8px 離れている。幾何情報で測定した。

ここから「近接」を適用候補にできます。ただし、近接が原因だとはまだ言いません。類同、共通領域、読順、ラベル文言も候補です。画面、実装、行動、発言、作者資料を混ぜず、概念がどの根拠を説明しようとしているかを記します。

20.4 概念から仮説へ進む

基本形は次です。

私は［条件付きの観察］を記録した。これは［要因候補］によって起きている可能性がある。［一つの変更］を行い、他を固定すると、［測定可能な結果］になると予想する。［反対の結果］なら、この仮説への確信を弱める。

例:

商品フォームで、入力欄と次ラベルの距離 8px が、対応するラベルとの距離 12px より短い。距離によるまとまりが意図と逆である可能性がある。各ラベルと操作部品を包む .field は固定し、親 .form-fields の row-gap だけを 8px から 20px へ変えると、項目対応の誤りが減ると予想する。同じタスク条件で誤りが減らない、または増えるなら、この説明への確信を弱める。

結果は「良くなる」でなく、タスク成功、誤選択、停止、発言、知覚判断など、取得方法と分母を定めます。

20.5 一つの違和感に複数の説明を置く

「どのボタンを押すか分からない」という発言には、複数の説明があります。

主要操作と補助操作の外観が似ている――類同・視覚的階層
ラベルがタスクの言葉と一致しない――内容理解
他サイトと位置や挙動が異なる――期待・メンタルモデル
送信後の状態が変わらない――フィードバック
クリック領域に別要素が重なる――実装不具合

どれも候補です。複数概念を列挙しただけにもせず、各候補に必要な追加根拠を書きます。

20.6 代替仮説を残す

代替仮説は、自説を弱く見せるためではなく、次に何を調べるかを明らかにします。少なくとも次の層を点検します。

層	例	追加根拠
画面	距離、色、順序	スクリーンショット、幾何情報
内容	ラベル、語彙、情報不足	内容レビュー、理解発言
実装	重なり、イベント、状態不整合	DOM、CSS、ログ
利用状況	タスク、端末、専門知識	文脈記録
測定	誘導質問、画面条件の差	手順、記録一式

候補を無制限に増やさず、誰への影響か、危険度、可逆性、確かめやすさ、表現価値を別列で記録して優先順位を付けます。合算スコアにはせず、測りにくい重大リスクを落としません。

20.7 一度に一つだけ変える

説明候補を見分けやすくする比較では、一つの操作対象だけを変え、内容、データ、ビューポート、状態をできるだけ固定します。操作したプロパティが一つでも、知覚、意味、スクロール、タスク戦略など複数の結果が変わり得ます。余白、色、文言を同時に変えて成功しても、どの変更が関係したか分かりません。

一軸変更だけで因果が証明されるわけではありません。人への影響を比較するなら、参加者、タスク、条件順序、学習、割付、測定誤差も扱い、操作が予定どおり成立したかを先に確認します。同じ人が両条件を行うなら順序を釣り合わせ、異なる人なら割付と経験差を記録します。実務では複合案が必要なこともあります。その場合は、科学実験と呼ばず、変更台帳へ差分をすべて記録します。可能なら一軸の診断比較と、複合した完成案の全体評価を分けます。部分の因果と、案全体の価値は別の問いです。

20.8 UX 用語で相手を押さえつけない

「法則だから」「認知科学的に正しいから」は、議論を終わらせます。用語を知らない人の観察や、作者の表現意図を劣位に置いてはいけません。

ヒックの法則なので減らしてください。

ではなく、

30 項目が一列に並ぶ架空の教材画面です。行動はまだ測定していません。候補の分類が探索を難しくするという作業仮説を置き、往復イベントを事前定義して比較したいです。ただしラベル理解の問題かもしれません。

と書けば、観察、範囲、提案、未確定事項を共同で検討できます。

20.9 因果仮説と、解釈的な問いを分ける

ボタンの距離を変えると誤選択率が変わるかは、条件と測定を定めた因果の問いにできます。一方、「この余白は高級感、緊張、孤独のどれを表現するか」は、作者資料、作品文脈、受け手の経験、批評的比較を必要とする解釈的な問いです。

後者を誤選択率だけで決めず、前者を作者の意図だけで証明しません。同じ画面に両方の問いが存在できます。

20.10 問い――どの結果なら、この仮説への確信を弱めるか

問い

商品検索画面には 100 件、四つのカテゴリー、検索があります。同じ 10 商品が二カテゴリーへ重複しています。行動データは未取得です。概念名だけで結論を出さず、実施前の仮説記録を書いてください。

答えの例

以下は実測結果ではなく、実施前計画の記入例です。カテゴリー重複が候補集合の予測を難しくする可能性があります。参加者 ID、条件、タスク項目、提示順、事前経験、検索利用を試行ごとに記録します。同じ参加者が基準条件と介入条件を行うなら条件順を釣り合わせ、参加者内の反復を人数として数えません。成功は対象商品の詳細ページへの正しい到達、時間はタスク表示から到達・中止まで、往復は A→B→A のカテゴリー選択イベントと定義します。サンプル数は事前の分析計画に基づいて決め、12 試行を普遍的基準にはしません。

重複 10 商品の secondary_category だけを削除し、商品数、配列順、ラベル、検索語、レイアウトを固定します。検索索引は商品名と説明だけから生成し、カテゴリーメタデータを索引しない画面条件にします。操作成立とデータ品質を確認した後、往復が減らない、発見率が下がる、または結果が参加者ごとに逆方向なら、仮説を弱め、ラベル理解や検索語を再検討します。差が測れない場合と操作に失敗した場合は分けます。

別の答え方

重複は複数の探し方を支える意図かもしれません。分類の一意性を目的にせず、検索語、探索経路についての語り、現場の業務分類、作者の情報設計資料を別根拠として並べます。読みの一致率だけで分類の価値を決めず、誰のどの実践を支える分類かを批評します。

別題――解釈的な問い

解釈的な問いの Evidenceを示す図。 — 図 20-9　解釈的な問いの Evidence

文化施設サイトのヒーロータイトルはビューポート下端と交差し、スクロールすると全体が現れます。作者資料には「展示へ入る前の境界を作る」とあります。これは単なる表示不具合でしょうか、それとも表現でしょうか。

答えの例

幾何情報とレスポンシブ条件は画面根拠、境界という意図は作者資料、遅れて読めた驚きや不安は受け手の発言として分けます。類似する展示サイトと業務サイトも比較します。作者意図だけで成功を証明せず、発言の多数決だけで表現を消しません。ナビゲーション達成、文字へのアクセス、没入という価値がどこで両立し、どこで衝突するかを記述します。

別の答え方

意図があっても、ズームや短いビューポートでタイトルへ到達できないなら、表現とは別にアクセス上の破綻があります。意味の解釈と実装条件の監査を並行します。

よくある考え方

ヒックの法則に反するので、カテゴリーか商品を減らします。

注意点

Hick–Hyman Law が扱う選択反応時間と、分類を使う探索タスクを同一視しています。必要な候補を消す副作用と反証条件もありません。一回の予想不一致だけで仮説全体を棄却せず、操作、実装、測定感度、対象範囲を先に点検します。

セルフチェック

概念名より前に条件付きの観察がある
要因候補と原因確定を区別した
一軸変更、固定条件、取得方法、分母を書いた
最低一つの代替仮説と反証条件がある
因果の問いと表現・価値の問いを区別した

参考

第19章「『なんか変』を観察する」— 仮説の前に根拠源と観察を分けます。
Lazar, Feng, Hochheiser, Research Methods in Human-Computer Interaction — HCI の研究問い、変数、方法を知る入口です。
ISO 9241-210:2019 — 利用状況、評価、反復設計との接続を確認できます。
Karl R. Popper, The Logic of Scientific Discovery, Routledge, 2002（初版英訳 1959）, Chapter 1 — 反証可能性の哲学的背景を知る資料です。本章の比較をそのまま科学実験とみなすものではありません。
Jonathan Lazar, Jinjuan Heidi Feng, Harry Hochheiser, Research Methods in Human-Computer Interaction, 2nd ed., Morgan Kaufmann, 2017, Chapters 2, 4, 7 — 研究問い、実験、行動データの設計を確認する中級の英語資料です。
Carole Gray and Julian Malins, Visualizing Research: A Guide to the Research Process in Art and Design, Ashgate, 2004, Chapters 2–3 — Art and Design における問いと解釈的探究の入口です。

第21章　比べる

二つの画面を見比べると、単独では気づかなかった 1px のずれや色の差が見えます。しかし、比較は真実をそのまま見せる窓ではありません。並べ方、順序、基準、変更数によって、見える差も判断も変わります。

本章では、横並び比較、重ね合わせ、点滅比較を使い分け、条件を固定した比較と方向性の異なる案の批評を分けます。差異閾と JND も扱いますが、デザイン値を決める万能公式にはしません。

21.1 絶対値より、並んだ差が見つけやすい

一つのグレーを見て「#777 か#7A7A7A か」と答えるのは難しくても、二つを隣接させれば境界が見えることがあります。人は常に絶対値を読んでいるわけではなく、周囲との関係も手掛かりにします。

ただし、同時比較で見つけた差が、単独利用時にも気づかれ、タスクへ影響するとは限りません。「差がある」「差に気づく」「差が意味を持つ」を分けます。

21.2 Before／After が隠してしまうもの

Before/After 監査を示す図。 — 図 21-2　Before/After 監査

変更前と変更後でビューポート、データ、スクロール、状態、フォント読込が違えば、意図した変更以外の差が混ざります。変更後が右側にあり「改善版」とラベル付けされるだけでも期待が生まれます。

記録 ID、元データのハッシュ、ブラウザ、ビューポート、画面条件、状態、スクロール、フォーカス、時刻を保存し、変更台帳と視覚差分を照合します。比較順を入れ替えた版も用意し、順序の影響を疑います。

21.3 横並び、重ね合わせ、点滅比較

横並び: 全体の方向性、階層、ブランド印象を並べやすい。視線移動と記憶が必要になる。
重ね合わせ: 位置、サイズ、形のずれを重ねて見つけやすい。透明度や合成色が新しい見えを作る。
点滅: 同じ位置を交互表示し、動いた領域を見つけやすい。ただし光感受性発作、片頭痛、めまいなどのリスクがあり、主経路にはしない。

既定の主経路は横並びと静止した重ね合わせにします。点滅は明示的な利用者操作がある場合だけ一往復を表示し、連続反復を既定にしません。実装する場合も WCAG 2.2 SC 2.3.1 の点滅頻度、輝度差、赤、面積の条件を監査し、中止、静止した代替比較を用意します。利用者起動であっても安全になるとは限りません。色だけで差を示さず、輪郭、パターン、ラベルも使います。

21.4 記憶で比較しない

別ページを行き来して「たぶん前より広い」と判断すると、スクロール位置、内容、時間経過が混ざります。スクリーンショットを同じ寸法で固定し、対応点を揃え、差分を同時に見られるようにします。

それでも、記憶を使う比較が無意味なわけではありません。ブランドの想起や、再訪時の印象を問うなら、時間を空けた単独提示自体が調べたい条件になります。何を比較したいかで方法を選びます。

21.5 一度に一つの差を作る

説明用図版では、一枚につき一つの差だけを作ります。row-gap を 16px から 24px へ変えるなら、内容、フォント、幅、状態を固定します。

これは案全体を作るルールではありません。実務案ではタイポグラフィ、間隔、色が関係し合います。一変数の診断図と、複合案の総合比較を別に残します。

21.6 差異閾と Just Noticeable Difference

簡単に言えば、差異閾は「どれくらい違えば弁別できるか」を扱います。より正確には、基準刺激、刺激次元、提示方法、課題、回答基準、観察者、環境を定め、刺激差と弁別回答の確率関係から推定します。

閾は人の中にある一本の硬い境界とは限りません。F05 の模式図では、二つの刺激のどちらが基準より大きいかを答える 2 択課題を用い、偶然水準である 50% より上の、事前に定めた正答率となる点を手続き上の閾として示します。何%を採るか、2 択か、同時か、時間をおいて示すかで値は変わります。

21.7 JND をデザイントークンの公式にしない

「フォントサイズは 2px 違えば見える」「不透明度は 10% 刻みなら安全」のようなルールは作れません。刺激次元、基準量、コントラスト、周辺文脈、表示装置、観察時間、個人差が違うからです。

Weber の法則は、条件によって弁別に必要な差が基準量に比例するという近似を記述します。全範囲で成立する普遍法則でも、Web のトークン計算式でもありません。トークンは製品内の役割、一貫性、アクセシビリティ、実装・運用と合わせて決めます。

21.8 比較が判断を歪める場合

極端に悪い案の隣へ本命案を置けば、本命は良く見えます。最初に見せた案が基準になり、後の差をその基準から評価することもあります。案名を「改善版」「旧版」とすれば期待が入ります。

案 ID を中立にし、提示順と左右位置を別々に記録して釣り合わせ、比較対象を選んだ理由を記録します。順序反転だけで誘導が消えたとはみなしません。評価者へ何を隠すかは倫理と実務文脈を考え、欺瞞を無条件に勧めません。

21.9 一変数比較のあとで、全体へ戻る

間隔、色、タイポグラフィを別々に改善しても、統合すると静けさが失われたり、階層が過剰になったりします。部分比較の結果を機械的に足しません。

完成案では、タスク、表現意図、ブランド、内容、レスポンシブ、状態、アクセシビリティ、運用をもう一度見ます。一変数比較は診断のレンズで、全体の答えではありません。

21.10 方向性の異なる案を比べる

同じ Brief から三方向を示す図。 — 図 21-7　同じ Brief から三方向

同じ目的資料から、密度を保つ業務案、安心感を重視する案、強い編集的表現の案が生まれます。差が一つでないため、因果比較には向きません。しかしデザイン批評には重要です。

目的、対象者、感情、ブランド、運用、リスク、捨てる価値を並べます。「A が優勝」で終えず、どの文脈で何を選ぶ案かを言葉にします。

21.11 問い――何を固定し、何だけを変えたか

問い

二つの購入手続き画面を比較すると、変更後はエラーを見つけやすく見えます。何を確認しますか。

答えの例

ビューポートは 1280×800 で同じですが、変更前はエラー 1 件、変更後は 3 件、スクロール位置も 64px 違います。境界線の色だけでなく、エラー文言、アイコン、概要、フォーカスも変わっています。このままでは色変更の効果を帰属できません。

一軸図では同じエラー条件、スクロール、フォーカス、DOM、文言を固定し、境界線の色だけを変えます。色差だけで伝えないためアイコンとテキストは両条件に同じ状態で置きます。視覚差分で変更範囲を確認します。ただし、弁別できたか、修正成功が増えたかは未測定です。

別の答え方

完成案としては、境界線だけを孤立評価せず、概要から項目への移動、読み上げ、修正後の回復まで比較します。

別題――方向性の異なる案

同じ文化施設の目的資料から、情報密度を保つ案、静かな余白を重視する案、展示画像が画面を覆う案が出ました。どれを選びますか。

答えの例

一つの数値で順位を付けません。初回来館者の経路確認、作品への期待、施設のアイデンティティ、更新担当者の運用、短いビューポートでの文字アクセスを別軸にします。展示画像案は没入を得る代わりに予定情報を遅らせ、密度案は探索を助ける代わりに余韻を減らす可能性があります。目的資料の優先順位と、捨ててもよい価値を関係者と記録して選びます。

別の答え方

一案へ収束せず、展覧会 Landing と来館案内で役割を分ける構成も考えられます。ただし運用負荷と一貫性を追加で評価します。

よくある考え方

最も評価点の高い案を採用します。

注意点

異なる尺度を一つの点数へ合算すると、誰の価値を優先し、何を捨てたかが隠れます。未合意の軸と影響を受ける当事者も残します。

よくある考え方

赤をもっと濃くすれば JND を超えるので見つかります。

注意点

どの刺激次元、基準、観察条件、判断基準で推定した JND かがありません。色の弁別とエラー理解、タスク成功も同じではありません。

セルフチェック

記録条件と変更台帳を残した
比較法が見せる差と隠す差を説明できる
一変数の診断比較と複合案の批評を分けた
JND を硬い境界やトークン公式として使っていない
一変数比較の後に目的と全体へ戻った

参考

Kalloniatis & Luu, “Psychophysics of Vision,” Webvision, NCBI Bookshelf — 閾、調整法、極限法、恒常法などの入口です。
Firestone et al. (2023), “A Shared Intuitive (Mis)understanding of Psychophysical Law…” — JND を誰にでも共通する硬い境界とみなす誤解を検討します。
W3C WAI, WCAG 2.2 SC 1.4.1 Use of Color — 色を唯一の伝達手段にしないための公式資料です。
W3C WAI, WCAG 2.2 SC 2.3.1 Three Flashes or Below Threshold — Blink を含む急速な表示変化の頻度、輝度差、赤、面積を監査する公式資料です。

第22章　ブラウザを動かして見る

Web は一枚の画像ではありません。画面幅、画面高、文字、言語、データ、通信、状態、利用者設定が変わるたび、同じ HTML でも見える関係が変わります。

本章では、完成スクリーンショットを眺める代わりにブラウザを動かします。ブレイクポイントの数字を先に選ばず、どの条件で、どの関係が、どう破綻するかを観察し、その後で CSS へ戻ります。

22.1 Web は一枚の画像ではない

幅 1280px の標準画面だけでは、短い高さ、キーボード表示、ズーム、長い名前、エラー、ローディングは見えません。デザインファイルのフレームは一条件の記録です。

観察には少なくともビューポート、画面密度、ズーム、文字サイズ、言語、フォント、データ、UI 状態、スクロール、フォーカス、入力方式を残します。すべてを同時に組み合わせるのでなく、リスクと利用状況から代表条件と境界条件を選びます。

22.2 幅と高さを連続的に変える

幅をデスクトップ、タブレット、モバイルの三点だけで確認すると、その間で起きる折返しや重なりを見落とします。幅を広い方から狭い方へ 1px ずつ動かし、最初に関係が変わる幅を記録します。自動で確認するなら 1px 刻み、手動なら変化付近を二分探索できます。

高さも動かします。ただし、レイアウト用のビューポートの高さを縮める試験と、実機のソフトウェアキーボード表示は同じではありません。キーボードが見える領域を縮めるか、レイアウト全体を変えるか、内容の上へ重なるかは環境で異なります。実機でフォーカス前後のレイアウト領域、見える領域、キーボードの入り込み、スクロールを別々に記録します。Cookie バナーやブラウザのツールバーも独立条件にします。

22.3 Breakpoint より先に、破綻条件を見る

Breakpoint を導く記録を示す図。 — 図 22-3　Breakpoint を導く記録

「768px だから二列を一列にする」のではなく、カードのタイトルが三行になり、操作ボタンが隣のカードと揃わなくなる条件を記録します。その破綻を避ける手段の一つとしてブレイクポイントを選びます。

破綻には重なり、切り抜かれ、意図しない横スクロール、読順の逆転、操作対象の縮小、階層の消失があります。データ表、地図、タイムラインなど二次元関係を保つための局所スクロールは、目的と代替を確認して評価します。

22.4 ズームと文字サイズを変える

ブラウザズーム、文字だけを大きくする設定、OS の表示倍率は同じでありません。ズームはページ全体の見かけと CSS pixel との関係を変え、文字だけの変更はフォントに強く作用します。それぞれ別条件で確認します。

WCAG 確認は達成基準ごとに分けます。SC 1.4.4 は文字を 200%まで拡大する条件、SC 1.4.10 は 320 CSS px 相当の幅で二方向スクロールを要求しない条件（例外あり）、SC 1.4.12 は指定された行高、段落後、字間、単語間を上書きする条件です。ブラウザ、手順、例外、判定を記録します。そのうえで適合値を超える負荷条件として、文字だけを大きくする設定や OS の表示倍率も別に試します。

文字間隔の上書きでは、固定高のボタン、切り詰めたラベル、絶対配置したバッジが破綻しやすい場所です。WCAG の数値は適合確認の条件であり、その値だけで十分なデザインを保証しません。

22.5 長い名前、長い URL、翻訳された文章

「田中」の代わりに長い複合姓、短い商品名の代わりに説明的な名称、英語の代わりにドイツ語や日本語を入れます。空白のない URL、長い数字、絵文字も対象言語に応じて用意します。右から左へ読む言語では、文字を差し込むだけでなく、文書またはコンポーネントへ正しい dir を設定し、数字・URL の混在、論理プロパティ、アイコン、DOM 順／見た目の順／フォーカス順を確認します。

Lorem ipsum は長さを見る一助ですが、語の区切り、意味、数字、固有名詞のリスクを再現しません。本番に近い匿名データと極端なデータを分けます。安易に省略記号で隠す前に、全文へ到達できるかを確認します。ホバーだけのツールチップやアクセシブルネームだけを万能解にしません。キーボード、タッチ、スクリーンリーダー、拡大時に知覚・操作でき、フォーカスを失わず閉じられる表示、詳細ページ、常時折返しなどを文脈に応じて選びます。

22.6 空、ローディング、エラー、満杯の状態

0 件、1 件、通常件数、上限件数を並べます。ローディングは短時間、長時間、部分成功、リトライを分けます。エラーも入力検証、権限、タイムアウト、競合で回復方法が違います。

状態を URL パラメータや状態切替で再現できるようにし、スクリーンショットだけでなく DOM、アクセシビリティツリー、ネットワーク、フォーカスを記録します。ランダムなデータに頼ると同じ破綻を再確認できません。

22.7 Flexbox、Grid、Intrinsic Web Design

画面を見てから実装へ戻ります。Item が折り返すなら、固定幅を増やす前に min-content、max-content、min-width:auto、Flex shrink、Grid track を確認します。

Intrinsic な設計は、内容と利用可能空間に応じてブラウザが配分できる余地を残す考え方です。しかし自動レイアウトへ任せれば意図が不要になるわけではありません。読順、最小幅、優先順位、例外を決めます。

22.8 `min()`、`max()`、`clamp()` と Container Queries

同じ Component の配置文脈を示す図。 — 図 22-7　同じ Component の配置文脈

clamp(minimum, preferred, maximum) は計算値を範囲内に保ちます。境界値の根拠は、文字、Container、読みやすさ、表現意図から決めます。関数名が自動的に正解を選ぶわけではありません。

Container query は、同じカードがメイン列とサイドバーへ置かれるような場合に、ビューポートでなくコンテナの inline size へ応答できます。クエリコンテナの選択、containment、入れ子のクエリ、フォールバックを確認します。Media query と併用して構いません。

22.9 一つのレスポンシブ手法を正解にしない

Media query、Container query、Flex wrap、Grid auto-fit、Fluid value、横スクロールにはそれぞれ役割があります。一つの技法を新しい／古いの序列へしません。

変化するものは何か、誰がどの環境で使うか、コンポーネントの配置文脈、ブラウザ対応、保守性、アクセシビリティから選びます。技法の名前でなく、破綻条件と副作用を比較します。

22.10 問い――最初に壊れるのは、どこで、なぜか

問い

商品カードのグリッドを 1280px から 320px まで縮めます。どこで何が最初に壊れますか。

答えの例

長い日本語の商品名を入れ、Chrome のバージョン、ズーム 100%、フォント読み込み完了を記録して観察します。この教材用の例では、コンテナの inline size が 286px 未満になると価格と在庫バッジの境界が交差するようにしています。286px は一般的な閾値でも利用者測定値でもありません。ビューポート幅はコンポーネントの配置で変わるため、原因条件をコンテナ幅で記録します。

価格を省略せず、バッジ文言、フォント、データを固定し、見出し行を折返し可能にします。286px 付近を 1px ずつ動かし、重なりが消え、DOM 順とフォーカス順が変わらないことを確認します。別仮説は長いバッジ文言と min-width:auto です。

別の答え方

カードを一列へ変えるより、サイドバー配置ではコンパクト版を使う方が目的に合うかもしれません。Container query 案と内容短縮案を別々に比較します。

別題――幅以外の破綻

幅 390px では正常なチェックアウト画面で、ソフトウェアキーボードを表示すると送信ボタンへ到達できないという報告があります。何を記録しますか。

答えの例

実機とブラウザバージョン、入力欄、フォーカス前後のレイアウト領域と見える領域、キーボードが重なるのか縮めるのか、スクロール位置、固定フッターの矩形、セーフエリアを記録します。単にビューポートの高さをキーボード分だけ減らしたデスクトップ上の再現は別の証拠です。フッター固定を外す案、dvh を使う案、フォーカス時だけスクロール余地を作る案を一つずつ比較し、ボタン到達、内容の遮蔽、フォーカス移動、キーボード再表示を確認します。

よくある考え方

高さを 100vh から 100dvh へ変えれば直ります。

注意点

キーボードの挙動、固定要素、スクロールコンテナ、ブラウザ差を確認しておらず、一つの単位を万能解にしています。

よくある考え方

768px にブレイクポイントを追加します。

注意点

破綻したコンポーネントの実寸、内容、状態との関係がなく、別配置では同じブレイクポイントが効かない可能性があります。

セルフチェック

幅と高さを連続的に変えた
ズーム、文字サイズ、文字間隔を別条件で見た
空状態から満杯、ローディング、エラーを再現した
ビューポート幅でなく破綻した関係を記録した
CSS 技法を唯一の正解にしていない

参考

W3C, CSS Containment Module Level 3, §4 — Container query の正式仕様です。
W3C, CSS Values and Units Module Level 4, §10.2 — min()、max()、clamp() の定義です。
W3C, WCAG 2.2, SC 1.4.4、1.4.10、1.4.12 — Resize text、Reflow、Text spacing の適合条件です。

第23章　DevTools で答え合わせする

画面の距離を見てすぐ DevTools を開くと、表示された数字を答えだと思いやすくなります。本章では先に予測し、その後で値と構造を確かめます。

DevTools は CSS の修正器だけではありません。画面から生まれた問いを、ボックスモデル、カスケード、レイアウト、状態、レンダリング、アクセシビリティツリーへ接続する観察道具です。同時に、人がどう感じ、使うかを直接測る道具ではありません。

23.1 値を見る前に予想する

「カード間は 24px、内側は 16px に見える」「タイトルの行高はフォントサイズの 1.4 倍ほど」と、対象、属性、概算、確信度を書きます。その後で DevTools を開きます。

外れても失敗ではありません。影を間隔と見誤った、透明な境界線があった、フォント指標が違った、サブグリッドで線が共有されたなど、見るレンズを更新できます。

23.2 ボックスモデルで距離の出所を探す

見えている空間は margin、padding、gap、行ボックス、トラックサイズ、配置から生じます。二要素間の距離を、一方の margin-bottom だけだと決めつけません。

境界矩形、ボックスモデル、親レイアウト、疑似要素を順に見ます。マージンの相殺、box-sizing、論理プロパティ、transform も記録します。重ね表示の色だけを覚えるのでなく、どの箱の辺と辺の間を測ったかを書きます。

23.3 Computed Style で最終結果を見る

Authored から Computed へを示す図。 — 図 23-3　Authored から Computed へ

Styles ペインには適用、継承、上書き、無効な宣言が並びます。Chrome の Computed ペインは、カスケード後のプロパティを探すブラウザ固有 UI です。どのルールとカスタムプロパティから来たかを展開して戻ります。

CSS には specified、computed、used、actual value という段階があります。さらに CSSOM の getComputedStyle() は互換性のためプロパティにより computed または used value を返す「resolved value」です。Chrome の Computed ペインという名称を CSS 仕様上の computed value と自動的に同一視しません。パーセント値や auto、フォント、transform、デバイス倍率を含む幾何情報、人の見えとも別です。

23.4 Grid／Flex の重ね表示で線と間隔を見る

Layout Overlayを示す図。 — 図 23-4　Layout Overlay

Chrome DevTools では Grid の重ね表示でトラック、線番号、間隔を、Flex の重ね表示で主軸／交差軸、項目間の配分を見られます。見えない線を画面へ重ねると、揃いの由来を追いやすくなります。他ブラウザでは名称、表示、機能が異なるため、DevTools 一般の必須機能とは書きません。

重ね表示は説明用の真実の層ではなく、特定ブラウザバージョンの診断表示です。スクリーンショットへブラウザ、バージョン、設定、選択ノードを添え、色だけで線を区別しません。

23.5 CSS を一つ消し、値を一つ変える

Local interventionを示す図。 — 図 23-5　Local intervention

宣言のチェックを一つ外し、画面のどこまで変わるかを見ます。gap を変えるならテキスト、データ、ビューポート、状態を固定し、変更前後の算出済みスタイルとスクリーンショットを保存します。

一つのプロパティでも複数の関係が変わります。line-height は高さ、ベースライン、折返し、隣要素の位置へ影響します。通常の一時的なローカル編集はページ再読込で失われ、テストも通っていません。ただし Overrides、Workspaces、IDE 連携など保存先を構成した場合はソースまたはローカルコピーへ残り得ます。保存構成と書込先を確認します。

23.6 状態を強制する

Forced pseudo-state と本物の状態を示す図。 — 図 23-6　Forced pseudo-state と本物の状態

:hover、:focus、:focus-visible、:active を強制し、通常時とのスタイル差を確認できます。ただし、疑似クラスを強制することと、キーボードで実際にフォーカスが移動することは同じではありません。

無効、ローディング、エラー、ネットワーク失敗はアプリケーション状態や通信条件で再現します。CSS クラスを付けただけではイベント、ARIA、操作可能性、サーバー結果まで再現できません。

23.7 レンダリングとアクセシビリティツリーも見る

Rendering パネルで描画、レイアウトシフト、エミュレーション等を調べ、Network／Performance で時間変化を確認します。Chrome の Accessibility ペインでは役割、名前、状態、アクセシビリティツリー上の位置を見ます。Source Order Viewer、DOM ソース順、CSS による見た目の順序、キーボードフォーカス順、アクセシビリティツリー順、スクリーンリーダーの読み上げ／ナビゲーション順は別物です。

ツリーに正しい役割が見えることは重要ですが、スクリーンリーダーで理解・操作できた証明ではありません。キーボードと実支援技術でも確認し、人のタスクは第24章で観察します。

23.8 値からデザインを決めない

「間隔が 18px だから 16px へ丸める」「トークンにないので削除する」と、値だけで決めません。18px が画像の光学補正、フォント指標、ブランドリズム、外部ウィジェットとの整合から生じたかもしれません。

値の由来、役割、反復、例外、変更の副作用を調べます。トークンは判断を共有する道具で、画面より先に正解を出す表ではありません。

23.9 DevTools で分からないこと

DevTools では、利用者がどこで迷うか、文言をどう理解するか、ブランドをどう受け取るか、長期利用で学習するかを直接知れません。アクセシビリティツリーだけで読み上げ体験も決まりません。

実装上の事実、画面上の幾何情報、ブラウザ内部の診断、行動、発言、作者意図を別根拠として残します。道具の限界を知ることも、答え合わせの一部です。

23.10 問い――見えている差は、どの値から生まれたか

問い

フォームの二つのまとまりの間が 32px に見えます。どこをどう調べますか。

答えの例

以下は実測結果でなく、教材用の基準例の記入例です。ラベル、操作部品、まとまりのラッパー、親コンテナを安定したセレクターで選び、境界ボックス間を幾何情報で測る計画を立てます。見かけの 32px という予測が、.field 内 gap 12px、親 .form-fields の row-gap:20px、行ボックスのどれに対応するかを別記録で確認します。

親 row-gap だけを 20px から 28px へ変え、DOM、フォント、テキスト、ビューポートを固定します。基準実装後、まとまり間の境界ボックス差が期待どおり 8px 増えたかを確認します。幾何情報も読みやすさも現時点では未測定です。

別の答え方

距離ではなく、境界線と背景の共通領域がまとまりを作っている可能性もあります。間隔だけを変える前に背景を一時無効化した比較を別に作ります。

別題――状態とアクセシビリティツリー

送信ボタンへ aria-busy="true" を付け、DevTools に状態が表示されました。ローディング時のアクセシビリティは確認できたと言えますか。

答えの例

DOM 属性、算出されたアクセシブルな状態、アクセシビリティツリーのスナップショットは確認できます。しかしボタンがキーボードから操作可能か、状態がいつ読み上げられるか、二重送信を防ぐか、完了・エラーへ遷移するかは別根拠です。アプリケーションの画面条件で受付、処理、成功、失敗を再現し、キーボード操作、対象スクリーンリーダー／ブラウザの発話、イベント／ネットワークログを時系列で記録します。

よくある考え方

アクセシビリティツリーに正しく出たので対応完了です。

注意点

ブラウザからプラットフォーム API への公開候補を、支援技術による提示、操作、理解、タスク成功と同一視しています。

よくある考え方

Computed に 32px と出ているので、Margin は 32px です。

注意点

どの要素のどのプロパティか、箱の辺、親レイアウト、行ボックス、transform がありません。算出値と画面上の距離も同一ではありません。

DevTools で分かる範囲を示す図。 — 図 23-8　DevTools で分かる範囲

セルフチェック

値を見る前に対象、概算、確信度を書いた
Styles、Computed、幾何情報、重ね表示を区別した
ローカル編集とソース変更を区別した
強制状態と実際の操作状態を区別した
アクセシビリティツリーと支援技術の利用を同一視しなかった
値から目的と全体へ戻った

参考

Chrome for Developers, “CSS features reference” — Styles、Computed、Grid／Flex tooling の公式資料です。
Chrome for Developers, “Accessibility features reference” — アクセシビリティツリー、ARIA、ソース順と限界の公式資料です。
Chrome for Developers, “Inspect mode” — 要素の寸法、色、フォント、アクセシビリティ情報を見る入口です。

第24章　人間を見て確かめる

デザイナーが感じた違和感は、丁寧に言語化しても仮説です。人が実際に使う場面を見ると、予想した場所では止まらず、別の言葉で迷い、意図しなかった回復方法を見つけることがあります。

本章では、完成度を評価するためではなく改善点を見つけるための小さなユーザビリティテストを計画し、行動、発言、システム上の出来事を分けて記録します。一人の観察を大切にしながら、一人を「ユーザー全体」へ一般化しない方法を学びます。

24.1 デザイナーの違和感は、まだ仮説である

「カテゴリーの重複で迷うはず」「ボタンが小さくて押せないはず」は、観察計画を作る候補です。参加者へその言葉を伝えると、同じ問題を探させてしまいます。

仮説、反証条件、代替仮説を事前に残し、セッション中は起きたことを記録します。予想外の行動をエラーとして片付けず、タスク、プロトタイプ、説明、環境のどこに由来するかを後で考えます。

24.2 誰に、何をしてもらうか

「一般ユーザー」ではなく、利用経験、業務知識、使用機器、支援技術、言語など、仮説に関係する募集条件を定めます。人口統計だけで代表性を語りません。

タスクは「この青いボタンを押してください」でなく、目標と必要な文脈を示します。「来週火曜に最も早く届く商品を選び、購入直前まで進んでください」のように、UI の言葉を答えとして含めません。成功条件、開始、終了、中止、ヘルプを事前に決めます。

24.3 説明しない、教えない、助ける条件を決める

進行役は沈黙を恐れて答えを教えないようにします。ただし「絶対に助けない」ことも倫理的とは限りません。苦痛、危険、個人データの誤送信、時間超過では止めます。

介入を、沈黙、誘導しない促し、タスク再提示、ヒント、答え、セッション中止の段階に分け、時刻と理由を記録します。ヘルプ後の完了は、独力完了と別の結果にします。

24.4 止まる、戻る、間違える、読み飛ばす

クリックだけでなく、停止、往復、スクロール、読み飛ばし、修正、別経路、ヘルプ要求を時系列で記録します。「迷った」は解釈です。まず「カテゴリー A→B→A を選択し、12 秒操作がなかった」と書きます。

停止時間の長さだけで困難を決めません。読んでいる、考えている、休んでいる、通信を待つ可能性があります。質問時点と発言原文を別に残します。

24.5 「使いやすかった」という発言をどう扱うか

セッション後の「使いやすかった」は大切な報告ですが、タスク中の行動を上書きしません。礼儀、期待、比較対象、質問の仕方が影響する可能性があります。

「どの場面でそう感じましたか」「予想と違った場所はありますか」と具体例を聞きます。発言原文、質問文、時点を残し、完了、時間、エラーと別の根拠にします。

24.6 思考発話法の利点と干渉

思考発話法は、参加者にタスク中の考えを声に出してもらう方法です。語の理解、予想、選択理由の手掛かりを得られます。一方、話すことが注意、速度、戦略を変えます。

発話を求める条件を手順に明記します。成績を比較したい場合は、声を出さない条件や事後インタビューを検討し、思考発話法の時間を無発話条件の時間と無条件に比較しません。進行役の「なぜ？」も後付け説明を促す可能性があります。

24.7 完了率、時間、エラーと観察メモ

完了率には分母と成功定義、時間には開始／終了、エラーには分類と回復を付けます。システム側の失敗、進行役によるヘルプ、参加者中止、欠測を同じ失敗へ押し込みません。

観察メモは、数値が生まれた過程を説明します。少数セッションの割合を精密な母集団率として報告せず、「5 試行中 3 試行で観察した」と実数を併記します。発見の重大さは頻度だけでなくリスクと回復可能性も見ます。

24.8 一人を見る。一人で一般化しない

一人のセッションでも、実際の経路、言葉、環境について多くを学べます。その人の困難を「例外」として消しません。同時に「ユーザーは皆こうする」と書きません。

誰に、どのタスクと条件で起きたかを書き、次の参加者で同じ仮説と別仮説を確かめます。サンプル数は研究目的、利用者の多様性、リスク、期待する推定精度、資源で決めます。「5 人なら十分」という普遍ルールは置きません。

24.9 倫理、同意、録画、個人情報

同意とデータライフサイクルを示す図。 — 図 24-7　同意とデータライフサイクル

目的、実施者、所要時間、録画・音声・画面・イベントの取得、利用範囲、閲覧者、保存期間、撤回、中止、謝礼、問い合わせ先を、参加前に理解できる言葉で伝えます。媒体ごとに同意を分けます。

本番アカウントや実際の個人データを使わせず、架空データを用意します。参加者 ID への置換は仮名化であり、匿名化ではありません。顔、声、画面、固有の支援技術、業務内容、時刻などの準識別子から再識別され得ます。募集連絡先、同意、謝礼、調査データを別の保管場所・別権限にし、必要最小限だけ取得します。

撤回用の識別番号は、連絡先と調査 ID を長期に結ぶ対応表を避ける一案ですが、万能ではありません。元データが削除可能な期間と、匿名化集計、バックアップ、既に共有・公開した引用など個別削除できない段階を同意時に具体的に伝えます。「いつでもすべて削除できる」と約束しません。

雇用・教育関係など断りにくい募集では、評価者を募集担当者にしない、参加しなくても不利益がない、謝礼を過度な誘因にしない等の対策を取ります。仮説を先に教えないことは、目的やリスクを偽ることと同じではありません。必要な非開示は本当に必要か、最小リスクか、直接質問へ真実を答えられるか、セッション後の事後説明とデータ再同意が必要かを事前審査します。

24.10 問い――何を見たら、この仮説を見直すか

問い

「カテゴリーの重複が商品探索を難しくする」という仮説を、どう観察しますか。

答えの例

対象業務に近い参加者へ、商品名を直接示さない探索タスクを行ってもらいます。同じ参加者が元の画面と重複を除いたプロトタイプを行う場合、条件順とタスク項目を割り付けて釣り合わせ、学習と疲労を記録します。参加者内反復を独立な人数として扱わず、分析単位を事前に決めます。成功、開始／終了、カテゴリー選択イベント、A→B→A の往復、検索利用、ヘルプを定義します。思考発話は探索戦略を変える可能性があるため、主な成績比較は無発話条件で行い、終了後に事後インタビューを行います。

重複を除いても往復が変わらない、発見が悪化する、またはラベル理解で止まるなら、重複だけの説明を弱めます。操作成立、タスク難易度、学習、順序も先に点検します。

別の答え方

重複は複数のメンタルモデルを支えるかもしれません。最短時間だけでなく、参加者が使った業務用語と分類理由を聞き、作者の情報設計資料と分けて解釈します。

よくある考え方

5 人に見せて、使いやすいか聞きます。

注意点

募集条件、タスク、成功、質問、条件、反証、倫理がなく、人数を万能ルールにしています。

別題――倫理判断

直属の部下へ、勤務時間中の録画テスト参加を上長本人が依頼しようとしています。どうしますか。

答えの例

上長を募集、同意取得、個別録画閲覧から外します。参加・不参加が評価へ影響しないこと、撤回範囲、謝礼、閲覧者を明示し、可能なら独立した募集担当者と外部参加者を使います。それでも自発性を確保できない、リスクに比べ必要性が低い場合は実施しません。

別の答え方

録画をやめれば十分とは限りません。観察メモやイベントからも個人が特定され、権力関係は残ります。集団ワークショップなど別方法でも同じ問題を点検します。

よくある考え方

同意書へ署名してもらえば問題ありません。

注意点

署名の有無だけで、理解、自発性、撤回可能性、過度な誘因、選択の公正さは保証されません。

セルフチェック

参加者条件と現実的タスクを定義した
ヘルプ条件と中止条件を決めた
行動、発言、システムイベントを分けた
思考発話の干渉を扱った
分母、開始／終了、エラー分類を決めた
同意、撤回、保存、削除を実施前に決めた

参考

ISO 9241-11:2018 — ユーザビリティを利用者、目標、文脈と利用結果で捉える規格です。
GOV.UK Service Manual, “Using moderated usability testing” — タスク、議論ガイド、個人データ、支援技術を含む実務導線です。
GOV.UK Service Manual, “Usability benchmarking a website or whole service” — タスク成功、時間等を測る入口です。
NISTIR 7741 — 形成的／総括的な調査と思考発話の成績干渉を考える資料です。

第25章　作って、見て、また作る

最初の案だけで、まだ分からない全条件に正しい画面を作れないことは、制作の失敗ではありません。作る前には見えなかった内容、状態、利用者、技術条件が、作って動かすことで初めて見えるからです。既に分かっている法令、安全、プライバシー、アクセシビリティの非交渉要件まで「試してから考える」という意味ではありません。

本章では、本書で学んだ観察、概念、実装、比較、利用者検証を、一度きりの手順ではなく反復可能な制作習慣へまとめます。反復は必ず円形に一周するわけではありません。途中で前へ戻り、別の仮説へ枝分かれし、十分な根拠が得られたら止めることも含みます。

読み始める前の確認

序章で観察メモを残した人は、この先の著者例を読む前に 読後の観察メモを開いてください。序章のメモはまだ見ずに、同じ画面をもう一度 30 秒だけ見て、最初に目に入ったものと気になった場所を書きます。その後で、時間を気にせず観察を広げます。

序章で観察メモを残していない人は、最初と最後の比較はできません。その場合は、単独観察メモを使い、別の初見画面を読後の観察練習として見ます。ここで書かなかった記録を、後から自己 Before／After として補うことはしません。

25.1 最初から正解を作れないのは、失敗ではない

企画時には短い商品名しかなくても、本番では長い名前、在庫切れ、通信遅延、権限差、支援技術による操作が現れます。最初の案は、未知を発見するための外在化でもあります。

反復を「最初のデザインが下手だった証拠」と捉えると、作者は案を守り、都合の悪い観察を例外にしやすくなります。案を暫定的な仮説と捉えれば、変更は敗北ではなく学習になります。ただし、無期限に作り直すことも目的ではありません。重大なリスク、未解決の不確実性、変更コスト、公開期限を見て、次に何を確かめる価値があるかを選びます。

25.2 Best Practice は文脈つきの候補である

Best Practice と Contextを示す図。 — 図 25-2　Best Practice と Context

「選択肢を減らす」「一貫させる」「動きを抑える」は、出発点にはなりますが、目的を離れた正解ではありません。救急時に選択肢を隠せば危険になり、意図された警告まで一貫させれば区別できず、状態変化を伝える動きをすべて消せば結果を見失うことがあります。

候補を採用する前に、誰が、どの状況で、何を達成し、失敗すると何が起こるかを記します。理論やガイドラインは判断の根拠の一部です。ブランド、内容、アクセシビリティ、プライバシー、性能、実装・運用コスト、法令、安全性も同じ表に置きます。すべてを一つの点数へ潰さず、譲れない条件とトレードオフを残します。

25.3 目的と利用状況へ戻る

局所的な Before／After で整って見えても、タスク全体を悪化させることがあります。ボタンを大きくした結果、重要な比較表が画面外へ押し出されるかもしれません。入力を段階化した結果、全体を確認したい熟練者の往復が増えるかもしれません。

変更ごとに次を確認します。

対象となる利用者と利用状況は何か。
支える目標と、守るべき表現意図は何か。
成功、失敗、回復を何で観察するか。
どの制約を固定し、どの制約を交渉できるか。
改善が別の人、状態、入力方法へ移したコストはないか。

「ユーザーのため」と作者が代弁するだけでは足りません。観察した行動、発言、実装状態、組織上の要件を出所つきで分けます。

25.4 作る―見る―気づく―言葉にする

まず、考えられる最小の形を作ります。完成品に限らず、紙、静止画、HTML、本番に近い仮データなど、確かめたい問いに必要な忠実度を選びます。

次に、第19章のように、読む前の塊、距離、揃い、類同、強さ、状態、例外を見ます。「ダサい」「分かりにくい」と評価する前に、見えた差を記述します。

観察: 同じ完了操作を持つ三つのボタンのうち、二つは右端、一つはカード左下にある。

気づきを早く修正案へ変えず、スクリーンショット、表示幅、内容、時刻、状態を残します。言葉にすることで、後の自分や他者が同じ対象を確認できます。

25.5 名前を知る―疑う―仮説を立てる

観察に「一貫性」「近接」「再認」などの名前を接続すると、見落としていた比較軸や先行研究を探せます。しかし名前は原因の確定ではありません。

私は、三つ目のボタンだけ位置が異なることを観察した。反復した位置から次の操作を予測している人は、三つ目を見つけるまで余分な探索をする可能性がある。位置を揃えると最初の到達が早まるのではないか。

代替仮説として、ラベルが異なる、カードの見出しが弱い、画面外にある、キーボードのフォーカス順が違う、三つ目だけ権限がない、などを残します。「位置を揃えても探索経路が変わらない」は仮説を弱める結果です。

25.6 変える―比べる―人間を見る

第21章のように比較したい差を一つに絞り、第 22・23 章のようにブラウザと DevTools で状態・幅・内容・実装を点検します。その後、第24章のように、人の行動で仮説を確かめます。

すべての問いに利用者テストが必要なわけではありません。CSS の重複、フォーカス不可、表示名の欠落は実装監査で確かめられます。業務用語の理解、予測、回復経路は人を見なければ分からないことがあります。証拠源を問いに合わせます。

比較後は「改善した」で閉じません。固定条件、変えた軸、観察単位、分母、反証、悪化した側面を記録します。結果が曖昧なら、仮説を保持する、別仮説を調べる、計測を直す、変更を戻す、保留する、のいずれも正当な判断です。

25.7 反復の記録を残す

記録がなければ、同じ議論を繰り返し、過去の制約が永久のルールへ変わります。短い判断記録に、少なくとも次を残します。

欄	記録すること
文脈	対象、タスク、状態、端末、日時、版、入口、飛ばした段階と理由
観察	評価を混ぜない事実と、確認元へのリンク
仮説	主仮説、代替仮説、反証条件
変更	変えた軸、固定した条件、実装差分
結果	行動、発言、計測、技術検査を分離
判断	採用、棄却、保留、非公開、機能削除、戻す条件と理由・決定権者
非交渉条件	法令、安全、プライバシー、アクセシビリティ、承認、公開条件
未解決点	未解決点、一般化しない範囲、負担・再学習コスト
次の対応	所有者、期限、監視、再検討・取り下げ条件、再検討日

判断記録は結論を正当化する装飾でも、担当者の評価表でもありません。予想と違った結果、欠測、途中で変わった条件、少数意見も残します。閲覧者、保持期間、変更履歴を定めます。個人データは複製せず、必要最小限の権限制御された場所へ参照し、その参照先が削除された状態も記録します。

一件を最後まで通す――送信後に変化がない

以下は手順を示す著者作成の例であり、実参加者から得た結果ではありません。

段階	記録
対象	序章の申請画面、通信を遅らせた状態、送信前の状態
観察	送信後もボタンの見た目、文言、見えるステータス、フォーカス表示に差がない。操作できるかはまだ未確認
仮説	受付が伝わっていない／クリックイベントが発火していない／応答が失われ結果不明／支援技術へ状態が伝わっていない
変更	送信中に見える領域を新設し、「送信しています」と表示する。通信遅延、ボタン、読み上げ用の通知、内容、表示幅は固定する
技術確認	イベント、ネットワーク、DOM、フォーカス、アクセシビリティツリー、二重送信防止を確認する
人の観察	必要な場合のみ、同意範囲と記録の扱いを定め、最初の再押下、状態説明、回復を観察する
結果の分岐	再押下が減る／見た目だけ改善する／イベント未発火が見つかる／回復が悪化する、のいずれも記録する
判断	公開前に譲れない条件を満たさなければ公開しない。結果が混ざるなら保留または限定公開、重大な悪化なら戻す
未確認	スクリーンリーダー条件、低速回線、再訪時の理解、運用後の監視

利用者観察を選ぶ場合、同意、記録媒体、記録の保持期間、撤回できる範囲、組織内の確認を第24章の手順へ接続します。速度のために参加者保護を省略しません。利用者や当事者が、目的設定、リスク判断、結果解釈へ関わることが適切な案件もあります。

25.8 序章と同じ画面を、もう一度見る

同じ画面の Before／After 観察を示す図。 — 図 25-7　同じ画面の Before／After 観察

本書の最初に見た架空の申請画面を、もう一度見ます。序章で残した観察メモと、この章で書いた読後の観察メモを並べます。著者の例を読んだ後で書き足すと比較にならないため、読後の観察メモは本章冒頭で先に書いておきます。

これは教材効果を因果的に証明する実験ではなく、自分の記録の変化を見る内省課題です。画面を覚えている影響もあります。序章の観察メモがない場合は、Before／After とは呼ばず、未見の別画面を使う練習へ切り替えます。

最初の記録が「余白が変」「どこを押すか分かりにくい」だったとします。読了後には、次のような観察になるかもしれません。

ラベルと対応する入力欄より、入力欄と次のラベルの距離が近い。
主要操作と補助リンクの色・面積・位置が同程度で、最初の視覚的優先を分けにくい。
送信後の受付、処理中、結果不明を示す見える状態が画面にない。支援技術へ状態が伝わるかは画面観察だけでは不明で、実装監査が必要である。
前画面で選んだ権限名を再生しなければ、現在の選択を照合できない。

これは画面の唯一の診断ではありません。観察から仮説、必要な証拠、確かめ方へ進めるようになったことを比べます。

25.9 増えた言葉ではなく、変わった観察を確かめる

専門用語の数で上達を測ると、Concept Dropping を促します。Before／After を次の観点で読みます。

具体性: どの要素間の、どの差かを指せるか。
証拠の境界: 見た事実、解釈、評価を分けたか。
複数性: 一つの違和感に代替仮説を残したか。
検証可能性: 何を変え、何を見れば仮説を弱められるか。

用語を使わなくても、この四点が増えていれば目は変わっています。逆に用語が多くても、「認知負荷が高いから悪い」で止まれば観察は進んでいません。

25.10 共通の診断結果を置かない。書き方の例は置く

同じ画面でも、利用者、タスク、状態、画面幅、業務リスクが違えば重要な問題は変わります。共通の診断結果を置くと、読者は画面を見る代わりに著者の語を探します。そこで、結論の正解ではなく、観察と推論を分ける書き方の一例を示します。

ただし「何でもあり」ではありません。観察対象を指せるか、証拠と推論を分けたか、別説明を検討したか、確かめ方が対象に合うかは相互に検討できます。答えを一つに固定せず、推論の質を話し合います。

問い

序章と同じ画面を見て、一つの違和感を観察、仮説、代替仮説、変更、反証条件へ展開してください。

答えの例

観察は「スクリーンショットでは送信ボタンを押した後、ボタンの見た目と文言、見えるステータス、フォーカス表示に変化がない」です。操作できるか、支援技術へ状態が伝わるかはまだ不明です。主仮説は送信中状態を検出できず再送する可能性、代替仮説はクリックイベント自体が発火していない、応答が失われ結果不明、支援技術へステータスが通知されない、です。

まずネットワーク、イベント、DOM、アクセシビリティツリーを確認します。送信直後にステータス領域を新設し、「送信しています」と表示する条件を作ります。ボタン状態と支援技術への通知は固定したまま、同じ遅延条件で比べます。再押下が変わらずイベント未発火なら、フィードバック不足という仮説は弱まります。公開候補では、支援技術への通知、二重送信防止、結果不明からの回復を追加で確かめます。

別の答え方

送信より前の入力グループに注目し、距離、見出し、エラー関連付けの複合仮説を立てても構いません。その場合は送信後状態を直す答えと競争させず、タスクのどの段階を扱うかを明記します。

よくある考え方

近接の原則とフィードバックを適用すればよい。

注意点

原則名だけでは、どこで何が起き、誰のどのタスクをどう支えるかがありません。複数の変更を同時に行うと、何が結果へ寄与したかも分かりません。

25.11 また作る

本書の流れは次のように書けます。

作る → 見る → 気づく → 言葉にする → 名前を知る → 疑う → 仮説を立てる → 変える → 比べる → 人間を見る → また作る

しかし実務では、どこから始めても構いません。比較中に観察記述へ戻り、人を見る前に実装不具合を直し、リスクが高ければ公開を止め、十分なら次の問いへ移ります。法令、安全、プライバシー、重大なアクセシビリティ破綻は公開前に必ず確認します。公開した場合も運用指標、問い合わせ、障害、支援技術での利用を監視し、再検討や取り下げの条件に達したら再び問いを開きます。矢印は命令ではなく、現在地を共有する地図です。

Web デザインを見る目とは、正解を知ることではありません。画面で起きていることに気づき、考えるための言葉を持ち、その言葉を疑い、人間と実装を見ながら確かめ続けることです。次に作る画面が、このループの続きになります。

セルフチェック

最初の案を正解でなく検証可能な案として扱った
ベストプラクティスの対象、目的、制約を記した
観察、解釈、評価、実装事実を分けた
主仮説に代替仮説と反証条件を付けた
問いに合う証拠源を選んだ
変えた軸と固定条件を記録した
改善と同時に悪化・移転したコストを確認した
判断記録に未解決点と戻す条件を残した
用語数でなく観察の変化を比べた
十分な根拠で止める条件と次の問いを決めた
人を対象にするとき倫理・プライバシー確認を通した
公開後の監視と、再検討・取り下げの条件を決めた
自己比較を教材効果の実証と呼ばなかった

参考

ISO 9241-210:2019, Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systems, https://www.iso.org/standard/77520.html — Human-centred design の活動と反復を確認する公式規格。規格本文は有料で、本書は特定の直線工程として単純化しない。
Donald A. Schön, The Reflective Practitioner, Basic Books, 1983 — 行為の中の省察を考える古典。Design 手順のチェックリストではなく、専門実践の認識論として読む。
Horst W. J. Rittel and Melvin M. Webber, “Dilemmas in a General Theory of Planning,” Policy Sciences 4, 1973, pp. 155–169, https://doi.org/10.1007/BF01405730 — 問題設定と解決が相互に変化する課題の入口。すべての UI 問題を同じ種類の Wicked Problem と呼ばない。
Thomas P. Moran and John M. Carroll (eds.), Design Rationale: Concepts, Techniques, and Use, Lawrence Erlbaum Associates, 1996 — Design 判断と根拠を残す方法を深く調べる資料。
W3C, Web Content Accessibility Guidelines (WCAG) 2.2, https://www.w3.org/TR/WCAG22/ — アクセシビリティを任意のトレードオフへ落とさず、適用要件と検証方法を確認する一次資料。

第 IV 部統合ケース　違和感を、公開判断まで運ぶ

第 19〜25 章では、観察、仮説、比較、ブラウザ、DevTools、人の行動、反復を学びました。第25章が読者自身の制作習慣と内省を扱ったのに対し、本ケースは、別担当者へ渡せる根拠資料を作る演習です。架空の権限申請サービス「Michi Access」にある一つの違和感を、思いつきの修正で閉じず、公開・保留・取り消しの判断まで運びます。

題材は「申請ボタンを押した後、画面が変わらない」です。以下はすべて著者が作成した画面条件と未実施の観察計画であり、実利用者の結果ではありません。

1　記録条件を固定する

trial_id=P4-T01、ビューポート 1280×800、ズーム 100%、標準申請データ、通信遅延 4 秒、送信前状態を残します。スクリーンショットだけでなく、DOM、算出済みスタイル、アクセシビリティツリー、通信条件、コンポーネント版も記録対象です。

最初の違和感は「押せたか分からない」でした。これは評価です。観察へ書き換えます。

送信前と送信後 500ms の画面記録を比べると、ボタンの見た目とラベル、見える状態表示、フォーカス表示に差がない。

ボタンが実際に操作可能か、クリックイベントの発火、サーバー受付、支援技術への通知は画面記録だけでは不明です。

2　複数仮説と反証を残す

仮説	必要な根拠	弱まる結果
見えるフィードバック不足で再押下する	同じ遅延での最初の再押下、状態説明	テキスト追加後も変化なし
クリックイベントが発火しない	イベントリスナー、コンソール、イベントログ	イベントとリクエストが毎回記録される
応答が失われ、結果不明になる	リクエスト／操作 ID、サーバーログ	クライアントとサーバーが成功へ同期する
支援技術への状態通知が不足する	アクセシビリティツリー、支援技術での通知	適切な名前／役割／状態と通知を確認
ラベルが送信結果を予測させない	行動後発言、別ラベル比較	ラベル変更で理解が変わらない

「フィードバックの問題」と名前を付けても、五つの仮説は区別されません。

3　一軸比較を作る

比較 ID P4-C01-DISPATCH-VISIBLE では、「クライアントから送信中の見える表示」という一つの実験要因を操作します。その実装差は、可視領域の新設と「送信しています」というテキストの追加です。これはサーバー受付済みを意味しません。ボタンの操作可能性、スピナー、色、位置、支援技術への通知、通信遅延、内容は元の画面と同じく固定します。

これは「処理中の可視差」という仮説だけを見る診断用の差分で、公開候補ではありません。完成案 P4-SM01 では、未送信、クライアントから送信中、サーバー受付済み、処理中、成功、失敗、結果不明、再照会、回復を別状態にします。見えるテキスト、ボタン操作、支援技術への状態通知、二重送信防止を状態ごとに同期し、診断用の差分とは別 ID で評価します。

4　ブラウザを動かす

320、768、1280px、200% ズーム、長い申請名、エラー、オフライン、権限差を一条件ずつ変えます。ブレークポイントの一覧を消化するのでなく、状態表示がボタンから離れる、再配置で順序が変わる、長文が操作を押し出す地点を記録します。

横幅と通信条件を同時に変えた記録から原因を決めません。再現条件を表へ残し、壊れなかった条件も記録します。

5　DevTools で実装を監査する

見る前に予想します。「ボタンはフォーム送信、送信中状態はコンポーネント内で所有、状態表示は DOM に存在するが空」と仮説化します。その後、Elements、Computed、イベント、通信、アクセシビリティツリーで答え合わせします。

著者が定義した元の画面条件では、ボタンはクリック処理からリクエストを送る一方、送信中状態を持たず、状態表示領域は DOM にありません。これは実製品を DevTools で測った結果ではありません。診断用の差分は新しい可視領域を挿入します。CSS だけで直そうとせず、クライアント／サーバー／アクセシビリティの状態所有者を表にします。サーバーログは DevTools で直接観察したものとせず、別の権限・出所を持つ根拠として参照します。

6　人を対象にする前の確認条件

イベント未発火、DOM 欠落、状態機械の矛盾は、まず実装監査と自動テストで確かめられます。状態の理解、再押下、結果不明からの回復は、人の行動を見る価値があります。

人を対象にする場合は、目的、募集条件、タスク、成功・中止、介入、同意媒体、データ保持、撤回、権力関係、組織審査を先に通します。本ケースでは値が未確定なので、収集許可は未確定です。実アカウントや本番環境へ接続せず、障害注入は架空環境だけで行います。

観察計画は無発話条件で最初の再押下、状態説明、回復操作を記録し、発言は終了後に聞きます。募集条件、タスク、成功／中止、ヘルプ、条件の割り付け、順序、分析単位、分母、欠測、反証条件を実施前に固定します。参加者数はリスク、利用者の多様性、目的、推定精度から決め、「5 人」を普遍ルールにしません。

7　判断記録で閉じずに区切る

欄	P4-D01
観察	画面記録では送信前後 500ms で可視差なし。操作可能性と支援技術への状態通知は監査前不明
技術的な根拠	著者定義の元の画面条件では送信中状態と状態表示 DOM なし。実測結果ではない
介入	診断用 `P4-C01-DISPATCH-VISIBLE`。公開候補は状態機械 `P4-SM01`
譲れない確認条件	重複業務処理を防ぐ。状態を知覚可能にする。実データを使わない
あり得る結果	支持、混合、変化なし、操作不成立、悪化
判断責任者	プロダクトオーナー。アクセシビリティ、セキュリティ、運用責任者の承認を別記
公開	確認条件未達なら非公開。限定公開時は対象と期限を明記
監視	重複リクエスト、結果不明、サポート到達、支援技術での状態検査
取り消し／再開	重複処理、回復不能、重大な状態通知不全で取り消し。問い合わせ増加で再開
Unknowns	低速回線、再訪、別言語、支援技術組合せ

反復は「改善するまで続ける」ではありません。十分な根拠で公開する、リスクのため止める、変更を戻す、問いを保留する、別の責任者へ渡す、という区切りを含みます。第25章ではこの判断を自分のループへ戻しました。本ケースでは、次の担当者が記録条件、出自、未確認事項、確認条件を再現できる形で渡すことを成果とします。

問い

最初の記述のどこが観察で、どこが評価ですか。
五つの仮説を見分ける最小の根拠は何ですか。
P4-C01-DISPATCH-VISIBLE で固定すべき条件は何ですか。
ブラウザと DevTools だけで結論できる問い、人を見る必要がある問いを分けてください。
どの条件なら公開せず、どのシグナルで問いを再開しますか。

答えの例

「押せたか分からない」は評価を含みます。送信前後で可視差がないことは画面記録で確認でき、クリック発火や支援技術への状態通知は別の根拠です。まずイベントと通信を監査し、操作成立を確かめます。見えるフィードバックの仮説には、クライアントから送信した直後の「送信しています」という可視差だけを変える比較を使い、「受付済み」とは表示しません。

画面条件の仕様で状態表示 DOM が存在しないことは、人を呼ばずに仕様検査できます。一方、その変更で再押下や状態理解が変わるかは、適切な倫理・プライバシー確認の後に行動を観察します。診断用の差分自体は公開せず、状態機械 P4-SM01 で支援技術への状態通知、二重送信防止、結果不明からの回復を満たさなければ公開確認を通しません。

別の答え方

業務上、受付直後に取消できることが最重要なら、再押下より取消への到達を主な結果にできます。その場合も、タスク目的とリスクが違うことを明記し、同じ結果表へ混ぜません。

よくある考え方

フィードバックがないのでスピナーを付ける。

注意点

スピナーは処理中を表す候補ですが、受付、結果不明、再照会、回復を区別しません。イベント未発火や重複処理も直しません。変更前に、どの状態を誰へ伝えるかを定めます。

セルフチェック

記録条件と根拠の層を残した
観察、解釈、評価を分けた
最低二つの代替仮説と反証条件を残した
診断用の差分と完成案を分けた
一度に一条件を動かした
画面、コード、人から得た根拠を代用しなかった
人を対象にする前に倫理・プライバシー確認を通した
公開、保留、非公開、取り消し、再開条件を記録した

参考

本ケースは第 19〜25 章の根拠メモと図版設計を参照する。特に ISO 9241-210、ISO 9241-11、WCAG 2.2、WAI-ARIA 1.2、HTML、CSSOM View、ResizeObserver、コンテナクエリ、NISTIR 7741 を、各主張の適用範囲とともに確認する。

付録 A　用語集

A.1 用語集の読み方

用語は分野の異なる概念を同じ「法則」へまとめないため、分野、一言で言うと、より正確には、Web では、よくある誤解、関連語、検索キーワードを示します。短い説明は入口であり、定義の代わりではありません。章末の根拠メモと付録 E で一次資料へ進んでください。

参考 ID

知覚心理学 → 付録 E.1、主に第 1〜6 章の根拠メモ
認知心理学 → E.2、主に第 7〜12・15・18 章
実験心理学 → E.3、主に第 13〜14 章
心理物理学 → E.4、第21章
HCI・ユーザビリティ・UX Research → E.5〜E.7、第 17・24〜25 章
Web デザイン・CSS・ブラウザ → E.8〜E.9、第 22〜23 章
アクセシビリティ → E.10、各章の該当根拠メモ

個別用語の主張を確認するときは、分野 ID だけでなく対応章の根拠メモまで辿ります。

近接の原則

分野: 知覚心理学
参考 ID: E1-01。根拠は対応表参照。
一言で言うと: 近いものは同じまとまりに見えやすい。
より正確には: 刺激間距離が知覚的 Grouping へ影響する傾向。
Web では: ラベルと入力欄、カード内外の距離。
よくある誤解: 近ければ必ず関係する／余白は大きいほどよい。
関連語: 類同、共通領域
検索キーワード: Gestalt proximity UI

類同の原則

分野: 知覚心理学
参考 ID: E1-01。根拠は対応表参照。
一言で言うと: 似たものは仲間に見えやすい。
より正確には: 色・形・大きさ等の類似が Grouping へ寄与する。
Web では: 同じ役割のボタンや状態。
よくある誤解: 同じ色なら同じ意味が保証される。
関連語: 一貫性、デザイントークン
検索キーワード: Gestalt similarity interface

閉合

分野: 知覚心理学
参考 ID: E1-01。根拠は対応表参照。
一言で言うと: 欠けた形を補って見やすい。
より正確には: 不完全な輪郭からまとまりや形を知覚する傾向。
Web では: Border を全部描かない Group。
よくある誤解: 省略すれば必ず洗練される。
関連語: 共通領域、図と地
検索キーワード: Gestalt closure

共通領域

分野: 知覚心理学
参考 ID: E1-01。根拠は対応表参照。
一言で言うと: 同じ囲いの要素はまとまりやすい。
より正確には: 明示された領域の共有が Grouping cue になる。
Web では: Card、Fieldset、Panel。
よくある誤解: Card を増やせば構造が明確になる。
関連語: 近接、境界
検索キーワード: common region grouping

図と地

分野: 知覚心理学
参考 ID: E1-01。根拠は対応表参照。
一言で言うと: 対象と背景を分けて見る。
より正確には: 視野を前景となる図と背景となる地へ組織化する。
Web では: Modal、Overlay、Contrast。
よくある誤解: 背景を暗くすれば必ず Modal になる。
関連語: Contrast、Layer
検索キーワード: figure ground perception

良い連続

分野: 知覚心理学
参考 ID: E1-01。根拠は対応表参照。
一言で言うと: 滑らかに続く線を一つに見やすい。
より正確には: 交差や中断があっても連続する経路として知覚する傾向。
Web では: Alignment、流れ、Chart。
よくある誤解: 揃いの別名だけである。
関連語: 整列、視線経路
検索キーワード: good continuation Gestalt

プレグナンツ

分野: 知覚心理学
参考 ID: E1-01。根拠は対応表参照。
一言で言うと: 知覚は安定した簡潔な形へ組織化されやすい。
より正確には: 複数の Grouping 原理を包括する歴史的概念。
Web では: 複雑な画面のまとまりを考える入口。
よくある誤解: 単純な画面ほど常に優れている。
関連語: Gestalt、Grouping
検索キーワード: law of Prägnanz

運動知覚

分野: 知覚心理学
参考 ID: E1-01。根拠は対応表参照。
一言で言うと: 変化から動きを知覚する。
より正確には: 時間的な位置・形の変化を運動として組織化する。
Web では: Transition、Carousel、Loading。
よくある誤解: 動けば必ず理解が高まる。
関連語: 注意捕捉、Animation
検索キーワード: motion perception interface

注意

分野: 認知心理学
参考 ID: E2-01。根拠は対応表参照。
一言で言うと: 処理する情報を選ぶ仕組み。
より正確には: 有限の処理資源を対象・位置・特徴へ配分する過程。
Web では: Primary Action、通知、探索。
よくある誤解: 視線が向けば理解した。
関連語: 選択的注意、顕著性
検索キーワード: attention visual interface

選択的注意

分野: 認知心理学
参考 ID: E2-01。根拠は対応表参照。
一言で言うと: 一部を選び他を処理しにくくする。
より正確には: タスクや期待に応じて情報処理を選択する。
Web では: 重要なエラーや操作への誘導。
よくある誤解: 重要なら大きくすれば必ず見える。
関連語: 注意、視覚探索
検索キーワード: selective attention HCI

視覚的顕著性

分野: 知覚・視覚研究
参考 ID: E2-01。根拠は対応表参照。
一言で言うと: 周囲との差で目立つ性質。
より正確には: 低次特徴等による相対的な目立ちやすさ。
Web では: 色、面積、Contrast、動き。
よくある誤解: 目立つことと重要理解・クリックは同じ。
関連語: 視覚的階層、注意
検索キーワード: visual salience UI

視覚的階層

分野: デザイン原則
参考 ID: E2-01。根拠は対応表参照。
一言で言うと: 重要度の差を視覚的強さへ表す。
より正確には: 複数の視覚変数で読む順序・関係を構成する実務概念。
Web では: 見出し、CTA、補助情報。
よくある誤解: 大きさだけの順位表。
関連語: 顕著性、Typography
検索キーワード: visual hierarchy web design

ワーキングメモリ

分野: 認知心理学
参考 ID: E2-01。根拠は対応表参照。
一言で言うと: 一時的に保ちながら処理する仕組み。
より正確には: 課題遂行中の保持と操作を担う容量制約のあるシステム。
Web では: 前画面の値、比較、複数 Step。
よくある誤解: 誰でも同じ個数しか保持できない。
関連語: 短期記憶、認知負荷
検索キーワード: working memory interface

チャンク化

分野: 認知心理学
参考 ID: E2-01。根拠は対応表参照。
一言で言うと: 知識で複数要素をまとまりとして扱う。
より正確には: 既有知識や構造により情報を高次単位へ符号化する。
Web では: 番号区切り、Navigation Group。
よくある誤解: 見た目を区切れば同じ Chunk になる。
関連語: 専門性、Grouping
検索キーワード: chunking expertise UI

認知負荷

分野: 認知心理学・教育心理学
参考 ID: E2-01。根拠は対応表参照。
一言で言うと: タスクで必要になる認知的な負担。
より正確には: 保持、処理、学習等に関わる負荷を文脈と測定法つきで扱う。
Web では: 長い Form、複雑な比較。
よくある誤解: 情報量が多い画面の同義語。
関連語: ワーキングメモリ、タスク
検索キーワード: cognitive load interface

再生

分野: 認知心理学
参考 ID: E2-01。根拠は対応表参照。
一言で言うと: 手掛かりなしに思い出す。
より正確には: 記憶内容を自ら生成する検索過程。
Web では: Command、前画面の値を思い出す。
よくある誤解: 再生は常に悪い。
関連語: 再認、記憶
検索キーワード: recall memory UI

再認

分野: 認知心理学
参考 ID: E2-01。根拠は対応表参照。
一言で言うと: 見た候補を知っていると判断する。
より正確には: 提示された刺激を過去経験と照合する過程。
Web では: Menu、Recent items、Suggestion。
よくある誤解: GUI なら常に再認だけで済む。
関連語: 再生、Recognition over recall
検索キーワード: recognition recall usability

メンタルモデル

分野: 認知心理学・HCI
参考 ID: E2-01。根拠は対応表参照。
一言で言うと: 対象の動きを予測する内的表現。
より正確には: 経験から形成され、説明・予測・操作を支える表象。
Web では: Cart、Back、保存、権限申請。
よくある誤解: 利用者全員が同じモデルを持つ。
関連語: Conceptual model、期待
検索キーワード: mental model HCI

ヒック・ハイマンの法則

分野: 実験心理学
参考 ID: E3-01。根拠は対応表参照。
一言で言うと: 選択反応時間は選択の情報量と関係する。
より正確には: 選択肢の確率を含む情報量と反応時間の関係をモデル化する。
Web では: Menu や分類を考える仮説。
よくある誤解: Menu は 7 個以下にする法則。
関連語: Choice overload、情報量
検索キーワード: Hick Hyman law

フィッツの法則

分野: 実験心理学・HCI
参考 ID: E3-03。根拠は対応表参照。
一言で言うと: 遠く小さい Target ほど選択に時間がかかりやすい。
より正確には: 距離と有効幅から Target 選択の運動時間をモデル化する。
Web では: Hit area、Edge、Touch。
よくある誤解: 特定の最小 px を直接決める法則。
関連語: Target size、pointing
検索キーワード: Fitts law HCI

差異閾

分野: 心理物理学
参考 ID: E4-01。根拠は対応表参照。
一言で言うと: 違いに気づける境界。
より正確には: 二刺激の差を一定確率で弁別できる閾。
Web では: Spacing や色差の比較。
よくある誤解: JND を普遍デザイントークンにできる。
関連語: JND、Weber
検索キーワード: difference threshold JND

JND

分野: 心理物理学
参考 ID: E4-01。根拠は対応表参照。
一言で言うと: 丁度気づける程度の差。
より正確には: Just Noticeable Difference。手続きと確率に依存する弁別差。
Web では: Before／After の差を考える入口。
よくある誤解: 1px なら常に気づく／気づかない。
関連語: 差異閾、Weber の法則
検索キーワード: just noticeable difference design

フィードバック

分野: HCI
参考 ID: E5-01。根拠は対応表参照。
一言で言うと: 行為や状態への反応を返す。
より正確には: システムが入力受付、進行、結果、回復可能性を知覚可能にする情報。
Web では: 押下済み、ローディング、成功、エラー。
よくある誤解: Animation の別名。
関連語: システム状態、状態
検索キーワード: feedback HCI interface

システム状態の可視性

分野: ユーザビリティ原則
参考 ID: E5-01。根拠は対応表参照。
一言で言うと: 今何が起きているか分かる。
より正確には: 適切なフィードバックで現在状態を適時に伝える原則。
Web では: 通信中、結果不明、保存済み。
よくある誤解: 画面に文字があれば達成。
関連語: フィードバック、状態
検索キーワード: visibility system status

ヤコブの法則

分野: UX 経験則
参考 ID: E2-01。根拠は対応表参照。
一言で言うと: 人は他 Site の経験を持ち込む。
より正確には: 既存の慣習と期待を活用する実務上の経験則。
Web では: Logo、Search、Cart。
よくある誤解: 独自 UI は禁止。
関連語: Convention、Mental model
検索キーワード: Jakob's law UX

フォン・レストルフ効果

分野: 記憶研究
参考 ID: E2-01。根拠は対応表参照。
一言で言うと: 異なる項目が記憶に残りやすいことがある。
より正確には: 同質系列の孤立項に関する記憶効果。
Web では: 例外の顕著性を考える候補。
よくある誤解: 目立たせればクリックされる法則。
関連語: Isolation effect、例外
検索キーワード: von Restorff effect

知識の呪い

分野: 認知バイアス・実務概念
参考 ID: E2-01。根拠は対応表参照。
一言で言うと: 知っている状態から未知を想像しにくい。
より正確には: 自分の知識が他者の推定へ影響する傾向。
Web では: 作者だけが知る略語や流れ。
よくある誤解: 全ての初見問題の診断名。
関連語: 専門家の盲点、Mental model
検索キーワード: curse of knowledge design

確証バイアス

分野: 認知心理学
参考 ID: E2-01。根拠は対応表参照。
一言で言うと: 信じる説明に合う根拠を集めやすい。
より正確には: 既存の信念を支持する情報を選択・解釈しやすい傾向。
Web では: 好きな案を支持する観察。
よくある誤解: 反対意見があれば消える。
関連語: 反証、Alternative hypothesis
検索キーワード: confirmation bias design

馴化

分野: 学習・知覚
参考 ID: E2-01。根拠は対応表参照。
一言で言うと: 反復刺激への反応が低下する。
より正確には: 反復提示に対する反応減少として操作的に検討する現象。
Web では: 通知や Animation への反応。
よくある誤解: 見慣れたという感想の同義語。
関連語: 注意、反応回復
検索キーワード: habituation interface

Alignment

分野: デザイン原則
参考 ID: E8-01。根拠は対応表参照。
一言で言うと: 要素を共通の基準線へ関係づける。
より正確には: 位置・端・ベースライン等を共有し構造と流れを作る。
Web では: Grid、Form、Table。
よくある誤解: すべて同じ中央へ揃える。
関連語: ベースライン、良い連続
検索キーワード: alignment graphic web

Optical alignment

分野: デザイン実務
参考 ID: E8-01。根拠は対応表参照。
一言で言うと: 数値より見え方を調整する。
より正確には: 形状や視覚重量に応じ数学的位置から補正する。
Web では: Icon、円、Play symbol。
よくある誤解: 感覚で好きにずらすこと。
関連語: Geometric center、Visual weight
検索キーワード: optical alignment typography

一貫性

分野: デザイン・ユーザビリティ原則
参考 ID: E8-01。根拠は対応表参照。
一言で言うと: 同じ意味に同じ規則を使う。
より正確には: 表現・挙動・用語の対応を予測可能に保つ。
Web では: コンポーネント、状態、ナビゲーション。
よくある誤解: 例外を全部消す。
関連語: 類同、Convention
検索キーワード: consistency UI

デザイントークン

分野: デザイン実装
参考 ID: E8-01。根拠は対応表参照。
一言で言うと: Design 判断を名前付き値として共有する。
より正確には: 色、間隔、タイポグラフィ等をシステム横断で管理する抽象。
Web では: CSS Custom Properties、Theme。
よくある誤解: 値をトークン化すれば一貫性が保証される。
関連語: Component、CSS variable
検索キーワード: design tokens

Responsive Web Design

分野: Web Design
参考 ID: E8-01。根拠は対応表参照。
一言で言うと: 利用環境に応じ Layout を適応させる。
より正確には: 柔軟なレイアウト、メディア等で多様なビューポートへ応答する設計。
Web では: 再配置、ナビゲーション、内容。
よくある誤解: 端末別固定画像を作ること。
関連語: Intrinsic design、Media query
検索キーワード: responsive web design

Reflow

分野: Web・アクセシビリティ
参考 ID: E8-01。根拠は対応表参照。
一言で言うと: 拡大や幅変更で内容が再配置される。
より正確には: 二次元スクロールを強いず読み・操作できる再配置を検討する。
Web では: ズーム、狭幅、長文。
よくある誤解: 見た目が同じこと。
関連語: WCAG 1.4.10、Responsive
検索キーワード: reflow WCAG

コンテナ Query

分野: CSS
参考 ID: E9-02。根拠は対応表参照。
一言で言うと: ビューポートでなくコンテナ条件へ応答する。
より正確には: Containing context の size や style を条件に子孫の Style を変える CSS 機能。
Web では: 再利用 Component。
よくある誤解: Media Query を完全に置換する。
関連語: Containment、Media query
検索キーワード: CSS container queries

Usability

分野: 人間工学・HCI
参考 ID: E6-01。根拠は対応表参照。
一言で言うと: 特定文脈で目標を達成する利用結果。
より正確には: 特定の利用者が特定目標を有効さ・効率・満足とともに達成する程度。
Web では: タスク完了、時間、体験。
よくある誤解: 製品に固定された一つの点数。
関連語: ISO 9241-11、文脈
検索キーワード: usability ISO 9241-11

Usability testing

分野: UX Research・HCI
参考 ID: E6-01。根拠は対応表参照。
一言で言うと: 人がタスクを行う過程を観察する。
より正確には: 参加者、タスク、条件、指標を定め問題・性能・理解を調べる方法群。
Web では: プロトタイプやサービスの Formative 評価。
よくある誤解: 5 人に感想を聞くこと。
関連語: Behavioral observation、Benchmark
検索キーワード: usability testing protocol

Think Aloud

分野: 認知研究・UX Research
参考 ID: E7-01。根拠は対応表参照。
一言で言うと: タスク中の考えを声に出してもらう。
より正確には: 指示条件下の発話報告をデータとして扱う手順。
Web では: 語の理解や予測の手掛かり。
よくある誤解: 心の中をそのまま読める／行動へ影響しない。
関連語: Retrospective interview
検索キーワード: think aloud protocol

Observation

分野: 研究・Design 実務
参考 ID: E5-01。根拠は対応表参照。
一言で言うと: 起きたことを条件つきで記す。
より正確には: 第三者が対象・時点・条件を辿れる記述。
Web では: 距離、イベント、停止、状態。
よくある誤解: 原因や良し悪しを含めること。
関連語: Interpretation、Evaluation
検索キーワード: observation interpretation evaluation

Alternative hypothesis

分野: 科学的方法・Design Research
参考 ID: E5-01。根拠は対応表参照。
一言で言うと: 別の説明候補。
より正確には: 同じ観察を説明し得る競合仮説。
Web では: ラベル、位置、権限、通信条件を並べる。
よくある誤解: 案を増やす Brainstorm だけ。
関連語: 反証、根拠
検索キーワード: alternative hypothesis design

Decision Log

分野: Design 実務
参考 ID: E5-01。根拠は対応表参照。
一言で言うと: 判断と根拠を追える記録。
より正確には: 文脈、観察、仮説、変更、結果、決定、未知、責任者を残す。
Web では: 公開、保留、取り消し。
よくある誤解: 結論を正当化する議事録。
関連語: Design rationale、ADR
検索キーワード: design decision log

付録 B　Web デザインを見るための 100 の問い

この一覧は 100 個を順番に消化する採点表ではありません。違和感に合う入口を選び、観察条件、仮説、必要な根拠へ進むために使います。

用途別セット

初めて画面を見る: B001、B002、B041、B042、B091。
実装前レビュー: B011、B021、B031、B051、B071、B081、B092。
レスポンシブ監査: B003、B019、B084、B087、B088。
人を対象にする前: B091〜B100。倫理・プライバシー確認を先に通す。
短い 5 問: B001、B011、B041、B081、B091。これは万能チェックリストではない。

B.1 見る前の条件を見る問い

B001. 誰が、何をする画面か。 B002. いまどの状態を見ているか。 B003. ビューポート、ズーム、文字サイズは何か。 B004. 内容は実データに近いか。 B005. 初回利用か再訪か。 B006. マウス、タッチ、キーボードのどれか。 B007. 通信・権限条件は何か。 B008. 観察時間を固定したか。 B009. 記録日時と版を残したか。 B010. 見えない条件を推測で埋めていないか。

B.2 まとまりと距離を見る問い

B011. 関係するものは近いか。 B012. 関係しないものは離れているか。 B013. ラベルは対応するコントロールに最も近いか。 B014. 内側と外側の余白を区別できるか。 B015. 等間隔が関係差を消していないか。 B016. 境界を外してもまとまりが見えるか。 B017. カードが必要以上に重なっていないか。 B018. 余白スケールの例外に理由があるか。 B019. 狭幅でまとまりが壊れないか。 B020. 距離以外のまとまり手がかりと競合していないか。

B.3 線と揃いを見る問い

B021. 見えない基準線はどこか。 B022. 左端・右端・中央のどれを共有するか。 B023. テキストのベースラインは揃っているか。 B024. 一つだけずれた要素はないか。 B025. ずれは意図された強調か。 B026. 数学的中央と視覚的中央を区別したか。 B027. アイコンの視覚重量は釣り合うか。 B028. Grid を外しても構造が見えるか。 B029. 長文で Alignment が崩れないか。 B030. フォーカス表示は形に沿って見えるか。

B.4 類似と規則を見る問い

B031. 同じ役割は同じ見た目か。 B032. 違う役割が同じ見た目になっていないか。 B033. 色・形・位置のどれが意味を担うか。 B034. 状態差を色だけに頼っていないか。 B035. 反復からどんな規則を学ぶか。 B036. 一つだけ違うものに理由があるか。 B037. コンポーネント差と内容差を分けたか。 B038. デザイントークンの例外を追えるか。 B039. 旧コンポーネントが混在していないか。 B040. 規則を別ページでも維持しているか。

B.5 強さと注意を見る問い

B041. 最初に目に入るものは何か。 B042. それはタスク上最も重要か。 B043. 大きさ・色・コントラスト・位置・動きのどれが強いか。 B044. 全部を強調していないか。 B045. 主要操作が複数に見えないか。 B046. エラーは必要な時点で気づけるか。 B047. 補助情報が本文より強くないか。 B048. アニメーションを止めても意味が伝わるか。 B049. 動きの面積・速度・反復は必要か。 B050. 目立つことを理解や選択と混同していないか。

B.6 記憶と選択を見る問い

B051. 前の画面を思い出させていないか。 B052. 覚える代わりに見て確認できるか。 B053. プレースホルダーだけをラベルにしていないか。 B054. 情報は知識に合うまとまりになっているか。 B055. 初心者と専門家でまとまりが違わないか。 B056. 選択肢は数より分類に問題がないか。 B057. 検索、絞り込み、並べ替えは目的に合うか。 B058. 選択肢の確率や頻度を考えたか。 B059. 段階的開示で必要情報を隠していないか。 B060. 再認を増やした結果、探索コストが増えていないか。

B.7 操作対象を見る問い

B061. 見た目と操作領域を分けて考えたか。 B062. 操作対象は入力方法に対して狙いやすいか。 B063. 操作対象までの距離と有効幅は何か。 B064. 近接操作対象の誤操作を考えたか。 B065. 画面端を利用できるか。 B066. キーボードで到達・実行できるか。 B067. Focus 順はタスク順と合うか。 B068. Disabled の理由と回復方法が分かるか。 B069. 小さなアイコンを大きく見せず操作領域を広げられるか。 B070. 操作成立を見た目だけで判断していないか。

B.8 期待と状態を見る問い

B071. 利用者は過去のどの経験を持ち込むか。 B072. 独自表現を学ぶ手掛かりがあるか。 B073. 同じ規則が次も続くと予測できるか。 B074. 例外は意図と理由を伝えるか。 B075. 押した受付が分かるか。 B076. 処理中、成功、失敗、結果不明を分けたか。 B077. 可視状態とプログラム上の状態が同期するか。 B078. 再試行と再照会を区別したか。 B079. 回復・取消・サポートへ進めるか。 B080. 作者だけが知る略語や前提はないか。

B.9 Responsive と内容変化を見る問い

B081. 画面幅を連続して変えると最初に何が壊れるか。 B082. ブレークポイントより壊れる条件を先に見たか。 B083. 200% ズームで再配置するか。 B084. 文字サイズだけを変えたか。 B085. 長い名前・URL・翻訳で壊れないか。 B086. Empty、Loading、エラー、権限差を見たか。 B087. 内容順と見た目の順序が一致するか。 B088. コンテナ単位の変化が必要か。 B089. スクロール方向と Focus 移動が矛盾しないか。 B090. スクリーンショットだけで Web を評価していないか。

B.10 仮説と検証を見る問い

B091. 観察、解釈、評価を分けたか。 B092. 概念名が観察の代わりになっていないか。 B093. 最低二つの代替仮説があるか。 B094. 何が起きれば仮説が弱まるか。 B095. 一度に何を一つだけ変えるか。 B096. 固定条件を記録したか。 B097. 画面、コード、人のどの根拠が必要か。 B098. 分母、欠測、ヘルプを定義したか。 B099. 人を見る前に倫理・プライバシー確認を通したか。 B100. 公開、保留、取り消し、再開条件を残したか。

使い方

一度に全部へ答えず、三つを選びます。答えが評価語になったら、対象、差、条件を加えて観察文へ書き換えます。人の行動を扱う問いは第24章の倫理・プライバシー条件を先に確認します。

付録 C　曖昧なレビューの言葉を観察に変える

曖昧な言葉を禁止することが目的ではありません。違和感の入口として受け取り、第三者が対象と条件を確かめられる文へ展開します。

C.1 「ダサい」

聞き直す: どの要素の、どの差が、どの表現意図と合わないか。
観察例: 見出しは明朝体、ボタンは幾何学的なサンセリフ、補助ラベルは手書き風で、三つの書体役割に反復規則が見つからない。
注意: 流行、個人の好み、対象文化を普遍的な美の基準にしない。

C.2 「いい感じ」

聞き直す: 何を維持したいか。どの利用目的・表現意図を支えたか。
観察例: 見出しの強さが一段階上がり、本文と補助情報の読む順序を区別できる。
注意: 肯定的な評価も根拠を省略すると再現できない。

C.3 「メリハリがない」

聞き直す: 何と何の視覚的強さが同程度か。
観察例: 主要操作と補助リンクが同じ色、フォントの太さ、面積で、役割差が視覚変数に対応していない。
注意: 全要素の Contrast を上げない。

C.4 「余白が足りない」

聞き直す: どの要素間の距離が、どの関係を表せないか。
観察例: ラベルと入力欄より、入力欄と次のラベルの方が近い。
注意: 大きい余白を正解にせず、内外と関係強度を見る。

C.5 「分かりにくい」

聞き直す: 誰が、どのタスクの、どの時点で、何を予測・識別・選択・回復できないか。
観察例: 送信後に可視状態が変わらず、サーバー受付と結果不明を区別する手掛かりがない。
注意: 実際の理解や行動は観察前に断定しない。

C.6 「直感的ではない」

聞き直す: どの過去経験や慣習と異なるか。学習後はどうか。
観察例: ロゴが画面左上にあるがリンクでなく、サイトトップへ戻る既存期待と異なる。
注意: 「直感」を生得的能力とせず、経験と文脈を見る。

C.7 「UX が悪い」

聞き直す: どの利用者、目標、期間、接点、結果を指すか。
観察例: パスワード再設定後に元タスクへ戻るリンクがなく、再開にホームから 6 操作を要する。
注意: 一画面の好みを経験全体の診断にしない。

C.8 「認知負荷が高い」

聞き直す: 何を保持し、何を処理し、どの知識を必要とするか。
観察例: 三つ前の画面で選んだ権限名を記憶から再生し、現在の略称と照合する必要がある。
注意: 要素数や情報量の同義語にしない。測定なしに心的状態を診断しない。

C.9 書き換えても断定を避ける

基本形は次です。

私は［条件］で［対象の差・行動］を観察した。これは［概念・実装・文脈］によって起きる可能性がある。別に［代替仮説］もある。［一つの変更または追加の根拠］で確かめ、［結果］なら仮説を弱める。

観察語へ書き換えても、その概念で原因が確定するわけではありません。

付録 D　授業で使うためのガイド

D.1 15 回授業の到達目標と進行

回	主題	到達目標	授業内の観察・討議
1	Web デザインを見る目	評価語を観察へ書き換える	同一画面の初回記録を手元に残す
2	知覚と Gestalt	HTML 構造と知覚構造を分ける	Blur／矩形化比較
3	近接と距離	関係強度を距離で説明する	Form 三案の Grouping
4	整列と見えない線	端、ベースライン、視覚補正を区別する	重ね合わせで基準線を描く
5	類同と一貫性	役割と見た目の対応を監査する	ボタン一覧を作る
6	動きと注意	注意捕捉と理解を分ける	アニメーション条件比較
7	視覚的階層	最初の注意とタスク重要度を比べる	3 秒観察と無制限観察
8	記憶とまとまり	保持・処理・知識差を記述する	フォームの再生要求を探す
9	再生、再認、選択	再認と探索コスト、選択情報量を分ける	メニュー／検索比較
10	フィッツの法則と操作	見た目と操作領域を分ける	マウス／タッチ／キーボード監査
11	メンタルモデルと慣習	経験由来の期待を仮説化する	独自 UI の代替仮説
12	フィードバックと状態	受付、処理、結果不明、回復を分ける	状態機械を作る
13	観察と仮説	複数仮説と反証条件を作る	概念名だけの指摘を書き換える
14	DevTools と人の観察	画面、コード、人の根拠を分ける	架空手順と倫理確認
15	デザインレビュー	根拠と価値を示し異論を残す	初回記録との内省比較

D.2 90 分授業の時間配分例

0〜10 分: 前回の観察を一つ共有。
10〜25 分: 日常例と概念の短い説明。
25〜40 分: 図版を個人で観察。答え例は見せない。
40〜60 分: 3〜4 人で観察／解釈／評価を分類。
60〜72 分: 答えの例と別解を提示し、結論でなく推論を比較。
72〜84 分: ブラウザ／DevTools または紙上の一軸比較。
84〜90 分: セルフチェックと未解決点を手元に記録。

時間は固定ルールではありません。支援技術、通訳、休憩、読み上げ、討議方法に応じて調整します。

D.3 個人観察からグループ討議へ

最初に個人で書く時間を確保します。発言の速い学生の語が全員の初見を上書きしないためです。共有時は「違う答え」を勝敗にせず、対象、条件、根拠、代替仮説を質問します。発言しない参加方法として、匿名カード、チャット、共同文書、読み上げ不要の提出を用意します。

D.4 答えの例を見せる時機

個人記録の前に例を見せると、例の語を探す課題になります。原則として観察後に見せます。例は診断結果の正解でなく、書き方の一例と明記します。短くても根拠の境界がある例と、詳しい例を並べ、文字数を能力スコアにしません。

D.5 よくある誤解への介入

「近接だから余白を増やす」には、どの要素間か、別のまとまり手がかりは何かを尋ねる。
「認知負荷が高い」には、保持・処理対象と観察可能な指標を尋ねる。
「5 人でテスト」には、目的、リスク、多様性、分母を尋ねる。
「DevTools の値が正解」には、見る前の予想と視覚結果を分けさせる。
「一貫性」には、意図された例外と表現価値を残す。

D.6 省略可能な節と短縮案

8 回なら、1／2-3／4-5／7-8／9-10／11-12／13-14／15 へ統合します。技術演習を行えない環境では DevTools 操作を実演に置換できますが、画面とコードの根拠境界は省略しません。人を対象とする実習を省き、既存の匿名化済み架空ログで倫理と分析を学べます。

D.7 学習評価を正解にしない

評価対象は診断結果の一致でなく、次の四点です。

対象と差を具体的に指したか。
観察、解釈、評価を分けたか。
代替仮説を残したか。
必要な根拠と反証条件を示したか。

これは標準化心理尺度ではありません。文字数、専門用語数、修正数をスコアにしません。教員の異論と学生の少数意見を記録できる欄を設けます。

D.8 図版・配布資料・アクセシビリティ

図版は色だけで差を示さず、パネル ID、短い代替テキスト、長い説明を配布します。拡大可能な形式、十分なコントラスト、キーボード操作、キャプション、読み上げ順を確認します。動画は停止・再生・速度変更と文字起こしを用意します。学生を無断で録画せず、授業参加と研究同意を分けます。

通常の授業活動、成績評価、教育改善、一般化可能な研究は同じではありません。授業で書いた観察を後から研究データへ転用せず、必要なら組織の倫理審査、自由意思による別同意、非参加による不利益の防止、教員と募集担当者／評価者の権力関係、撤回と保持を設計します。授業への参加同意を研究同意とみなしません。

教員用準備チェックリスト

到達目標と省略範囲を伝えた
図版と代替説明を事前配布した
個人観察の時間を確保した
答え例を正解として採点しない
複数の参加・発言方法を用意した
実データ、録画、同意、保持を確認した
授業後に未解決点と改善記録を残した

付録 E　参考資料一覧

本一覧は学習の入口です。完全な書誌、版、適用制約は各章の Evidence note を正本とします。URL と仕様版は公開前に再確認します。

E.1 知覚心理学

[E1-01] Max Wertheimer, “Laws of Organization in Perceptual Forms,” 1923. Gestalt の知覚的組織化を遡る原典。歴史的文脈と現代研究を分けて読む。
[E1-02] Kurt Koffka, Principles of Gestalt Psychology, 1935. Gestalt 心理学の体系的な古典。UI 向け法則集ではない。
[E1-03] Stephen E. Palmer, Vision Science: Photons to Phenomenology, MIT Press, 1999. 図と地、Grouping、奥行き等を広く学ぶ専門書。

E.2 認知心理学

[E2-01] Alan Baddeley, “Working Memory,” Science, 255(5044), 1992, pp. 556–559. Working memory model の入口。
[E2-02] Nelson Cowan, “The Magical Number 4 in Short-Term Memory,” Behavioral and Brain Sciences, 24(1), 2001. 条件つきの容量議論。UI 項目数 Rule へ直結させない。
[E2-03] George A. Miller, “The Magical Number Seven, Plus or Minus Two,” Psychological Review, 63(2), 1956. 歴史的論文。Menu を 7 個以下にする根拠として使わない。
[E2-04] Don Norman, The Design of Everyday Things, revised ed., Basic Books, 2013. Conceptual model、Feedback、Mapping の入口。

E.3 実験心理学

[E3-01] W. E. Hick, “On the Rate of Gain of Information,” Quarterly Journal of Experimental Psychology, 4(1), 1952.
[E3-02] Ray Hyman, “Stimulus Information as a Determinant of Reaction Time,” Journal of Experimental Psychology, 45(3), 1953.
[E3-03] Paul M. Fitts, “The Information Capacity of the Human Motor System in Controlling the Amplitude of Movement,” Journal of Experimental Psychology, 47(6), 1954.

三論文はいずれも実験条件と Model を読むための一次資料です。選択肢数や Target px の普遍 Rule へ変換しません。

E.4 心理物理学

[E4-01] Gustav Theodor Fechner, Elemente der Psychophysik, 1860. 心理物理学の歴史的原典。
[E4-02] Stanley Smith Stevens, Psychophysics: Introduction to Its Perceptual, Neural, and Social Prospects, 1975. 測定と尺度を調べる専門資料。

JND、Difference threshold、Weber fraction は測定手続きと刺激次元を含めて調べます。

E.5 HCI

[E5-01] ISO 9241-210:2019, Human-centred design for interactive systems, https://www.iso.org/standard/77520.html — Human-centred design 活動と反復の公式規格。
[E5-02] Stuart K. Card, Thomas P. Moran, Allen Newell, The Psychology of Human-Computer Interaction, 1983. HCI の歴史的基礎。
[E5-03] Thomas P. Moran and John M. Carroll (eds.), Design Rationale: Concepts, Techniques, and Use, 1996. 判断根拠を記録する方法。

E.6 ユーザビリティ

[E6-01] ISO 9241-11:2018, Usability: Definitions and concepts, https://www.iso.org/standard/63500.html — 利用者、目標、Context と Usability の定義。
[E6-02] James R. Lewis, “Sample Sizes for Usability Studies: Additional Considerations,” Human Factors, 36(2), 1994, https://doi.org/10.1177/001872089403600215 — 問題発見と Sample size。特定人数の普遍 Rule にしない。
[E6-03] GOV.UK Service Manual, “Using moderated usability testing,” https://www.gov.uk/service-manual/user-research/using-moderated-usability-testing — 実務的な入口。組織・地域の倫理規程を別に確認する。

E.7 UX Research

[E7-01] K. Anders Ericsson and Herbert A. Simon, Protocol Analysis: Verbal Reports as Data, revised ed., MIT Press, 1993. Think Aloud と Verbal report の条件。
[E7-02] Robert M. Schumacher and Svetlana Z. Lowry, NISTIR 7741, 2010, https://doi.org/10.6028/NIST.IR.7741 — Formative／Summative と Process。医療 EHR 文脈をそのまま一般化しない。
[E7-03] U.S. HHS OHRP, The Belmont Report, https://www.hhs.gov/ohrp/regulations-and-policy/belmont-report/read-the-belmont-report/ — Respect、Beneficence、Justice の歴史的入口。各地域の法令・審査を置換しない。

E.8 Web Design

[E8-01] Ethan Marcotte, “Responsive Web Design,” A List Apart, 2010. Responsive Web Design という整理の歴史的入口。
[E8-02] W3C, Design Principles, https://www.w3.org/TR/design-principles/ — Web Platform 設計原則。個別 UI の見た目 Rule ではない。
[E8-03] W3C Design Tokens Community Group, Design Tokens Format Module — 公開時点の Draft status と版を確認する。

E.9 CSS と Browser

[E9-01] MDN Web Docs, CSS, https://developer.mozilla.org/docs/Web/CSS — 読みやすい仕様入口。Normative source は対応する W3C／WHATWG 仕様。
[E9-02] CSS Working Group, CSS Containment Module Level 3, https://www.w3.org/TR/css-contain-3/ — Container Queries を含む仕様。
[E9-03] CSS Working Group, CSSOM View Module, https://www.w3.org/TR/cssom-view-1/ — Viewport、Geometry、Scroll 等。
[E9-04] WHATWG, HTML Living Standard, https://html.spec.whatwg.org/ — Form、Button、Focus、Semantics の正本。
[E9-05] WHATWG, DOM Standard, https://dom.spec.whatwg.org/ — DOM と Event の正本。

E.10 Accessibility

[E10-01] W3C, Web Content Accessibility Guidelines (WCAG) 2.2, https://www.w3.org/TR/WCAG22/ — Success Criteria と Conformance。
[E10-02] W3C, WAI-ARIA 1.2, https://www.w3.org/TR/wai-aria-1.2/ — Role、State、Property の意味論。ARIA だけで挙動を自動実装しない。
[E10-03] W3C, ARIA Authoring Practices Guide, https://www.w3.org/WAI/ARIA/apg/ — Pattern 例。製品要件、Browser・支援技術検証を別に行う。
[E10-04] W3C WAI, Understanding WCAG 2.2, https://www.w3.org/WAI/WCAG22/Understanding/ — Success Criterion の意図と例を読む補助資料。Normative 本文と区別する。

調べるときの記録

資料名、著者・組織、版、公開日、参照日、URL／DOI、該当節、何を支持するか、何を支持しないかを Evidence note へ残します。検索結果の要約だけを根拠にしません。

索引

電子版のため、ページ番号ではなく主な章・付録への Link を示します。詳細語義は付録 A、出典は各章の根拠メモと付録 E を参照してください。

日本語用語

注意 — 第10章、付録 A
一貫性 — 第4章、第16章、付録 A
運動知覚 — 第6章、付録 A
閉合 — 第5章、付録 A
確証バイアス — 第18章、付録 A
共通領域 — 第5章、付録 A
近接 — 第2章、付録 A
再生／再認 — 第12章、付録 A
視覚的階層 — 第10章、付録 A
図と地 — 第5章、付録 A
選択的注意 — 第10章、付録 A
知識の呪い — 第18章、付録 A
知覚的組織化 — 第1章
チャンク化 — 第11章、付録 A
馴化 — 第18章、付録 A
プレグナンツ — 第1章、付録 A
メンタルモデル — 第15章、付録 A
類同 — 第4章、付録 A
良い連続 — 第3章、付録 A
ワーキングメモリ — 第11章、付録 A
Typography／文字の形 — 第7章
色と Contrast — 第8章
リズムと重心 — 第9章

欧文・理論名

Alternative Hypothesis — 第20章、付録 A
フィードバック — 第17章、付録 A
Fitts's Law — 第14章、付録 A
Hick–Hyman Law — 第13章、付録 A
JND／Just Noticeable Difference — 第21章、付録 A
Jakob's Law — 第15章、付録 A
Mental Model — 第15章、付録 A
Observation／Interpretation／Evaluation — 第19章、付録 A
System 状態 — 第17章、付録 A
Think Aloud — 第24章、付録 A
Usability — 第24章、付録 A
Von Restorff Effect — 第16章、付録 A

Web 実装・調査

アクセシビリティ Tree — 第23章、第24章、第25章、第 IV 部統合ケース
CSS Custom Properties — 第4章
コンテナ Query — 第22章、付録 A
Decision Log — 第25章、第 IV 部統合ケース、付録 A
デザイントークン — 第4章、付録 A
DevTools — 第23章
Flexbox／Grid Overlay — 第3章、第23章
Hit Area — 第14章
HTML 構造と知覚構造 — 第1章
Network／結果不明 — 第17章、第 23〜25 章
Responsive Web Design／Reflow — 第22章、付録 A
Usability Testing — 第24章、付録 A

レビュー語

「いい感じ」 — 付録 C
「UX が悪い」 — 付録 C
「認知負荷が高い」 — 第11章、第19章、付録 C
「ダサい」 — 第19章、付録 C
「直感的ではない」 — 第15章、付録 C
「分かりにくい」 — 第19章、付録 C
「メリハリがない」 — 第10章、付録 C
「余白が足りない」 — 第2章、第19章、付録 C

用語集全項目

読後の観察メモ

このページは、第 25 章本文の著者例を読む前に使います。序章で残した最初の観察メモと比べるために、同じ画面をもう一度見て、いまの言葉で記録します。

下の項目をコピーして、テキストエディタ、メモアプリ、ノート、印刷した紙など、自分が後で見返せる場所に残してください。本書のサーバーへ送信する必要はありません。

読後の観察メモ

最初に目に入ったもの:

気になった場所:

序章の画面だと気づいたか:

序章で自分が何を書いたかを思い出したか:

同時間の初動記録

まず 30 秒だけ画面を見ます。最初に目に入ったもの、気になった場所、序章の画面だと気づいたかを書きます。序章の観察メモはまだ開きません。

時間制限なしの展開記録

観察:
解釈:
評価:
主な仮説:
別の仮説:
必要な確認:
仮説が外れたと言える条件:
一つだけ変えるなら:
変えずに固定する条件:

序章の観察メモを開いた後

用語数や文字数ではなく、何を見て、どこまで言えると考え、どんな別の仮説を残したかを比べます。これは教材効果を証明する実験ではありません。

単独観察メモ

序章の最初の観察メモがない場合に使う記録ページです。最初の記録と比較できないため、Before／After や教材効果の測定とは呼びません。代わりに、読後の時点で初めて見る画面を観察し、観察、解釈、評価、代替仮説を分けて書く練習として使います。

備品貸出申請の未見画面を使う単独観察を示す図。 — 転移図 1　未見画面を使う単独観察

観察:
解釈:
評価:
別の仮説:
必要な確認:
仮説が外れたと言える条件:

Keyboard shortcuts

Webデザインを見る目