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

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

文字が読みにくい。どこを押せばよいか分からない。きれいに並んでいるはずなのに、なぜか落ち着かない。でも、その理由をうまく説明できない。

デザインを始めたばかりのころは、「センスがないから分からない」と思ってしまうかもしれません。しかし、その違和感は、画面を詳しく見るための大切な出発点です。

たとえば、余白が変だと感じた画面を見てみます。

すべての余白が狭いのでしょうか。それとも、見出しと説明の間だけが広いのでしょうか。関係するボタンと説明が離れ、別の内容に見えているのでしょうか。同じ 16 ピクセルの余白でも、文字の大きさや周囲の情報によって見え方は変わります。

「余白が変」を、どの要素とどの要素の間が、周囲と比べてどう違うのかまで説明できれば、直す場所を考えられます。

この本で学ぶこと

この本は、Figma のボタンの場所や、CSS の命令を順番に覚える操作マニュアルではありません。人が画面をどのように見て、情報を探し、覚え、選び、押したあとの結果を待つのかを手がかりに、Web デザインを読み解く本です。

近いものが一つのまとまりに見えることがあります。大きな文字や周囲と違う色へ、注意が向くことがあります。前の画面で見た番号を覚え続けるのは大変です。押したボタンから返事がなければ、もう一度押してしまうことがあります。

こうした人の特徴を知ると、画面で起きていることを見つけやすくなります。ただし、「人間は必ずこう見る」という万能な答えにはしません。見る人の目的、使っている機器、周囲の明るさ、過去に使ったサイトなどによって、同じ画面の使われ方は変わるからです。

図は、本文と一緒に読む

この本では、多くの図を使います。図の中へ答えや長い解説を詰め込むのではなく、一枚の図では一つの画面や一つの違いだけを見せます。

先に本文で、どこを見る図なのかを説明します。図のあとには、そこから何が分かるのかを書きます。読者が図を使って課題を解いたり、正解を当てたりする必要はありません。著者が画面を読み解く過程を追いながら読み進められます。

Web サイトは、止まった一枚の絵ではない

Web サイトは、見る人の画面幅によって並び方が変わります。文章が長くなることも、画像が届かないこともあります。ボタンを押せば処理が始まり、成功することも失敗することもあります。

そのため、この本では完成した見た目だけでなく、HTML や CSS、ブラウザの動き、実際に人が使う場面も扱います。美しく見えることと、必要な情報を見つけられることの両方を考えます。

読み終えたとき、すべての正解を覚えている必要はありません。

「もっといい感じに」ではなく、「見出しと説明が離れ、別の内容に見える」「売り切れを色だけで伝えている」「押したあとに処理中だと分かる表示がない」と言えるようになること。それが、この本の目指す変化です。

本書の使い方

四つの部

• 第 I 部では、距離、そろい、大きさ、文字、色、動きが、画面のまとまりや強さをどう変えるかを見ます。
• 第 II 部では、情報を見つける、覚える、選ぶ、ボタンを押すときに起こる難しさを見ます。
• 第 III 部では、過去の経験や同じ画面の繰り返しから、次の動きを予想する仕組みを見ます。
• 第 IV 部では、画面で感じた違和感を言葉にし、HTML や CSS までたどって直す流れを見ます。

順番に読むと、一つの画面を見るところから、制作上の判断までが積み上がります。気になる章から読んでも構いませんが、初めて Web デザインを学ぶ場合は、第 I 部から順に読むと用語が少しずつ増えていきます。

章の読み方

各章は、日常や Web サイトで起こる具体的な出来事から始まります。次に、実際にありそうな画面を使い、著者が何を見て、どう考えたのかを説明します。必要な専門用語は、現象を理解したあとに紹介します。

図版には、本文が説明している一つの差だけを残します。図の前に注目する場所を案内し、図の後に何が分かったかを説明します。読者が図だけから答えを探す必要はありません。

参考資料の読み方

章末の「参考」には、本文の内容をさらに詳しく知るための研究や Web の公式仕様を載せています。最初からすべて読む必要はありません。気になった話題を深く調べたいときに使えます。

巻末の資料

本文は、読むだけで話がつながるように作っています。巻末には、本文に出てきた言葉を調べる用語集、曖昧なレビュー表現を具体的な観察へ変える例、参考資料の一覧があります。どれも暗記するためのものではなく、分からない言葉や気になる話題があったときに参照する資料です。

第24章では、人が Web サイトを使う様子から分かることを、著者が例を使って説明します。読者が友人や家族を集めて調査する必要はありません。

序章　まず、一つの画面を読み解く

最初に、一つの Web 画面を見ます。専門用語はまだ使いません。著者が「どこが気になったか」を画面上の具体的な場所へ置き換えていく過程を追います。

例に使うのは、架空の権限申請画面です。締切、申請対象、三種類の権限、承認経路、申請理由、送信ボタンが一画面に置かれています。情報の意味を詳しく読む前から、強く見える場所と、関係が分かりにくい場所があります。

最初に強く見えるもの

右上の「本日 17:00 締切」は、周囲と異なる色の面に入り、画面の端で孤立しています。そのため、本文より文字が小さくても強く見えます。ここで分かるのは、締切が重要だという事実ではなく、周囲との見た目の差が大きいことです。

関係が分かりにくいもの

画面中央には「閲覧」「編集」「ダウンロード」という三つの権限があります。その下には、直属上長から部門長までの承認経路があります。どちらも横方向へ並び、同じような強さの枠を持っています。このため、選択する権限と、申請後に進む承認順序が、似た種類の情報に見える可能性があります。

押した後がまだ見えない

右下の「申請する」は、塗りのある大きなボタンです。しかし、この静止画だけでは、押した直後に何が起きるか、送信中に再び押せるか、成功や失敗がどこへ表示されるかは分かりません。画面に見えている情報と、操作して初めて分かる状態は別です。

この序章では、まだ良い画面か悪い画面かを決めません。一つの「なんか変」を、締切の色、権限と承認経路の似た枠、送信後の状態という具体的な場所へ分けました。第 I 部からは、このような違いがなぜまとまりや強さとして見えるのかを、一つずつ詳しく説明します。

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

Web サイトを開くと、文字、画像、色、線、ボタンなどが目に入ります。しかし、私たちはそれらを、ばらばらの部品として見ているわけではありません。

「上にサイト名がある」「中央の大きな場所が主な案内だ」「この画像と説明は一組だ」と、関係のあるものをまとめながら見ています。

最初に、文化祭サイトのパソコン表示を見ます。

横幅が広いため、「このまちの好きが、舞台になる。」という主題と舞台の絵を左右へ並べられます。その下には、開催日や受付変更のお知らせが続きます。大きな主題、小さな案内、その下の詳しい情報という順に、面積と文字の強さが変わっています。

同じ内容をスマートフォンへ表示すると、並び方が変わります。

横に並んでいた主題と絵が、上から下へ積み直されています。それでも、主題のあとに説明があり、そのあとに詳しい情報が続く順番は保たれています。

この二枚から分かるのは、画面の見え方が、部品の有無だけでは決まらないことです。同じ文字と画像でも、大きさ、距離、並ぶ方向が変われば、まとまりと読む順番も変わります。

画面は、いくつかの「面」としても見える

文章を読むと、その内容に注意が向きます。そこで一度だけ文字を長方形へ置き換えると、内容から離れて、画面の大きな形を見やすくなります。

この図では、上部の細い帯、その下の大きな主題、中央の広い画像、その下に続く小さな情報の集まりが見えます。文字の意味を読めなくても、情報が多い場所と少ない場所、広く空いた場所は残ります。

これは、人が本当に文字を長方形として見ているという意味ではありません。画面の面積と配置を説明するために、著者が情報を一時的に減らした図です。文字の内容や書体の違いは消えているため、最後には通常の画面へ戻る必要があります。

情報を一種類ずつ減らす

同じ画面でも、何を残すかによって見つけやすい関係が変わります。ここでは、通常の画面、色を外した画面、細部をぼかした画面、形だけを残した画面を一枚ずつ見ます。

最初は通常の画面です。

通常の画面では、内容も雰囲気も分かります。その一方で、色、写真、文章の意味が同時に入るため、何がまとまりを作っているのかを一度に説明するのは難しくなります。

次は、色を外した画面です。

青や赤の違いはなくなりましたが、暗い文字と明るい背景、大きな暗い画像面の差は残っています。つまり、色の種類がなくても、明るさの差だけで見つけられる境界があります。

三枚目は、細部をぼかした画面です。

文章は読めなくなりますが、画面の上部、中央の大きな面、下部の小さな面という強弱は残ります。細かい装飾より、大きな面積の差が先に見える図です。

最後は、内容の細部を外し、埋まっている形だけを残した画面です。

この図では、どこに情報が集まり、どこが広く空いているかを比べられます。ただし、文章の意味も、写真の内容も、色が伝える雰囲気もありません。

四枚は、よい画面を自動的に選ぶ検査ではありません。それぞれ、通常の画面に含まれる情報の一部だけを見やすくしたものです。色を外した図だけ、ぼかした図だけで評価せず、通常の画面と行き来しながら使います。

HTML のまとまりと、見た目のまとまり

Web ページの HTML には、どの要素がどのまとまりに入るかという親子関係があります。しかし、同じ親要素に入っているからといって、画面でも同じ強さの一組に見えるとは限りません。

次の HTML では、見出し、説明、残席、申し込みボタンが同じ section の中にあります。

<section>
  <h2>秋のワークショップ</h2>
  <p>つくる・見る・話すを楽しむ一日です。</p>
  <p>残り3席</p>
  <button>申し込む</button>
</section>

画面では、次のように表示されています。

四つの要素は HTML 上では同じ親を持っています。しかし画面では、「残り 3 席」と「申し込む」が同じ青い背景に入り、近く並んでいます。そのため、下の二つが、購入前に続けて読む一組として強く見えます。

HTML は、見出しやボタンの意味、文書の順序を伝えるために大切です。CSS による距離、色、囲みは、目で見たまとまりを作ります。どちらか一方だけを正しくすればよいのではなく、意味のまとまりと見た目のまとまりが、必要な関係を同じように伝えているかを考えます。

まとまりを作る手がかりは一つではない

ものを一組に見せる方法は、距離だけではありません。色や囲みも使えます。まず、一種類ずつ見ます。

中央の間隔だけが広いため、四枚の均等な列ではなく、二枚ずつの組に見えます。この場合は距離がまとまりを作っています。

間隔はすべて同じですが、一枚目と三枚目だけが青いため、離れた二枚にも共通点が生まれます。この場合は色が種類を伝えています。

左の二枚が同じ背景の中にあるため、囲まれていない右のカードとは別の範囲に見えます。

ここまでは、距離、色、囲みがそれぞれ同じ組を分かりやすく示していました。最後の図では、三つが別々の組を示します。

近いカード、同じ色のカード、同じ背景に入ったカードが一致していません。読者は、一つの手がかりだけを見れば別の組を選ぶことになります。

実際の Web サイトでは、文字の意味や画像の内容、押したあとの動きも加わります。だから「近いものはまとまる」という一つの原則だけで、画面の読み方を決めることはできません。関係してほしい情報へ、距離、色、囲み、言葉が同じ方向を示しているかを見る必要があります。

画面のどこが、どう見えるかを言葉にする

「ごちゃごちゃしている」「すっきりしている」と感じたら、そこで判断を終えず、画面上の場所へ戻ります。

• どの情報が近く集まっているか
• どこに大きな面があるか
• どの端や中心がそろっているか
• 同じ色や形は、同じ意味を表しているか
• 囲みの内側と外側で、距離はどう変わるか

このように言葉へ変えると、何を残し、何を直すかを話せます。

次の第2章では、この中から「距離」を取り出します。同じ要素でも、間隔が変わるだけで、どこまでを一組として見るかがどう変わるのかを詳しく見ていきます。

参考

• Johan Wagemans ほか, “A Century of Gestalt Psychology in Visual Perception I”, 2012 — 近さや似ている形が、知覚のまとまりへどう関係するかを整理した論文です。
• WHATWG, HTML Living Standard — HTML が文書の要素と関係をどのように表すかを確認できる公式仕様です。
• W3C Web Accessibility Initiative, Images Tutorial — 図の目的に合った代替テキストを考えるための公式資料です。

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

フォームを見て、「余白が足りない」と感じることがあります。しかし、すべての余白を広げれば読みやすくなるわけではありません。

項目名と入力欄の間まで広げると、どの項目名がどの入力欄を説明しているのか、かえって分かりにくくなることがあります。反対に、一つの項目の内側は近く、次の項目までは広く空いていれば、全体が詰まっていても境界は見えます。

余白は、何もない場所ではありません。どの情報とどの情報が関係しているかを伝える場所です。

人の間隔が、集団の見え方を変える

最初に、八人が横一列へ並ぶ図を見ます。人の形は変えず、間隔だけを変えます。

すべての間隔が同じなので、途中に強い切れ目がありません。八人が一つの列として見えます。

次は、二人の間だけを近づけ、その次の人までを広く空けます。

小さな間隔が「二人の内側」、大きな間隔が「次の組まで」を表します。同じ形の八人でも、距離の繰り返しによって四つの組が生まれます。

最後は、中央の間隔だけを広くします。

中央の広い空白が境界となり、左の四人と右の四人へ分かれて見えます。

実際の人なら、服装、体の向き、会話も集団を知る手がかりになります。この図は、それらを同じにして、距離だけが変わるとまとまりも変わることを見せています。

横の組、縦の組、均等な格子

次は、人の形や言葉を使わず、同じ点だけを並べます。横方向と縦方向の距離を一枚ずつ変えると、何が一組に見えるかが分かります。

まず、横の二点を近づけます。

縦の点までの距離より、横の点までの距離が小さいため、左右の二点が一組に見えます。

次は、縦の二点を近づけます。

今度は、上下の二点が近いため、縦向きの組が並んで見えます。点の数、大きさ、色は図 2-2A と同じです。変えたのは距離の向きだけです。

三枚目では、横と縦の距離をほぼ同じにします。

どちらの向きにも強い差がないため、横のペア、縦のペアのどちらか一方へ分ける理由が弱くなります。全体が均等な格子として見えます。

ここで大切なのは、「何ピクセルなら一組になる」という数字を覚えることではありません。点の大きさ、画面の縮尺、ほかの距離との比べ方が変われば、同じ数値でも見え方は変わります。「近い」は、周囲との関係で決まります。

フォームには、二種類の距離がある

フォームでは、少なくとも次の二つを分けて考えます。

• 項目名から、その入力欄まで
• 入力欄から、次の項目名まで

以前の図にあった「入力まで」「次まで」という短い言葉だけでは、何から何までの距離か分かりません。この章では、毎回、二つの端を文章で説明します。

最初のフォームでは、項目名と入力欄を近づけ、次の項目までは広く空けています。

小さな距離が一項目の内側を、大きな距離が項目と項目の境界を表します。囲み線がなくても、どの項目名と入力欄が一組かを追いやすい配置です。

次は、二種類の距離を同じくらいにします。

文字を読めば対応は分かります。しかし、距離には「ここまでが一項目」という切り替わりがありません。毎回、項目名の内容を読み直して対応を確かめることになります。

三枚目では、入力欄から次の項目名までの方を近づけます。

距離だけを見ると、上の項目名より下の項目名の方が入力欄に近くなっています。HTML で正しく label と入力欄を結びつけていても、目で見た関係は逆を示しています。

入力エラーの文章が加われば、項目の高さは変わります。項目名、入力欄、エラー文を一つのまとまりとして近づけ、そのまとまりから次の項目までは広く空けると、状態が変わっても関係を保ちやすくなります。

空白が置かれる場所によって、役割は変わる

同じ 16 ピクセルの空白でも、どこにあるかによって意味が違います。ここでは、ボタンの内側、カードの中、次のセクションまでを一枚ずつ見ます。

ボタンの内側の空白は、文字を囲む形を作るだけでなく、押せる範囲を広げます。ただし、大きくしすぎれば周囲の操作や文章を押し下げます。押せる範囲については第14章で詳しく扱います。

カード内の空白は、情報同士の関係を作ります。題名と短い説明を近づけ、日時の前を少し広くすれば、内容の説明と開催情報を分けて読めます。

一枚のカードの中より、カードと次のセクションの間を広くすると、「ここから別の内容が始まる」という境界になります。

この三つをすべて「余白」と呼ぶことはできます。しかし、ボタン自身の内側、カード内の情報同士、二つの大きなまとまりの間では、管理する要素も役割も異なります。

gap、padding、margin は、誰が空白を持つか

画面で同じように見える空白でも、CSS では別の要素が管理できます。ここでは gap、padding、margin を、一つずつ DOM の関係と結びつけます。

gap は、親要素が子要素の間を管理する

たとえば、三枚のカードを並べる一覧が間隔を決めるなら、親要素へ gap を指定できます。

.card-list {
  display: grid;
  gap: 24px;
}

カードが増えても減っても、隣り合うカードの間に同じ規則が使われます。各カードが、自分の左右へ個別の空白を持つ必要はありません。

padding は、要素自身の境界と内容の間を管理する

カードの背景や枠線から、内容をどれだけ離すかは、カード自身の padding で表せます。

.card {
  padding: 24px;
}

背景色も枠線もカードの外形まで続き、空白はその内側に入ります。カードを別の場所へ移しても、内容と境界の関係はカードと一緒に移動します。

margin は、要素自身の外側に空白を置く

特定の見出しだけ、前の内容から離したい場合などは、その見出し自身の外側へ margin を置けます。

.section-heading {
  margin-block-start: 48px;
}

ここでは margin-top ではなく margin-block-start を使っています。これは、文章が進む方向の「始まる側」を表す書き方です。横書きと縦書きなどで方向が変わっても、前の内容から離すという意図を残しやすくなります。

見た目が同じでも、DOM の責任は違う

三枚の図の空白が同じ幅なら、静止画では同じように見えるかもしれません。しかし、要素を追加したとき、背景色を付けたとき、並ぶ方向を変えたときに違いが現れます。

• 一覧全体が、並ぶ子要素の間を決めるなら gap
• カードやボタン自身が、境界と内容の間を決めるなら padding
• 特定の要素が、自分の外側で前後と離れるなら margin

プロパティ名を暗記してデザインを決めるのではありません。まず、誰と誰の間にある空白か、どの要素がその関係を管理するかを決め、そのあとで CSS を選びます。

余白を一律に増やさない

余白が気になったとき、ページ中の値へ同じ数字を足してはいけません。項目の内側まで広げれば、関係する情報が離れてしまいます。

見る順番は単純です。

1. 何と何の間にある空白かを指す
2. 一つのまとまりの内側か、次のまとまりまでかを分ける
3. 周囲の距離と比べる
4. その関係を管理する DOM 要素を決める
5. gap、padding、margin などの CSS へ置き換える

近いものが同じ仲間に見えるなら、距離は画面の文法になります。第3章では、距離に加えて、要素の左端、右端、中心、文字の基準線が作る「そろい」を見ていきます。

参考

• York University, “Laws of Organization in Perceptual Forms” — 点の距離とまとまりを扱った古典的な図を確認できます。
• W3C Web Accessibility Initiative, Grouping Controls — 関係するフォーム項目を、見た目と HTML の両方でまとめる例です。
• W3C, CSS Box Model Module Level 3 — 内容、padding、枠線、margin の関係を定める公式仕様です。
• W3C, CSS Box Alignment Module Level 3 — gap が要素間の空白を作る仕組みを確認できます。

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

ページを見て、「少しガタついている」「なんとなく落ち着かない」と感じることがあります。実際の線は描かれていなくても、文字やカードの端が同じ位置で繰り返されると、そこに一本の線があるように見えるからです。

この章では、その線を見つけます。ただし、すべてを左へそろえる話ではありません。左端、右端、中心、カードの下端、文字の基準線など、内容に合った基準を選びます。

描かれていない四つの線

最初の四枚では、青い点線を補助線として重ねています。点線は完成した Web サイトに表示するものではありません。何が同じ位置へそろっているかを説明するための線です。

見出しと本文は、長さが違っても、読み始める左端をそろえられます。

行頭が同じ位置にあれば、次の行を読むとき、視線を戻す場所が安定します。

時刻のような数値は、右端をそろえる方法があります。

文字数が違っても、終わる位置が同じなら、上下の時刻を比べる場所がそろいます。

幅の違うボタンは、中心を同じ高さへ置くことができます。

この場合に共有しているのは、左端や右端ではなく、それぞれのボタンの中央です。

高さの違うカードなら、下端をそろえることもできます。

四枚は、左端だけが正しい基準ではないことを示しています。何を読み、何を比べるかによって、役立つ線は変わります。

左右の端、中心、文字の基準線を分けて見る

一つの図へ三種類の線を重ねると、何を説明しているのか分かりにくくなります。ここでは、左右の端、中心、文字の基準線を別々の図で見ます。

名前の左端と、日時の右端

出演者名は、読み始める左端を共有しています。日時は、文字数が違っても終わる右端を共有しています。一つの一覧の中に、役割の違う二本の縦線があります。

カードの枠線をそろえているだけではありません。カードの内側で、名前と日時がそれぞれ別の基準を繰り返しています。

幅の違うボタンの中心

「保存」と「下書きとして保存」では、必要な幅が違います。左右の端はそろいませんが、中心が同じ高さにあれば、一つの操作列として並べられます。

文字が一行に並ぶ基準

図の赤い線は、文字が一行に並ぶときの基準の一つで、ベースラインと呼ばれます。文字を囲む四角形の上下中央をそろえる方法とは異なります。

大きな時刻と小さな「開演」、ボタンの外枠とその中の文字では、箱の高さが違います。それでも文字のベースラインを共有すると、一つの行として読める場合があります。

整列と、曲線が続いて見えることは別

「そろっている」という話と、「離れた線が続いて見える」という話は似ていますが、同じではありません。

図 3-3A は、制作者がカードの開始位置を同じにした配置です。このように、複数の要素へ共通の端や中心を与えることを整列と呼びます。

図 3-3B では、制作者が線分の左端をそろえているわけではありません。離れた線分の向きが滑らかにつながるため、一つの曲線として感じられます。この見え方は「良い連続」と呼ばれます。

良い連続があるから、すべての Web ページを左ぞろえにすべきだ、とは言えません。整列はレイアウトを決める方法であり、良い連続は形がどうまとまって見えるかを説明する言葉です。

数値上の中央と、中央に見える位置

丸い再生ボタンの中へ、右向きの三角形を置く例を考えます。

最初の案では、三角形を囲む最小の四角形の中心と、円の中心を同じ位置へ置いています。

CSS で三角形の箱を中央へ置けば、この配置を作れます。しかし三角形は左右対称ではありません。左側には長い縦辺があり、右側には細い先端があります。そのため、箱の中心が同じでも、三角形の塗られた形が少し左へ寄って見える場合があります。

次の案では、三角形の大きさと形を変えず、位置だけを少し右へ動かしています。

これは「三角形は必ず何ピクセル右へ動かす」という規則ではありません。三角形の角度、大きさ、線の太さ、円との比率が変われば、合う位置も変わります。

大切なのは、最初から感覚だけで動かすことではありません。まず数値上の中央を基準にし、形と大きさを固定したまま位置だけを変え、二つを比べます。このような調整を、見た目に合わせる位置調整、英語では optical alignment と呼びます。

文字には、箱とは別の線がある

CSS で文字へ font-size や line-height を指定すると、ブラウザは文字を置くための行の箱を作ります。しかし、その箱の上下いっぱいまで文字の形が埋まるわけではありません。

図には三種類の境界があります。

• 行の箱は、ブラウザが一行を配置する範囲
• ベースラインは、多くの文字が並ぶ基準
• 文字の輪郭は、実際に黒く描かれて見える形

欧文の g や p は、ベースラインより下へ一部が伸びます。日本語の仮名や漢字は、欧文の大文字や小文字とは異なる形で文字の枠を使います。同じ font-size でも、書体が変われば見かけの大きさや上下の空白は変わります。

そのため、文字を含む二つの部品の箱が同じ高さでも、文字そのものはそろって見えないことがあります。反対に、文字が一行としてそろって見えても、外側の箱の上下中央は異なることがあります。

詳しい文字組みは第7章で扱います。ここでは、CSS の箱だけで文字の見える位置を説明しきれないことを覚えておけば十分です。

あえて軸から外すこともできる

すべてを同じ線へそろえると、安定した反復を作れます。

次に始まる場所を予想しやすく、静かな構成です。しかし、意図して軸を外すデザインもあります。

見出しと本文で異なる軸を持ち、その関係が各セクションで繰り返されれば、段差は表現上の規則として読めます。

最後は、一枚のカードだけが軸から外れています。

このカードだけに重要な状態や別の役割があるなら、位置の違いにも意味があるかもしれません。ほかと同じカードなのに一枚だけずれているなら、余白や幅の指定が違う可能性があります。

画面だけを見て、意図か事故かを断定することはできません。しかし、どの要素のどの端が、どの共通軸から外れているかは説明できます。そのあとで、HTML と CSS、別の画面幅、デザイン上の目的を確かめます。

どの線をそろえたのかを言葉にする

「きれいにそろえる」だけでは、何を直すのか分かりません。

• 見出しと本文の左端
• 時刻や価格の右端
• 幅の違うボタンの中心
• 大きさの違う文字のベースライン
• 高さの違うカードの下端

このように基準を指すと、同じ画面を見ながら話せます。数値上の位置と見た目が合わない形では、基準案と位置だけを変えた案を比べます。意図して外すなら、そのずれを一度きりの例外にせず、意味や反復と結びつけます。

次の第4章では、位置ではなく、色、形、大きさなどの「似ている見た目」が、同じ役割をどう伝えるかを見ていきます。

参考

• Johan Wagemans ほか, “A Century of Gestalt Psychology in Visual Perception I”, 2012 — 離れた線が連続して見える条件を含む、知覚のまとまりに関する論文です。
• W3C, CSS Box Alignment Module Level 3 — Flexbox や Grid で、端、中心、ベースラインをそろえる方法を定める仕様です。
• W3C, CSS Inline Layout Module Level 3 — 行の箱と文字のベースラインを詳しく確認できる仕様です。

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

Web サイトを使っていると、私たちは同じ見た目のものに同じ使い方を期待します。青い角丸のボタンを押して次のページへ進めたなら、別の場所にある同じボタンを見たときも、似たことが起きると思うでしょう。

ところが、その一つだけが入力内容を消すボタンだったらどうでしょう。押す前には違いが分かりません。見た目が教えた規則と、実際の働きが食い違っているからです。

反対に、どれも同じ「詳細を見る」ボタンなのに、一つだけ赤かったり、背が低かったりすると、そこだけ別の意味があるように見えます。人は、似たものを仲間として受け取り、違うものには違う理由があると考えやすいのです。

この章では、同じ見た目がどのように使い方を教えるのかを、実際の画面で追います。そして、何をそろえ、何を違わせるとよいのかを考えます。

4.1 見た目は、次に起きることを予告する

ボタンの色、形、大きさ、文字の太さ、アイコン、置かれた場所。私たちはこうした手がかりを一つずつ数えてから操作しているわけではありません。画面を見た瞬間に、似たものを見つけ、「これは同じ種類だろう」と予想します。

ただし、同じ色だから同じ働きだと決まるわけではありません。青はサイト全体のテーマカラーかもしれません。丸い形は、押せることを示しているだけかもしれません。ボタンに書かれた言葉や置かれた場所も一緒に見て、初めて使い方を予想できます。

大切なのは、見た目と働きを対応させることです。同じ働きには共通する見た目を与え、違う働きには見分けられる手がかりを残します。次の例では、同じ操作なのに見た目だけが変わると、何が起きるかを見ていきます。

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

文化祭サイトに「詳細を見る」というボタンが四つあります。どれも出演者カードから詳細プレビューを開く操作です。それなのに外観が少しずつ違うと、状態や重要度まで違うように見えることがあります。

比較の基準になるカードを、図 4-2A に示します。以降の三枚でも、画像の大きさ、カードの外形、ボタンの文言と位置は変えません。

図 4-2B では、ボタンの色だけを赤へ変えました。高さも角丸も同じですが、危険な操作や警告を表すボタンのように見える可能性があります。

図 4-2C は高さだけを低くした案です。補助的な操作や、別の部品のように見える可能性があります。

図 4-2D は角丸だけを強くした案です。同じ青色でも、外形の違いによって別の部品群に属するように見えることがあります。

小さな違いにも、意味があるように見える

図 4-2A〜4-2D では、ボタンに書かれた言葉と置かれた場所を変えず、色、高さ、角丸を一つずつ変えました。いくつもの部分を同時に変えると、何が印象を変えたのか分からなくなるからです。

赤いボタンを見ると、削除や警告を思い浮かべる人がいるでしょう。背の低いボタンは、少し重要度の低い操作に見えるかもしれません。丸みの強いボタンは、別の種類の部品に見えることがあります。実際の働きは同じでも、見た目の差には意味があるように感じられます。

もちろん、全員が同じ受け取り方をするとは限りません。それでも、理由のない違いを増やすほど、利用者が考えなければならないことは増えていきます。

差は情報になる

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

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

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

答えられない差は、制作の途中で偶然残ったものかもしれません。ただし、画面だけを見て決めつけることはできません。選択中や読み込み中など、まだ説明されていない状態を表している場合もあるからです。

同じ役割の範囲を決める

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

そろえるべきなのは、HTML で同じ button を使っているもの全部ではありません。押した後に同じ種類の結果が起きるか、重要度や危険性が同じかを考えます。「次へ進む」と「すべて削除する」は、どちらもボタンですが、同じ見た目にしない理由があります。

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

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

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

図 4-3A の「送信する」はフォームの内容をサーバーへ送ります。

図 4-3B の「音楽」は、同じページにある一覧を絞り込みます。

図 4-3C の「詳細を見る」は、別のページへ移動するリンクです。

三つの図では、青い角丸という見た目はほとんど同じです。しかし、押した後に起きることは違います。

「送信する」は、入力したメールアドレスを送ります。「音楽」は、今いるページの一覧を変えます。「詳細を見る」は、別のページへ移動します。ボタンに書かれた言葉を読めば違いは分かりますが、形だけを眺めると、すべて同じ種類の操作に見えます。

同じ見た目を使うこと自体が間違いなのではありません。三つとも「押せる場所」だと知らせるには、共通する形が役立ちます。ただし、押した後の違いを文字や置き場所でも伝える必要があります。送信ボタンはフォームの最後に置き、絞り込みは選択肢として並べ、詳細リンクはカードの内容に続けて置く。このように周りとの関係まで設計すると、同じ青を使いながら役割を分けられます。

HTML でも役割を分ける

見た目が同じでも、HTML まで同じにする必要はありません。別ページへ移動する「詳細を見る」にはリンクの <a>、その場で送信や絞り込みを行うものには <button> を使います。これにより、キーボードや読み上げソフトにも役割が伝わりやすくなります。

CSS を使えば、リンクとボタンをよく似た形にできます。それでも、共有しているのは見た目です。押した後の働きまで同じになったわけではありません。

4.4 類同の原則と一貫性

似たものを同じまとまりとして見やすい傾向を、類同の原則と呼びます。色、形、大きさ、向きなどが似ていると、離れていても仲間に見えることがあります。

文化祭サイトの「音楽」「演劇」「展示」が同じ形で並んでいれば、同じ種類の選択肢だと分かりやすくなります。Web デザインでは、このように同じ役割へ同じ表現を繰り返すことを、一貫性のあるデザインと呼びます。

ただし、類同の原則は、そろえれば何でも分かりやすくなるという決まりではありません。赤い丸が並んでいても、それが削除、エラー、飾りのどれなのかは、形だけでは決まりません。書かれた言葉や置かれた場所、押した後の結果も必要です。

また、重要な違いまで消してはいけません。普通の操作、選ばれている状態、押せない状態、危険な操作をすべて同じにすると、利用者は見分けられなくなります。一貫性とは、すべてを同じにすることではなく、同じ理由でそろえ、違う理由があるところだけを違わせることです。

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

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

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

最初に「音楽」という青いボタンを押すと、一覧が音楽企画だけに絞られます。

次に同じ外観の「演劇」を押すと、同じように一覧が絞られます。二回の経験から、この青い形は企画の種類を選ぶ操作だという規則が見えてきます。

その後で初めて「展示」を見ると、まだ押していなくても同じ結果を予想しやすくなります。画面は説明文だけでなく、外観と結果の反復によって使い方を教えています。

この三枚は、「二回使えば必ず覚える」と証明する図ではありません。覚えるまでの回数は人や画面によって変わります。ここで大切なのは、サイトが操作の繰り返しによって、自分自身の使い方を少しずつ教えていることです。

一貫性が破れたとき

もし四つ目だけ、同じ青い形なのにフィルターを解除したら、覚えた規則が裏切られます。間違えて押した人は、自分のせいだと思うかもしれません。しかし、同じ見た目で違う結果を隠していたのは画面の側です。

予想を裏切る表現が、いつも悪いわけではありません。削除や公開のように結果が大きく違う操作なら、あえて色や形を変えて注意を促すことがあります。その場合は、見た目だけに頼らず、「削除する」のような具体的な言葉や確認画面も使います。例外には、例外だと分かるだけの理由と手がかりが必要です。

4.6 共通部品で、同じ規則を守る

同じボタンをページごとに手作りすると、少しずつ違いが生まれます。あるページでは高さが 40 ピクセル、別のページでは 42 ピクセルというように、理由のない差が増えていきます。

そこで、同じ種類のボタンを共通部品として作ります。表示する言葉だけを入れ替えて使えば、高さ、内側の余白、角丸、キーボードで選んだときの輪郭などを同じ規則にできます。

色や余白の値へ名前を付け、複数の部品で共有する方法もあります。この名前付きの値をデザイントークンと呼びます。サイトの基本となる青へ名前を付ければ、その色を使う場所をまとめて見直せます。

ただし、共通部品やデザイントークンが、役割まで決めてくれるわけではありません。「詳しく見る」というリンクと「絞り込む」というボタンが同じ青を使っていても、HTML と押したあとの働きは異なります。共有する部分と、役割に合わせて分ける部分を選びます。

4.7 必要な違いは、きちんと見せる

選択中、押せない状態、読み込み中、エラー、成功は、普通の状態と同じ見た目では伝わりません。削除や公開も、気軽にやり直せる操作とは結果の重さが違います。このような差は、消すのではなく、はっきり見せる必要があります。

ただし、色だけに意味を背負わせないようにします。選択中ならチェック印や「選択中」という文字を添える。押せないなら、なぜ押せないのかを近くに書く。削除なら、赤くするだけでなく「削除する」と具体的に書き、必要なら確認や取り消しも用意する。色を見分けにくい人や読み上げソフトを使う人にも、同じ状態が伝わるようにします。

一つだけ違う部品を見つけたときは、すぐに色や形をそろえず、なぜ違うのかを考えます。役割や状態が違うなら、その差は必要かもしれません。同じ役割なのに理由の分からない差があるなら、CSS までたどって直します。一貫性とは、差を全部消すことではなく、必要な差だけが残っている状態です。

同じ役割には、同じ見た目と同じ結果を繰り返します。異なる役割には、言葉、形、置き場所のどれかで見分けられる差を残します。色だけをそろえること、外形までそろえること、HTML の部品をそろえることは別々に考えます。

次章へ

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

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

参考資料

• 入口: 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章　人間は、見えない線まで補ってしまう

画面のまとまりが伝わるか不安になると、何でも枠で囲みたくなります。カードを囲み、その中の項目も囲み、さらにページ全体を別の面へ載せる。こうして四角の中に四角が増えていきます。

けれども、人は描かれた線だけを見ているわけではありません。近いもの、端がそろったもの、同じ背景に載ったものから、線のない境界まで思い浮かべます。反対に、入力欄や選択中の項目では、実際の線が大切な手がかりになることもあります。

この章では、枠を減らすことを目標にはしません。見えていない境界を人がどう補うのかを知り、必要な線と、なくても伝わる線を分けます。

5.1 途切れた線から、形を思い浮かべる

図 5-1A では、円の右側が途切れています。それでも、ばらばらの二本の曲線ではなく、一つの円として見えやすいでしょう。

このように、途切れた輪郭をつないで一つの形として見ることを、閉合と呼びます。見えない線が本当に描かれているわけではありません。残った曲線が、円を思い浮かべるのに十分な手がかりになっています。

図 5-1B では、円の右側を長方形が覆っています。こちらは線が途切れただけでなく、手前の長方形の後ろへ円が続いているように見えます。

見えていない物体が、手前の物の後ろにも続いていると考えることを、遮蔽補完と呼びます。難しい名前を覚えるより、「途切れた線をつなぐこと」と「隠れた物の続きを考えること」は別だと分かれば十分です。

どんな線でも一つの形に見えるわけではありません。図 5-1C のように開いた部分が大きいと、どのように閉じるのかが分かりません。

人が形を補うのは、足りないものを自由に想像するからではありません。残っている線の向きや間隔から、続きが自然に決まりそうなときに補いやすくなります。

5.2 枠がなくても、一枚のカードに見える

Web サイトのカードも、外周線だけでまとまっているわけではありません。図 5-2A では、画像、見出し、説明が近くに置かれ、その周囲には広い余白があります。外周線がなくても、一組の情報として読めます。

図 5-2B では、同じ内容の後ろへ薄い背景を加えました。同じ色の面に載ったものが、一つの領域に属して見えます。

図 5-2C では、その面へ外周線も加えました。ページの背景とカードの色が近いときでも、カードが終わる位置をはっきり示せます。

最後の図が、いつも最も良いわけではありません。三枚の違いは、手がかりの強さです。静かな読み物なら余白だけで十分かもしれません。背景の近いカードが密集する画面なら、外周線が役立つかもしれません。

ここで大切なのは、まとまりに見えることと、押せることを混ぜないことです。一枚のカードに見えても、カード全体を押せるとは限りません。「詳しく見る」というリンクだけが操作できる場合もあります。操作できる場所は、言葉、形、マウスを重ねたときの変化、キーボードで選んだときの輪郭などで別に伝えます。

5.3 前にあるものと、後ろにあるもの

申し込みの途中で、小さな確認画面が手前に現れることがあります。元のページが暗くなり、白い確認画面だけが明るく残ると、どちらが今読むべき内容なのか分かりやすくなります。

手前に見える対象を図、その後ろへ続く部分を地と呼ぶことがあります。この画面では、白い確認画面が図、暗くなった元のページが地です。

ただし、見た目を暗くするだけでは足りません。確認画面を開いている間は、後ろのページを誤って押せないようにします。キーボードで操作する場所も確認画面の中に保ち、閉じたら元の場所へ戻します。これは静止画では確認できない、動作の設計です。

HTML の dialog 要素をモーダルとして開くと、ブラウザは後ろのページを操作できない状態にします。それでも、何を確認する画面なのか、戻るにはどこを押すのか、最初にどこが選ばれるのかは制作者が決めます。

5.4 コードの箱を、全部画面へ描かない

HTML では、位置をそろえるための入れ物が何段も重なることがあります。しかし、その入れ物すべてに背景や境界線を付ける必要はありません。

ページ全体、記事の一覧、一枚の記事、記事の中の画像というように、コード上では箱が入れ子になります。これを同じ太さの線で全部描くと、どのまとまりが大きく、どれがその中の一項目なのか分かりにくくなります。

大きなまとまりは広い余白や背景の違いで示し、入力欄には明確な輪郭を使う、といった分担ができます。コード上の入れ物と、読者に見せる境界は同じではありません。画面に必要なのは、コードの構造をすべて見せることではなく、内容と操作の関係を伝えることです。

5.5 消してはいけない境界もある

外周線を減らすと、画面がすっきり見えることがあります。しかし、何を消したのかによっては、操作できる場所や現在の状態まで分からなくなります。

図 5-7A1 では、白い面と青い輪郭が、メールアドレスを入力できる範囲を示しています。

図 5-7A2 では輪郭を消し、入力面を周囲と近い色にしました。ラベルは残っていますが、どこを押せば入力できるのかが弱くなります。

選択肢でも同じことが起きます。図 5-7B1 では、青い面と輪郭によって「会場で受け取る」という行全体が選ばれていると分かります。

図 5-7B2 では丸印だけを残しました。どちらが選ばれているかは分かりますが、文字を含む行全体を押せることは伝わりにくくなります。

境界線を残すかどうかは、「今風に見えるか」だけで決めません。次のどれを伝える線なのかを考えます。

• どこまでが一組の情報か
• どこを押したり入力したりできるか
• どの項目が選ばれているか
• エラーやキーボード操作の位置がどこか

余白や背景だけで十分に伝わる境界なら、線を弱められます。操作や状態を伝える唯一の手がかりなら、むやみに消せません。良い余白は、単に何も置かなかった場所ではなく、関係を伝えるために残した場所です。

次章へ

ここまでは、線、背景、余白という動かない手がかりを見てきました。しかし、画面の一部が動き始めると、そこへ目が向きやすくなります。

次章では、動きが何を伝え、どのような動きが読んでいる人を邪魔するのかを、実際に動く図で説明します。

参考資料

• 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.” HTML の dialog 要素についての仕様です。
• W3C WAI, “Dialog (Modal) Pattern.” キーボードでも使える確認画面を作るときの参考資料です。

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

文章を読んでいるとき、画面の端で何かが動けば、ついそちらを見ることがあります。変化したものへ気づくことは、現実の世界では危険を避けるためにも役立ちます。しかし Web サイトでは、読む内容と関係のない広告や飾りにも目が向いてしまいます。

動きそのものが悪いわけではありません。「保存する」を押したあとに表示が変われば、操作が届いたと分かります。メニューが横から現れれば、閉じていた領域が開いたと理解しやすくなります。

大切なのは、何を伝えるための動きなのか、動きが終わったあとにも結果が残るかです。この章では、静止画だけでは分からない内容を、実際に動く図で説明します。

6.1 画面の端で動き始める通知

最初の図では、中央に記事があり、右端に通知の一部が見えています。通知は動きません。

次の図では、同じ通知がしばらく止まったあと、左へ一度だけ動きます。動く向きを示す矢印は、読者の視線ではありません。通知そのものの移動方向です。

この図が表しているのは、読者の目の動きではありません。「前から見えていたものが、途中で動き始める」という画面上の変化です。研究では、この変化を動きの開始と呼びます。

動き始めたものへ注意が向く場合はありますが、誰もが必ず通知を見るとは限りません。通知を見ても、内容まで読んだとは限りません。この記事が読みにくくなったかどうかも、この図だけでは分かりません。

それでも、本文と関係のない通知が何度も動けば、読んでいる場所から注意を離すきっかけが増えます。反対に、送信結果のように今すぐ知らせたい変化なら、注意を向けることが役立ちます。動きを考えるときは、「目立ったか」だけでなく、「今の目的に必要な変化か」を見ます。

6.2 動きの大きさは、速さだけでは決まらない

同じ 300 ミリ秒のアニメーションでも、小さなアイコンが数ピクセル動く場合と、画面全体が端から端まで動く場合では、見え方が違います。

動きの印象には、少なくとも次の違いが関係します。

• 画面のどれくらい広い部分が動くか
• どこからどこまで移動するか
• 何秒かけて動くか
• 一度で止まるか、何度も繰り返すか
• 自分の操作で始まったか、勝手に始まったか

「横移動は疲れる」「ゆっくりなら安全」のように、方向や速さだけで決めることはできません。小さく一度だけ起きる変化と、画面の広い範囲で繰り返す変化は、同じ横移動でも別の体験です。

体調によって、大きな拡大や画面全体の移動に不快感を覚える人もいます。確かめるために強い動きを我慢してもらう必要はありません。動きを減らす設定を尊重し、すぐ止められるようにし、動かない表示でも内容を読めるようにします。

6.3 自動で切り替わる大きな写真

次の文化祭サイトでは、大きな写真が自動で横へ切り替わります。図は少し静止したあとに一度切り替わり、その状態を繰り返します。

同じ場所で複数の内容を切り替える部品を、カルーセルと呼びます。自動切替では、いつ次へ進むかをサイト側が決めます。短い見出しなら読み終えられる人も、長い説明や拡大した文字では間に合わない人もいます。

切替を 5 秒から 10 秒へ延ばしても、読む速さをサイトが決める点は変わりません。自動で切り替えない、停止ボタンを置く、前後の内容を自分で選べるようにする、といった方法なら、読む時間を利用者が決められます。

この図では、開催日時を読むことと写真の切替に直接の関係がありません。広い写真を自動で動かす前に、静止した一枚でも目的を達成できないかを考えます。

6.4 読み込み中を示す光

次の図では、出演者カードの形をした灰色の面を、明るい帯が繰り返し横切ります。この仮の形をスケルトン表示と呼びます。読み込み後に入る画像や文章の位置を、先に示すための表示です。

灰色の形は、これから画像や文章が入る位置を予告できます。しかし、光を流しても、読み込みが何パーセント進んだかは分かりません。失敗して止まっていても、同じ動きを続けられてしまいます。

読み込みが長引くなら、「出演者を読み込んでいます」という言葉を添えます。失敗したら、動きを止めて「読み込めませんでした」と伝え、もう一度試す操作を用意します。意味を伝えるのは光ではなく、最終的な内容と状態を示す言葉です。

光がなくても灰色の形で配置を予告できるなら、動きを減らす設定では帯を止められます。読み込み中であることは、短い文章でも残せます。

6.5 メニューが開いたことをつなげる

次の図では、メニューボタンを押したあと、画面幅いっぱいのメニューが右から入ります。小さな通知よりも、動く面積が大きい例です。

この動きには、「閉じていた別の領域が開いた」と伝える役割があります。ただし、動きが状態そのものではありません。動き終わったあとにメニュー項目が見え、閉じるボタンがあり、後ろのページを誤って操作できないことが必要です。

動きを減らす設定では、短い色の変化だけで表示したり、すぐ開いた状態へ切り替えたりできます。途中の移動を省いても、開いている状態と閉じている状態を区別できれば、メニューの意味は残ります。

6.6 保存できたことを知らせる

最後は、「条件を保存する」を押したあとに通知が現れる例です。通知は右から入り、しばらく表示されたあとに消えます。

この動きは、直前に行った保存操作と関係があります。利用者へ知らせたいのは、通知が右から来たことではなく、保存できたことです。実際に意味を伝えているのは「条件を保存しました」という文章です。

通知が画面の外から長い距離を移動しなくても、同じ場所へ静かに表示すれば結果は伝えられます。

数秒で消える通知を見逃すこともあります。あとから開ける操作履歴へ保存結果を残せば、見逃しても確認できます。

アニメーションを短くすることと、情報を消してよいことは別です。動きを減らしても、操作の結果を伝える文章と、必要なら再確認できる場所を残します。

6.7 動きを減らしたい人の設定を尊重する

OS には、画面の動きを減らす設定があります。Web サイトでは、CSS の prefers-reduced-motion を使うと、その希望を知ることができます。

設定が有効なときは、画面全体の移動、大きな拡大、繰り返す装飾などを止めたり、小さな変化へ置き換えたりします。ただし、アニメーションを無効にしたせいで、メニューが開かない、読み込み中のまま終わらない、といった状態にしてはいけません。

考える順序は単純です。

1. 動きが何を伝えているかを言葉にする。
2. 動き終わった状態だけでも、その意味が分かるようにする。
3. 動きを減らす設定では、移動や拡大を省く。
4. 結果を示す文章や状態は残す。

自動カルーセル、読み込み中の光、メニュー、保存通知は、どれも「アニメーション」です。しかし目的は同じではありません。目的と関係の薄い動きは止め、意味を助ける動きは小さくし、最後に文章や静止した状態を残します。

次章へ

動きは、画面の一部へ注意を向けます。動きがなくても、大きさや色の差によって、最初に見る場所は変わります。

次章では、見出し、本文、ボタンなどの強さをどう分けると、読む順序が伝わるのかを見ていきます。

参考資料

• Abrams and Christ, “Motion Onset Captures Attention,” 2003. 動き始めと注意の関係を扱った研究です。
• Smith and Abrams, “Motion onset really does capture attention,” 2018. 動き始めが注意へ与える影響を、条件を分けて調べています。
• W3C WAI, “Understanding Success Criterion 2.2.2: Pause, Stop, Hide.” 自動で動く内容を止める仕組みについての公式解説です。
• W3C WAI, “Understanding Success Criterion 2.3.3: Animation from Interactions.” 操作によって始まる動きを減らす考え方です。
• W3C, “Media Queries Level 5: prefers-reduced-motion.” 動きを減らす設定を CSS から知るための仕様です。
• W3C WAI, “Carousels Tutorial.” 自動切替の停止や前後操作を含むカルーセルの作り方です。

第7章　人間は、文字の形から声を感じる

同じ「ようこそ」という言葉でも、細い文字で小さく置く場合と、太い文字で大きく置く場合では、話しかけられ方が違うように感じます。本当に声が聞こえるわけではありません。文字の形や大きさが、声の調子のような印象を加えるという意味です。

Web サイトでは、ほとんどの情報を文字で伝えます。どの書体を選ぶかだけでなく、文字の大きさ、太さ、間隔、一行の長さ、見出しと本文の差が、読み方を変えます。

この章では、書体へ「元気」「上品」といった性格を決めつけません。実際に見えている太さや空白へ戻り、読みやすさと読む順序を作る方法を考えます。

7.1 同じ言葉でも、同じ強さには見えない

最初の三枚は、同じ歓迎の言葉です。文章の内容ではなく、文字の組み方だけを変えています。

文字が占める黒い面積が小さく、文字同士の間にも背景が見えます。静か、軽い、控えめと感じる人がいるかもしれません。

二枚目では黒い面積が増え、文字の隙間が小さくなりました。力強い、にぎやか、急いで伝えているように感じる人もいるでしょう。

三枚目は、文字そのものを大きくしています。堂々として見えるなら、その理由は書体だけではありません。画面の中で使っている面積も変わっています。

「太い書体は元気」と暗記すると、別の画面でうまく使えません。「太い線と狭い字間によって、黒い面が強く見える」と捉えれば、何を調整したのかが分かります。

印象は文字だけでも決まりません。同じ書体でも、歓迎の言葉に使うか、災害のお知らせに使うかで受け取り方は変わります。背景色、写真、周囲の余白も、文字の声を一緒に作ります。

7.2 一文字が読めても、文章が読みやすいとは限らない

一文字ずつ見分けられることと、長い文章を読み続けられることは別です。行が詰まりすぎたり、一行が長すぎたりすると、次に読む場所を見失いやすくなります。

図 7-3A は、行と行の間が狭い文章です。

文字は判別できても、行末から次の行頭へ戻るときに、どの行を読んでいたか分かりにくくなります。

図 7-3B では、文字サイズを変えず、行の間だけを広げています。

空白は飾りではなく、一行ずつを分ける働きをします。ただし、広すぎると同じ段落の行がばらばらに見えます。

図 7-3C は、行間を保ったまま文章の横幅を広げた例です。

行間と一行の長さは、別々の問題です。行間が狭い文章の横幅だけを短くしても、上下の詰まりは直りません。どこが読みにくいのかに合わせて調整します。

ブラウザでは、利用者が文字を大きくしたり、行間を広げたりできます。そのときに文字が切れたり、重なったり、ボタンが押せなくなったりしないことも大切です。完成した一枚だけでなく、文章が増えたり大きくなったりする画面までが Web デザインです。

7.3 文字の差が、読む順序を作る

文化祭の催しを紹介する画面には、催し名、日時、会場、説明、申込ボタンがあります。すべてを同じ大きさと太さで並べると、どこから読めばよいのか見た目から分かりません。

最も大きく太い「夕暮れの音楽会」が、このページの主題です。日時と会場は、そのすぐ下へ近づけて一組にしています。説明文の前には少し広い余白を取り、基本情報から長い文章へ切り替わることを示しています。

「申し込む」は青い面に入り、文章とは違う形です。説明の続きではなく、次にできる操作だと分かります。

読む順序は、大きさだけでは決まりません。太さ、色、前後の余白、左端のそろい方が一緒に働きます。すべてを同時に強くする必要もありません。大見出しを巨大にし、太くし、赤くし、さらに囲むと、ほかの情報が見つからなくなります。

大きいものが、いつも最重要とは限らない

催しの雰囲気を知りたい人には、大きな催し名が良い入口になります。開始時刻だけを急いで探している人には、日時の見つけやすさも必要です。

画面の主役を一つ作りながら、よく探される情報を埋もれさせないようにします。目立つ順序と、利用者が必要とする順序が大きく食い違っていないかを考えます。

見た目と HTML の見出しを合わせる

大きな文字が自動的に HTML の見出しになるわけではありません。HTML の h1 や h2 は文章の構造を伝え、CSS は見た目を作ります。

見た目では大見出しなのに HTML では普通の div だと、読み上げソフトから見出しとして探せません。反対に、HTML では見出しなのに本文と同じ見た目では、目で読む人が区切りを見つけにくくなります。見た目と HTML の両方で、同じ文章構造が伝わるようにします。

7.4 日本語と英語は、同じ数字でも同じ大きさに見えない

CSS で同じ文字サイズを指定しても、日本語と英語の見える大きさは同じにならないことがあります。

図の赤い点線は「文化祭」の見える輪郭、青い線は文字を並べる基準です。漢字は、文字に用意された四角い範囲を大きく使って見えます。

同じ文字サイズの「Festival」には、大文字と小文字が混ざります。日本語と同じ青い線へ置いても、見える輪郭の高さは同じになりません。

日本語の見出しの横へ英語を添えるとき、同じ font-size にするだけでは強さがそろわない場合があります。数字や記号、アイコンを横へ並べる場合も同じです。CSS の数値だけでなく、実際に見える大きさと上下の位置を見て調整します。

ただし、最初から一文字ずつ手でずらすのではありません。まず文字を並べる基準線で規則を作り、特定のアイコンだけがずれて見える場合に小さく補正します。

7.5 Web フォントが届く前にも、文字は表示される

デザインツールでは、選んだ書体が最初から表示されています。Web では、フォントのファイルがまだ届いていない時間や、取得に失敗した状態があります。

図 7-7A は、Web フォントが届く前に、端末へ入っている代わりの書体で表示した画面です。

完成時と同じ見た目ではありませんが、演目名も説明も隠れていません。この時点の文字幅で改行とボタンの幅が決まります。

図 7-7B は、Web フォントが届いたあとの画面です。

同じ文字列でも、一文字ごとの幅が違うため、改行やカードの高さが変わっています。その下にあるボタンも移動します。押そうとしていた場所が大きく動けば、誤って別のものを押す原因になります。

フォントを待つために文字を長く透明にするより、代替フォントで内容をすぐ表示します。そして、どちらの書体でも長い見出しがはみ出さず、ボタンの文字が切れず、切替時に周囲が大きく動かないように作ります。

美しい書体を選ぶことは大切です。しかし本文の読みやすさは、書体名だけでは決まりません。文字の大きさ、行間、一行の長さ、背景との明暗差、読み込み中の表示までを一緒に設計します。

次章へ

文字の大きさや太さは、読む順序を作ります。色もまた、目立つ場所を作り、同じ仲間や異なる状態を伝えます。

次章では、色の名前や好みだけで決めず、周囲との違いと、色以外に残す手がかりを考えます。

参考資料

• W3C, “CSS Fonts Module Level 4.” Web で書体を選び、代替書体へ切り替える仕組みの仕様です。
• W3C, “Requirements for Japanese Text Layout.” 日本語の横書き・縦書き・句読点などを扱う詳しい資料です。
• W3C WAI, “Understanding SC 1.4.12: Text Spacing.” 利用者が行間などを変えても内容を読めるようにする解説です。
• W3C WAI, “Understanding SC 1.4.4: Resize Text.” 文字を拡大したときの考え方です。
• WHATWG, “HTML Standard: Headings and Sections.” HTML の見出しが持つ意味を確認できます。

第8章　人間は、色を周りとの関係で見る

同じ赤でも、白い背景の上では暗く締まって見え、黒い背景の上では明るく浮いて見えることがあります。赤そのものは変わっていません。変わったのは周りの色です。

色は、見た目を楽しくするだけではありません。リンク、選択中、エラー、保存ボタンなどの違いを見つけやすくします。しかし、色だけへ意味を任せると、色の見え方や表示環境が変わったときに意味まで消えてしまいます。

この章では、色を単独の名前や好みで考えません。周囲との違い、画面での役割、色以外に残す手がかりを順に見ていきます。

8.1 同じ赤でも、周りが変わると違って見える

三枚の中央にある赤は、すべて同じ色、同じ大きさです。変えるのは背景だけです。

二枚目で変わったのは背景だけです。それでも赤の明るさや強さが違って感じられるなら、色を隣の色との関係で見ていることが分かります。

CSS に同じ色コードを書けば、画面に出る色の値は同じです。しかし、人が受け取る強さまで同じになるとは限りません。ボタンの色は実際のページ背景へ置き、文字色は実際に重なる面の上で確認します。

色を説明するときは、「赤だから目立つ」だけで終わらせません。背景より明るいのか暗いのか、周囲より鮮やかなのか、使う面積が大きいのかを言葉にすると、調整する場所が分かります。

8.2 同じ青でも、役割は形で分ける

一つのサイトで青を繰り返すと、利用者は青を操作や現在地の手がかりとして覚えることがあります。ただし、リンク、ボタン、選択中のタブを青だけで区別することはできません。

三つは同じ青を使っていますが、役割は異なります。リンクには下線、ボタンには面と動作名、タブには並びと現在地の線があります。色が見分けにくくても、形と置かれた場所から違いが残ります。

同じ部品の状態にも、色以外の手がかりが必要です。キーボードでボタンを選んだときは、ボタンの外側へ輪郭を加えます。

操作できないときは、色を薄くするだけでは理由が分かりません。文字まで薄くすれば、操作できない理由を読むことも難しくなります。

色は違いを見つける助けになります。何が違うのかを理解する手がかりは、形、言葉、位置にも残します。

8.3 文字と背景の明るさを比べる

文字と背景の明るさが近すぎると、文字の輪郭を追いにくくなります。Web アクセシビリティの指針である WCAG では、この差をコントラスト比という数値で確かめます。

次の三枚は、文字サイズ、太さ、背景を同じにし、文字の明るさだけを変えています。

コントラスト比は大切な確認です。しかし、画面全体の読みやすさを表す点数ではありません。基準を満たしていても、文字が小さすぎたり、細すぎたり、一行が長すぎたりすれば読みにくくなります。ボタンの意味やエラーの直し方が分かるかも別の問題です。

写真やグラデーションの上では、場所によって文字の後ろの色が変わります。明るい部分へ重なったときにも読めるかを確認します。文字だけでなく、入力欄の輪郭や選択中の印など、操作に必要な形と周囲の差も必要です。

8.4 入力エラーを、赤い枠だけで伝えない

次の画面は、郵便番号の入力欄を赤くしただけです。

赤を見分けられても、どこが間違いで、何を入力すればよいかまでは分かりません。「赤はエラー」というサイトの決まりを知らない人には、状態そのものも伝わらない可能性があります。

次の画面では、エラーの印と具体的な説明を加えています。

エラー文は「入力が正しくありません」だけでなく、「郵便番号は 7 桁の数字で入力してください」のように直し方を示します。色はエラーの場所を見つけやすくし、文章が内容を伝えます。

同じ考え方は、グラフやリンクにも使えます。グラフの線は色だけでなく実線と破線、点の形、線の近くにある名前で分けます。リンクには下線、選択中の項目には印や線を残します。

8.5 暗い画面は、色を反転するだけでは作れない

同じチケットを、三つの表示環境で見ます。

白と黒を入れ替えるだけでは、薄い境界が消えたり、鮮やかな色がまぶしく見えたりします。暗い背景の中でも、日付の枠、本文、ボタンが別の役割として残るように色を組み直します。

強制色表示では、利用者が選んだシステムの色へ置き換えられることがあります。背景色だけで作った区切りや、影だけで浮かせたボタンは消えるかもしれません。だから、文字、境界、部品の形を先に整え、色はそれらを助けるように使います。

色自体に、一つの意味が埋め込まれているわけでもありません。赤はエラーにも、祭りの飾りにも、値下げにも使われます。意味を決めるのは、近くにある言葉、形、置かれた場所です。

次章へ

色の差は、情報を見つける助けになります。しかし、情報が増えすぎると、どの色もどの見出しも同じように目立ち始めます。

次章では、一度に見せる情報の量をどう整えれば、必要なものを見つけやすくなるかを考えます。

参考資料

• W3C WAI, “Understanding SC 1.4.1: Use of Color.” 色だけへ意味を依存させないための公式解説です。
• W3C WAI, “Understanding SC 1.4.3: Contrast (Minimum).” 文字と背景のコントラスト比を確認できます。
• W3C WAI, “Understanding SC 1.4.11: Non-text Contrast.” 入力欄や状態を示す形のコントラストについての解説です。
• W3C, “CSS Color Module Level 4.” Web で扱う色の仕様です。
• W3C, “CSS Color Adjustment Module Level 1.” 強制色表示など、利用者の表示設定への対応を扱います。

第9章　人間は、部品ではなく画面全体を見る

一枚のカードだけを見ると、大きな見出しと鮮やかなボタンは分かりやすく見えます。ところが、同じカードを六枚並べると、すべてが「ここを見て」と主張し始めます。

Web サイトを作るときは、ヘッダー、カード、ボタンのような部品を一つずつ整えます。しかし、実際に見る人は完成したページ全体を見ます。部品同士の大きさ、余白、並び方が組み合わさり、最初に見つかる場所や読み進め方が変わります。

この章では、単に情報を減らすのではなく、ページの目的に合わせて強さと並びを整える方法を見ていきます。

9.1 一枚ではよくても、六枚では強すぎる

最初の図は、文化祭の演目カード一枚です。大きな見出しと青いボタンがあり、カードの中では役割が分かりやすく見えます。

しかし、このカードはページの中で繰り返して使われます。

青いボタンが六つ並ぶと、ページ上部の「文化祭へ申し込む」も、その中の一つに見えてしまいます。カードを直すときは、一枚だけでなく、実際に使う数と場所へ戻して見ます。

すべてのボタンを弱くすればよいわけでもありません。カードの詳細リンクは見つけられる強さを保ち、ページ全体の申込ボタンには、それよりはっきりした差を作ります。部品ごとの正しさではなく、役割同士の関係を整えます。

Web ページは、ポスターのような一枚の紙でもありません。画面幅、文字の大きさ、文章量によって、一度に見える範囲が変わります。最初の画面に何があり、スクロールすると何が現れるかまでをページ全体として考えます。

9.2 大きさの差が、読む順序を作る

次の三枚には、「文化祭」「開催日」「会場」という同じ情報があります。文字の大きさだけを変えています。

一定の倍率は、文字サイズの候補を作るには便利です。しかし、1.25 倍や黄金比を使えば、読む順序が自動で正しくなるわけではありません。

図 9-2C では、数学的にきれいな並びより情報の役割を優先しました。予定を探すページなら、開催日の方を強くする選択もあります。何を最初に伝えたいかを決め、それに合う差を作ります。

読む順序は大きさだけでも決まりません。太さ、色、位置、前後の余白も使えます。すべてを大きくして競わせるのではなく、必要な差だけを選びます。

9.3 情報が多くても、並びがそろえば比べやすい

情報が多い画面を見て、すぐに「減らした方がよい」とは決められません。予定表では、複数の時刻と会場を同時に比べられることが役立ちます。

次の二枚には、四つの催しについて、時刻、催し名、会場という同じ十二個の情報があります。

「17 時 30 分の催し」を探すとき、最初の画面では時刻の列だけを下へ追えます。二枚目では、カードごとに時刻の場所を探し直します。違いは情報の数ではなく、比較する位置がそろっているかです。

反対に、一画面にボタンが一つしかなくても、「続ける」のように押した結果が分からない名前なら迷います。情報を減らすことと、分かりやすくすることは同じではありません。目的に必要な情報を残し、まとまりと比較する場所を整えます。

9.4 グリッドの線より、情報の関係を優先する

グリッドは、そろえる位置と間隔をページ内で共有するための道具です。しかし、線にきれいにそろえただけで、情報の関係まで伝わるとは限りません。

図 9-8A もグリッドの線にはそろっています。しかし、日時と申込欄が離れているため、どの申込欄がどの日時に対応するのか弱くなっています。図 9-8B では、同じ列を使いながら関係するものを近づけました。

グリッドは目的ではありません。長い名前、翻訳された文章、文字の拡大、画面幅の変化へ対応しながら、内容の関係を保つために使います。

見た目の位置だけを CSS で並べ替えると、HTML の読む順番やキーボードで移動する順番と食い違う場合があります。モバイルで一列にするときも、目で見る順番と読み上げられる順番が大きくずれないようにします。

9.5 画像は、見出しの意味も変える

次の二枚は、どちらも「静かな夜の演奏会」という同じ見出しです。組み合わせる画像だけが異なります。

見出しは一文字も変えていません。それでも受け取り方が変わるのは、画像が文章にない場所や人物の様子を加えるからです。画像を飾りとして置くのではなく、文章と一緒に何を伝えるのかを考えます。

写真の上へ文字を置く場合は、画面幅にも注意します。PC では空いていた場所が、モバイルで写真を切り抜くと人物の顔や明るい部分へ重なることがあります。PC とモバイルは別々の図として確認し、その間の幅でも文字が読めるようにします。

9.6 同じ情報でも、目的が変われば構成は変わる

最後の三枚は、同じ文化祭情報を使った別々のページ案です。良い、普通、悪いという順番ではありません。優先する目的が異なります。

静かな鑑賞を優先した案です。同時に見える操作を減らし、作品を見る時間を作ります。その代わり、複数の日時を短時間で比べる用途には向きません。

日時の探索を優先した案です。情報量は多く見えますが、同じ場所を追って比較できます。大きな写真から雰囲気を感じる時間は少なくなります。

偶然の発見を優先した案です。大きさの変化が興味を引きますが、同じ場所を追って予定を比較する用途には向きません。

構成を決める前に、そのページで最初にしてほしいことを決めます。一つの催しを味わってほしいのか、予定を探してほしいのか、知らない催しを発見してほしいのか。目的が決まれば、何を大きくし、何を同時に見せ、何を次へ送るかを判断できます。

画面の中央へ置けば必ず注目される、右上へ置けば最初に見られる、といった万能の規則はありません。大きな面や強い色は目立ちやすくても、実際に探している情報によって見る場所は変わります。画面の釣り合いと、実際の視線の順序を同じものとして扱わないことが大切です。

次章へ

第1部では、近さ、整列、境界、動き、文字、色、画面全体の構成を見てきました。どれも、人が画面をどのように受け取るかに関わります。

次の第2部では、マウス、タッチ、キーボードなど、画面を操作する方法によって起きる違いを考えます。

参考資料

• W3C, “CSS Grid Layout Module Level 2.” 列や行を使ったレイアウトの仕様です。
• W3C WAI, “Understanding SC 1.4.10: Reflow.” 画面幅や拡大によってレイアウトが変わるときの考え方です。
• Locher et al., “Artists' Use of Compositional Balance for Creating Visual Displays,” 2001. 画面の釣り合いを扱った研究です。Web 画面の万能な配置規則ではありません。
• Müller-Brockmann, Grid Systems in Graphic Design. グラフィックデザインでグリッドを使う考え方を知る資料です。

第 I 部 統合ケース　三つの画面は、同じ目的ではない

ここまで、近いものはまとまって見えやすいこと、端や中心がそろうと関係を追いやすいこと、大きさや色が情報の強さを変えることなどを見てきました。この章では、それらを三つの実際的な画面へ戻します。

題材は、同じ文化祭です。ただし、三つの画面が助ける仕事は異なります。

一つ目は、展示作品に興味を持ってもらうための画面です。二つ目は、催しを比べてチケットを買うための画面です。三つ目は、文化祭の運営担当者が公開状況を確かめるための画面です。

同じ文化祭を扱っていても、必要な情報の順番は同じではありません。何のための画面かが変われば、主役にするもの、まとめるもの、目立たせるものも変わります。

作品をゆっくり見てもらう画面

最初は、展示作品を紹介する画面です。

この画面で最も広い場所を使っているのは作品画像です。題名や日時より先に作品の雰囲気が伝わるよう、画像のまわりにも広い余白があります。文字は画像と競わない大きさに抑えられています。

これは、情報が少ないから優れた画面なのではありません。作品を落ち着いて見てもらうという目的に合わせ、最初に必要な情報を絞った画面です。

一方で、開催日時を急いで探している人には不便かもしれません。日時を次の画面まで隠すのではなく、作品を邪魔しない位置に短く載せれば、静かな見た目と情報の見つけやすさを両立できます。

チケットを比べて買う画面

次は、催しを選んでチケットを買う画面です。

この画面では、大きな作品画像よりも、日時、価格、残席、購入ボタンが重要です。一つの催しに関係する情報を一枚のカードへまとめ、別の催しとの間を広く空けています。どの価格とどのボタンが同じ催しに属するかを、囲みと距離の両方で伝えています。

同じ形のカードを繰り返すと、同じ位置にある情報を縦に比べられます。上のカードで価格を見たあと、下のカードでも同じ場所を見れば価格が見つかります。

ただし、形をそろえるだけでは十分ではありません。この例では価格が大きく、残席は小さな文字で右端に置かれています。買えるかどうかを決める大切な情報なのに、価格から離れすぎています。この問題は、あとで詳しく直します。

公開状況を見守る画面

三つ目は、文化祭を運営する人が使う画面です。

運営担当者は、一つの作品を大きく見るのではなく、公開できていない催しや更新に失敗した催しを探します。そのため、画面には多くの行と列があります。

一見すると、前の二画面より忙しく見えます。しかし、情報が多いこと自体が失敗なのではありません。催し名は左、公開状態は中央、更新時刻と担当者は右というように、同じ種類の情報が同じ列へ並んでいます。このそろいがあるため、担当者は上下へ視線を動かして違いを探せます。

ここで余白を大きく増やすと、一度に見える催しが減り、かえって確認しづらくなることがあります。必要なのは、鑑賞画面のように静かにすることではなく、異常な状態と通常の状態を見分けやすくすることです。

大切な情報を、関係する場所へ置く

三画面のうち、購入画面には直したい箇所がありました。まず、変更前のカードを一枚だけ見ます。

価格は大きく太いため、すぐに見つかります。残席は小さく、価格から離れています。さらに、周囲の説明と似た強さなので、カードを急いで読んだときに通り過ぎやすい配置です。

残席だけを巨大にすれば、今度は催し名や価格より強くなりすぎます。赤くするだけでは、赤が見分けにくい人や色が置き換わる表示環境へ意味が残りません。

そこで、大きさを極端に変えず、価格の近くへ移します。

価格と残席は、どちらも購入を決める前に確かめたい情報です。二つを近づけると、視線をカードの端まで往復させなくても続けて読めます。「残席わずか」「売り切れ」のような言葉も残せば、色は意味そのものではなく、見つける助けとして使えます。

この修正で使ったのは、特別な公式ではありません。関係する情報を近づける、同じ種類の情報をそろえる、大切さに合った文字の強さを選ぶ、色だけへ意味を任せない、という第1部で見てきた考え方です。

よい画面は、目的によって姿が変わる

三つの画面を、余白の多さや情報量だけで順位づけることはできません。

展示紹介画面は、作品へ注意を向けるために広い余白を使います。購入画面は、催しを比べるために同じ形のカードを繰り返します。運映画面は、多くの状態を一度に確かめるために行と列を使います。

大切なのは、見た目を一つの正解へそろえることではありません。その画面で必要な情報が、必要な順番と強さで伝わることです。

画面を見て「すっきりしている」「ごちゃごちゃしている」と感じたら、そこで判断を終えず、何が広いのか、何が近いのか、どこがそろっているのか、どの情報が強いのかを言葉にします。すると、残すべき特徴と直すべき問題を分けて考えられるようになります。

第 II 部　人間は、そんなに処理できない

Web サイトを使っていると、目の前に書いてある情報を見落とすことがあります。前の画面で見た番号を忘れることも、似た選択肢の違いが分からなくなることもあります。小さなボタンを押そうとして、隣のボタンへ触れてしまうこともあります。

そんなとき、「もっと注意して見ればよかった」「覚えていない自分が悪い」と考えがちです。しかし、画面の作り方を変えることで防げる失敗もたくさんあります。

たとえば、文化祭の申し込み画面を考えてみましょう。

締切がページの端に小さく書かれていれば、見落とすかもしれません。前のページにしか整理番号がなければ、次のページへ進む間に忘れるかもしれません。三十個の催しが名前だけで並んでいれば、どれを選ぶか迷います。閉じるボタンと削除ボタンが小さく並んでいれば、揺れる電車の中で押し間違えるかもしれません。

これは、利用者の能力だけの問題ではありません。情報の置き方、選択肢の見せ方、ボタンの大きさ、使っている機器、周囲の環境が組み合わさって起きることです。

一つの難しそうな言葉で終わらせない

複雑な画面を見て、「認知負荷が高い」と説明することがあります。認知負荷とは、考えたり覚えたりするときに頭へかかる負担を表す言葉です。

便利な言葉ですが、それだけでは何を直せばよいか分かりません。

• 大切な情報が、強い広告に隠れて見つからない
• 前の画面の内容を、次の画面まで覚えておく必要がある
• 選択肢の違いが書かれておらず、比べられない
• ボタンが小さく、狙った場所を押しにくい
• 処理が終わったのか分からず、もう一度押してしまう

どれも「使うのが大変」という点は同じです。しかし、起きていることと直し方は違います。見つからないなら情報の強さや位置を見直します。覚え続けなければならないなら、必要な情報を同じ画面へ残します。違いを比べられないなら、選択肢の数だけでなく説明のそろえ方を直します。

第 II 部で見ていくこと

第10章では、目立つものと必要なものが同じとは限らないことを見ます。第11章では、覚えておく情報を画面の外へ追い出さない方法を考えます。第12章では、何もないところから思い出すより、見えている候補から選ぶ方が助けになる場面を扱います。

第13章では、選択肢が多いときに、分類、検索、絞り込みがどう役立つかを見ます。第14章では、マウスや指で操作する場所の大きさと距離を扱います。

研究で示された数字も登場しますが、「ボタンは必ずこの大きさ」「選択肢は必ずこの個数」と覚えるためではありません。誰が、何を使い、どのような場所で、何をしようとしたときの結果なのかを確かめながら読みます。

利用者を採点するのではなく、利用者と画面の間にどのような難しさが作られているかを見る。それが第 II 部の出発点です。

第10章　人間は、全部を同時には見られない

画面には、見出し、写真、ボタン、注意書き、広告が同時に並びます。それでも、私たちは全部を同じ強さでは見ていません。申し込みたいときはボタンを探し、開催日を知りたいときは数字を探します。

大きいもの、周囲と色が違うもの、動くものは目立ちやすくなります。しかし、目立つことと、その場面で必要なことは同じではありません。大きなキャンペーン画像が最初に目へ入っても、小さな「領収書を発行する」を探す助けにはなりません。

この章では、何を目立たせるかより先に、誰が何をしようとしている画面なのかを考えます。

10.1 画面にあっても、読まれるとは限らない

申込ページの上部に「受付は本日 17 時まで」と書いてあっても、利用者がすぐ入力欄へ進めば、締切を読まないかもしれません。

画面に表示されていること、目に入ること、意味を理解すること、あとで思い出せることは別です。「書いてあるから伝わる」とは限りません。

必要な情報は、必要になる場所へ置きます。締切は申込ボタンの近くへ、入力エラーの理由は問題のある入力欄の近くへ置きます。文字を大きくしたり赤くしたりする前に、情報と行動の関係を整えます。

全部を同時に見ないことは、能力不足でもありません。日時を探すときは数字や「開催日」という見出しが手がかりになります。申し込みたいときは「申し込む」という動作名を探します。目的に関係する情報へ注意を向けることで、行動を進めています。

10.2 大きさ、明暗差、位置は別々の手がかり

ボタンを目立たせる方法は、色を鮮やかにすることだけではありません。大きさ、背景との明暗差、周囲の内容との位置関係も影響します。

図 10-4C で大切なのは、画面の上や中央なら必ず目立つということではありません。申込内容の直後にあるボタンは、文章を読み終えた流れで見つけられます。離れた場所に置くと、同じ見た目でも探し直す必要があります。

「赤は目立つ」「大きければ見つかる」のように、一つの特徴だけを規則にしないようにします。赤いボタンが赤い背景の上にあれば差は弱くなります。大きな画像ばかりのページでは、一つだけを大きくしても区別できません。目立ちやすさは、対象と周囲の関係から生まれます。

10.3 強いボタンが複数あること自体は問題ではない

同じ画面に青いボタンが三つあると、「主要ボタンは一つにする」と言いたくなります。しかし、ボタンがどの範囲で、どの決定を表しているかによって意味は変わります。

「申し込む」「資料請求」「相談する」は、それぞれ異なる次の行動です。すべてが同じ強さで並ぶと、どれを選ぶ画面なのか分かりにくくなります。目的の違いを説明する、補助的な操作をリンクにする、次の段階へ移すといった整理が必要です。

こちらの三つは、各カードにある「詳細を見る」です。同じ決定が競っているのではなく、三つの対象へ同じ操作を繰り返しています。ボタンの個数だけで良し悪しを決めず、どのまとまりの中で何を選ぶのかを見ます。

10.4 目立つ広告は、探し物を助けない

次の設定画面で、利用者は「領収書を発行する」を探しています。中央には大きなキャンペーンバナーがあります。

広告は大きく、周囲と色も違うため、先に目へ入るかもしれません。しかし、領収書とは関係がありません。目立つことと、探しているものへ案内することは別です。

利用者は、見た目だけでなく言葉の意味や置かれそうな場所も使って探します。「領収書を発行する」なら、支払いや利用履歴に関する見出しの近くを探すでしょう。分かりやすい見出しの下へ置き、似た設定と同じ形でそろえることが助けになります。

10.5 締切は、申込操作の近くへ置く

イベントの内容を知る段階では、大きな出演者写真が良い入口になります。申し込む段階では、締切と申込ボタンの関係が重要になります。同じページでも、行動によって必要な情報が変わります。

ボタンだけを大きくしても、離れた締切は一緒に読めません。

二枚目では、写真、文字サイズ、ボタンの色を変えず、締切とボタンの距離だけを縮めました。「期限を確認してから申し込む」という一続きの行動が、一つのまとまりとして見えます。

何でも強くすれば、画面は「すべて重要」と叫び始めます。先に知る必要がある情報を操作の前へ置き、関係するものを近づけ、それでも見つけにくい場合に大きさや色を調整します。

「メリハリがない」という感想も、具体的に言い換えられます。「ページタイトルと小見出しの大きさが近い」「三つの異なる操作が同じ塗りボタンになっている」「締切と申込欄が離れている」と表せば、どこを直せばよいかが分かります。

次章へ

必要な情報が見つかっても、押す場所が小さすぎたり、指では届きにくかったりすれば操作できません。

次章では、マウス、タッチ、キーボードで操作するときに、同じ画面がどう変わるかを見ていきます。

参考資料

• Simons and Chabris, “Gorillas in our midst,” 1999. 目的へ注意を向けているときの見落としを扱った研究です。Web 画面の見落とし率へそのまま置き換えるものではありません。
• Itti and Koch, “Computational modelling of visual attention,” 2001. 周囲との差から目立ちやすさを考える研究の案内です。
• Folk, Remington and Johnston, “Involuntary covert orienting is contingent on attentional control settings,” 1992. 探す目的と注意の関係を扱います。

第11章　人間は、覚えながら操作すると間違えやすい

長いフォームの途中で、「さっき選んだプランはいくらだったかな」と前の画面へ戻ったことはないでしょうか。選んだ内容が次の画面から消えると、氏名や住所を入力しながら、プラン名や料金まで覚えていなければなりません。

必要な情報が画面に残っていれば、忘れても見直せます。電話番号の区切り、入力欄の近くにある書き方の例、注文内容と合計を並べた確認画面は、頭の中だけで覚え続けなくてもよいようにする工夫です。

この章では、画面の項目を機械的に減らすのではなく、いま何を覚えたまま、次の操作をしているのかを考えます。

11.1 電話番号は、区切ると照らし合わせやすい

次の二枚は、同じ電話番号です。一枚目は十桁が続いています。

数字の個数は変わっていません。空白によって記憶できる量が増えたわけでもありません。読み直す場所と、照らし合わせる単位が画面に見えるようになりました。

だからといって、電話番号の入力欄を三つへ分ければ必ず使いやすくなるわけではありません。番号全体の貼り付けや、スマートフォンの自動入力が使いにくくなる場合があります。一つの入力欄のまま、入力された数字を読みやすく表示する方法もあります。

見た目の区切りと、入力欄の分け方は別に考えます。

11.2 「七個まで」「四個まで」を画面の規則にしない

「人間が一度に覚えられるのは 7±2 個だから、メニューは七項目以下にする」という説明を見かけます。しかし、この数字は Web サイトのメニューを調べて得られたものではありません。短い時間だけ音や記号を覚える研究から広まった数字です。

メニュー項目が十二個でも、すべてが見えていて、意味の分かる見出しで分類され、何度でも見直せるなら、目的の項目を探せる場合があります。六個でも、「サービス」「ソリューション」のような違いの分かりにくい名前を覚えて階層を往復するなら迷います。

「四つのまとまりまで」という説明も、カードを四枚までにする規則ではありません。画面上のカードは、選ぶまで見直せます。短時間だけ見たあとに隠される記号とは、行っていることが違います。

大切なのは個数を特定の数字へ収めることではなく、次の点です。

• 候補の名前から違いが分かる
• 必要な間は画面に表示されている
• 多い場合は分類や検索で絞り込める
• 前の画面へ戻らなくても判断材料を見直せる

項目を七個へ収めるために、分かりにくい分類の中へ隠せば、かえって探しにくくなります。

11.3 覚えることと、考えることが重なる

確認コードを覚えるだけでも、時間がたてば忘れることがあります。そのコードを覚えたまま価格を計算したり、別の文章を読んだりすれば、さらに間違えやすくなります。

短い時間だけ情報を保つ働きを短期記憶、保った情報を使って判断や計算をする働きをワーキングメモリと呼ぶことがあります。名前を暗記する必要はありません。「覚えておくこと」と「いま考えること」が重なるほど大変になる、と捉えれば十分です。

画面側でできることは、必要な情報を消さないことです。六桁のコードなら入力欄の近くで見直せるようにする。人数を選ぶ画面なら、一人当たりの料金を残す。合計金額なら、人数の変更に合わせて更新し、計算の理由を読めるようにします。

説明も、使う場所の近くへ置きます。住所の書き方を読んでから、離れた入力欄まで覚えて移動させる必要はありません。エラーの理由は、問題のある入力欄の近くへ表示します。

11.4 情報が多い画面は、目的ごとに入口を変える

ダッシュボードには数値、警告、表が多く並びます。すべてを減らすと、一画面はすっきりしますが、業務に必要な比較までできなくなります。

同じ業務データでも、何をする画面なのかによって見せ方を変えられます。

監視画面では、普段見る状態をいつも同じ位置へ置きます。異常が起きた場所だけを強く示せば、すべての数値を順番に覚えて比べなくても変化を見つけられます。

一件の注文を探すときは、すべての小さな区画を眺める必要はありません。注文番号を入力する場所と、見つかった一件の状態を近くへ表示します。

店舗を比べるときは、名前と値を同じ位置、同じ幅の尺度へそろえます。一店舗ずつ開いて数値を覚えなくても、棒の長さを同時に比べられます。

情報量だけを問題にするのではなく、監視、探索、比較のどれを助ける画面なのかを決めます。

11.5 前の画面で決めたことを、次の画面にも残す

イベント申込を、プラン選択、情報入力、確認の三段階で見ます。

最初の画面では、プランの名前と一人当たりの価格を見て選びます。

次の画面では氏名や人数を入力します。ここでプラン名と価格が消えると、前の画面を覚えておくか、戻って確認しなければなりません。必要な情報だけを近くへ残し、人数が変われば合計も更新します。

確認画面には、入力した値と料金の計算根拠を同時に表示します。利用者は記憶から注文内容を作り直すのではなく、画面にある内容同士を照らし合わせられます。

前の画面にあったものを全部残す必要はありません。いま判断するために必要なプラン名、単価、人数、合計を選び、最新の状態で残します。

複数の画面へ分ければ、自動的に分かりやすくなるわけでもありません。前の情報が消え、比較するたびに往復するなら、覚えることは増えます。良い画面は、人の記憶力を試すのではなく、忘れても見直せるように作られています。

次章へ

必要な情報を画面へ残しても、押す場所が小さかったり、選択肢同士が近すぎたりすれば操作を間違えます。

次章では、マウスや指で目的の場所を選ぶときに、距離と大きさがどう関係するかを見ていきます。

参考資料

• Miller, “The Magical Number Seven, Plus or Minus Two,” 1956. 「七」という数字の元になった研究です。Web メニューの項目数を決める研究ではありません。
• Cowan, “The magical number 4 in short-term memory,” 2001. 短時間の記憶について、条件を分けて論じた研究です。
• Baddeley and Hitch, “Working Memory,” 1974. 情報を保ちながら考える働きを扱った研究です。
• Scaife and Rogers, “External cognition,” 1996. 画面など外にある情報が、考える作業をどう助けるかを扱います。

第12章　人間は、思い出すより手がかりから見つけやすい

知っている人の名前が出てこなくても、名簿を見ればすぐ分かることがあります。会場の正式名称を思い出せなくても、何文字か入力して候補が現れれば目的の場所を選べます。

何も見ずに答えを思い出すことを再生、表示された候補から知っているものを見つけることを再認と呼びます。名前を覚えるより、画面での違いが分かれば十分です。

ただし、候補を出せば必ず簡単になるわけではありません。似た名前が大量に並べば、今度は探して見分ける必要があります。この章では、必要な手がかりを、必要なときに見つけられる画面を考えます。

12.1 正式名称を思い出さなくても検索できる

利用者は会場名を正確には覚えていません。「し」から始まることだけを思い出し、検索欄へ「し」と入力しました。

何も表示が変わらなければ、検索中なのか、候補が一件もないのか分かりません。短い読み込みでも、候補を探している途中だと伝えます。

正式名称を一文字ずつ思い出す代わりに、候補を見て選べます。ただし「市民ホール」と「市民会館」のように名前が似ている場合は、地域や住所、会場の種類も必要です。

候補を取得できなかった場合に、空の一覧だけを表示してはいけません。「該当する会場がない」と「通信に失敗した」は別の状態です。失敗したことを伝え、もう一度試す操作を用意します。

入力欄と候補一覧を組み合わせた部品を、コンボボックスと呼びます。見た目だけでなく、キーボードでも候補へ移動できること、現在選んでいる候補が読み上げられること、失敗状態が分かることまで含めて作ります。

12.2 候補には、見分けるための情報を添える

会場検索の完成した画面を見ます。

利用者は最初に「市民」という二文字だけを思い出しました。候補が現れると、正式名称を思い出す作業から、地域と規模を見比べる作業へ変わります。

候補を増やしすぎると、長い一覧から探す負担が生まれます。数文字の入力で候補を絞り、見分けるために必要な情報だけを添えます。カテゴリーや現在地から絞り込める場合もあります。

自由入力を残した方がよい場面もあります。まだ登録されていない新しい会場を入力するときや、候補へ表示できない情報を扱う場合です。「候補から選ぶ」と「自由に入力する」のどちらか一方を、いつでも正解にはしません。

12.3 最近使ったものと、いまいる場所は別

画面へ手がかりを残す方法には、最近使った項目、履歴、パンくずリスト、手続きの進み具合などがあります。どれも同じものではありません。

「最近編集したイベント」は、直前まで扱っていた対象をもう一度見つけるための入口です。履歴は、それらをどの順番で見たり変更したりしたかをたどるために使います。

パンくずリストは、「組織 > イベント > 申込」のように、サイトの階層のどこにいるかを示します。「2 / 4 情報入力」という手順表示は、申し込みがどこまで進み、あとに何が残っているかを示します。

パンくずリストはブラウザの戻るボタンとも違います。通ってきた順番ではなく、サイト全体の中で現在のページがどこに属するかを示します。

最近使った項目には、プライバシーへの注意も必要です。共有端末へイベント名を残してよいか、いつ消すか、別のアカウントと混ざらないかを決めます。

12.4 入力したあとにも、項目名を残す

入力欄の中へ薄く表示される例文を、プレースホルダーと呼びます。例文は入力を始めると消えます。そのため、項目名をプレースホルダーだけへ任せてはいけません。

入力後には、連絡先のメールアドレスなのか、公開するメールアドレスなのか分かりません。書き方の例も消えています。

項目名、書き方の例、入力した値、エラーの説明には、それぞれ別の役割があります。項目名は入力後も見えるラベルとして残します。形式の指定が必要なら、その近くへ短く表示します。間違いがあれば、何をどう直すかを具体的に伝えます。

12.5 すべての候補を最初から並べなくてよい

「思い出させず、見て分かるようにする」は、すべての候補を最初から画面へ並べるという意味ではありません。候補が三十件、千件と増えれば、今度は長い一覧から探す作業になります。

最近使った項目から選べる、何文字か入力すると候補が現れる、カテゴリーで絞れる、必要な説明をその場で開ける、といった方法があります。必要になったとき、すぐ手がかりへたどり着けることが大切です。

候補には、選んだあとに何が起きるかも分かる名前を付けます。「登録済みの会場」と「過去に検索した言葉」を同じ見た目で混ぜると、選択後の結果を予想できません。種類が違う候補は、見出しや説明で分けます。

思い出すことを減らすと、探して見分ける作業が生まれます。どちらか一方をなくすのではなく、利用者が持っている少ない手がかりから、目的のものへ進める画面を作ります。

次章へ

候補が見つかっても、選択肢が多く似ていると、どれを選ぶか迷います。

次章では、選択肢の数だけでなく、違いの分かりやすさと、間違えたときに戻れるかを考えます。

参考資料

• Jakob Nielsen, “Recognition Rather Than Recall: Memory in User Interfaces.” 思い出す負担を減らし、画面上の手がかりを使う考え方の入口です。
• W3C WAI-ARIA APG, “Combobox Pattern.” キーボードや読み上げにも対応した候補一覧の作り方です。
• W3C WAI, “Form Instructions.” ラベル、説明、プレースホルダーを分ける理由を確認できます。
• W3C WAI-ARIA APG, “Breadcrumb Pattern.” サイト内の現在地を示すパンくずリストの実装例です。

第13章　人間は、違いの分からない選択肢に迷う

選択肢が三つなら簡単で、三十個なら難しい。そう言い切れそうですが、実際には数だけで決まりません。意味の分かる三十件から知っている名前を探すこともあれば、違いの分からない三つの料金プランに迷うこともあります。

選ぶときにしていることも同じではありません。知っている操作を押す、目的の会場を探す、複数の料金を比べて好みを決める。それぞれ必要な手がかりが異なります。

この章では、「七個以下」のような上限を作りません。違いを読めるか、候補を絞れるか、選んだ条件を見直せるかを考えます。

13.1 選択肢の数だけでは、難しさは決まらない

Hick–Hyman の法則は、決められた合図に対応するボタンを押す実験から、候補が増えると反応時間が長くなりやすい関係を表したものです。Web サイトのメニューを何個にするか調べた法則ではありません。

Web のメニューでは、「お知らせ」「開催予定」「申込履歴」といった意味を読み、どこへ進むかを予想します。よく使う項目の位置を覚えている人もいます。候補数だけを式へ入れて、使いやすさを決めることはできません。

「人間が一度に覚えられるのは 7±2 個だから、メニューは七項目以下」という説明も、別の記憶研究から数字だけを借りたものです。十二項目でも明確な見出しで分類され、すべてを見直せるなら探せる場合があります。六項目でも「サービス」「ソリューション」の違いが分からなければ迷います。

数を減らす前に、次を見ます。

• 名前から違いと行き先を予想できるか
• 似た候補を見分ける情報があるか
• 検索や条件で候補を絞れるか
• 選んだ条件と解除方法が見えているか
• 間違えても戻って選び直せるか

13.2 百件の会場を、名前と地域で絞る

同じ百件の会場でも、探し方があるかどうかで画面の使い方は変わります。

会場名を知っている人には、検索欄が役立ちます。

同じ名前を含む会場が複数ある場合は、地域の条件を加えます。

検索は、会場名の一部を知っている人に向いています。名前を知らず、「中央区にある百人以上のホール」という条件から探す人には、地域や広さで絞る方法が必要です。

検索できれば、百件でも必ず問題ないわけではありません。複数の会場を比べたいときは、一件ずつ開くより、広さや料金を同じ位置へ並べた方が分かりやすくなります。探すことと比べることでは、必要な画面が違います。

13.3 カテゴリー・絞り込み・並べ替えは別の操作

候補を探す三つの方法を、一つずつ見ます。

カテゴリーは、「会場 > ホール」のような階層をたどる方法です。どの種類に属するかを知っているときに役立ちます。

絞り込みは、「中央区」「百人以上」のような条件を組み合わせ、合わない候補を除く操作です。適用中の条件と、条件を一つずつ解除する方法を画面に残します。

並べ替えは候補を減らしません。「近い順」「料金が安い順」のように、同じ集合の順番を変えます。

部品の名前を覚えることより、利用者が何を知っているかを考えます。種類を知っていればカテゴリー、条件を知っていれば絞り込み、優先したいことが決まっていれば並べ替えが役立ちます。

13.4 画面を短くする方法は三つとも同じではない

設定項目が多いとき、すべてを表示する、詳細を折りたたむ、作業を段階に分けるという方法があります。

全表示では、画面が長くなる代わりに、前後の項目を同時に見比べられます。

折りたたみは、必要なときだけ詳細を開く方法です。しかし、閉じた中にエラーやよく使う項目があると、存在そのものを見落とす可能性があります。

段階分けは、決まった順番で進む作業に向いています。前の画面へ戻ったときに入力内容が残り、現在地と残りの手順が分かることが必要です。

画面を短くすることだけを目的にしません。必要な項目を見つけられるか、同時に比較する必要があるか、前の内容を覚えずに戻れるかで選びます。

13.5 三つしかなくても、違いが隠れていれば選べない

次の料金プランは三つだけです。しかし、名前の違いが現れる末尾を省略しています。

候補を二つへ減らしても、違いが読めなければ問題は残ります。

二枚目では、候補数、順序、月額、期間を変えず、プラン名だけを最後まで表示しました。さらに料金と期間が同じ位置にあるため、比較する場所を毎回探し直さずに済みます。

利用者がプラン名そのものを知らないなら、「学生向け」「一か月」「十二か月」のような説明も必要です。おすすめを付ける場合も、「人気だから」だけでなく、どんな人に向くのかを説明します。

選択肢が多いと迷うことはあります。しかし、万能な個数の上限はありません。数を見る前に、押すだけなのか、目的のものを探すのか、違いを比べて決めるのかを考えます。そして、名前、属性、絞り込み、並び、戻り道を整えます。

次章へ

選びたいものが決まっても、ボタンが小さかったり遠かったりすれば押しにくくなります。

次章では、マウスや指で対象を選ぶときに、距離と大きさがどう関係するかを見ていきます。

参考資料

• Hick, “On the rate of gain of information,” 1952. 選択反応時間を扱った研究です。Web メニューの項目上限を決める研究ではありません。
• Hyman, “Stimulus information as a determinant of reaction time,” 1953. 合図の確率と反応時間を扱います。
• Scheibehenne et al., “Can There Ever Be Too Many Options?,” 2010. 選択肢が多い場合の研究をまとめ、条件による違いを示した分析です。

第14章　人間は、小さく遠い場所を狙いにくい

画面の隅にある小さな×印が見えても、簡単に押せるとは限りません。マウスでは小さな場所へ矢印を合わせ、タッチでは指で直接触れます。キーボードでは、場所を狙わず順番に選択位置を移動します。

見えている記号の大きさ、実際に押せる範囲、キーボードで選ばれたことを示す輪郭は別のものです。この章では、同じ「閉じる」操作を三つの方法で見ながら、押しやすい画面を考えます。

14.1 マウス・指・キーボードでは、到達方法が違う

マウスでは、画面上の矢印を閉じるボタンまで動かします。

対象が遠く、小さくなるほど、矢印を正確に合わせるための移動が難しくなります。これは、遠くて小さい対象ほど到達に時間がかかりやすいという Fitts の法則から考えられる関係です。ただし、ボタンの意味を理解する時間までは説明しません。

タッチでは、画面へ指で直接触れます。

指先はマウスの矢印より大きく、触れている場所も隠します。小さな×印そのものだけでなく、その周囲を含めて押せるようにします。隣に別の操作がある場合は、指がずれても誤って押さない間隔が必要です。

キーボードでは、閉じるボタンの場所を狙いません。

Tab キーなどで選択位置を移し、目的のボタンへ到達してから実行します。いまどこが選ばれているかを示す輪郭と、自然な移動順が必要です。

同じ閉じる操作でも、マウスは小さな範囲を狙い、指は操作を覆い、キーボードは順番をたどります。三つを一つの「押しやすさ」という数値だけでは評価できません。

14.2 見える×印と、押せる範囲は別

閉じるボタンの×印を大きくしすぎると、画面の中で必要以上に目立つことがあります。しかし、見た目を小さく保ちながら、その周囲までボタンに含めることができます。

最初の例では、16 ピクセルの記号部分だけが反応します。

次の例では、×印の見た目は変えず、周囲まで押せるようにしています。

押せる範囲は、CSS の padding や最小サイズを使って広げられます。大切なのは手段の名前ではなく、HTML 上も一つのボタンになっていて、マウスでも指でも同じ範囲が反応することです。

ただし、見えない範囲を広げればよいとは限りません。

大きさと同時に、隣の操作との間隔を設計します。特に削除や送信のように結果が大きく違う操作は、近づけすぎません。間違えたときに取り消せる仕組みも必要です。

14.3 数字は確認の入口であり、唯一の答えではない

Web や各端末の設計資料には、操作対象の最小サイズについて異なる数字が示されています。数字は、見落としを防ぐための大切な確認項目です。しかし、単位や対象となる製品、例外条件が異なる数字を、そのまま一つの正解へまとめることはできません。

同じ CSS 上の大きさでも、画面の密度、拡大率、端末の大きさによって、指との比率は変わります。基準を満たしたことと、その画面で十分に操作しやすいことも同じではありません。

確認するときは、少なくとも次を見ます。

• 見えている記号ではなく、実際に反応する範囲
• 隣の操作までの間隔
• マウス、指、キーボードでの到達方法
• 文字を拡大したときの折り返し
• 間違えたときの取り消し方法

操作対象を広げたために、狭い画面でツールバーが二段になることもあります。これは失敗とは限りません。小さなボタンを無理に一列へ詰めるより、読みやすい順番で折り返す方が安全な場合があります。

14.4 ボタンを大きくする以外にもできること

押しやすさは、対象の大きさだけで決まりません。

一つ目は、よく使う操作を作業場所へ近づけることです。

どこにでも同じボタンを置くのではなく、結果と関係する場所へ置きます。

二つ目は、操作の位置を安定させることです。

内容によって保存ボタンの位置が飛び回ると、押す前に毎回探さなければなりません。画面幅が変わる場合でも、操作と内容の関係は保ちます。

三つ目は、別の操作方法も用意することです。

ショートカットだけへ頼ると、知らない人には使えません。画面上のボタンを残し、メニューなどへショートカットを併記します。見て選ぶ方法と、覚えて素早く使う方法の両方を用意します。

小さなアイコンをすべて巨大にするのではなく、押せる範囲、間隔、距離、位置、別の操作方法を組み合わせます。スクリーンリーダーからも意味が分かるように、×印だけでなく「閉じる」という操作名を付けることも必要です。

次章へ

操作しやすい場所にボタンがあっても、押したあとに何が起きたか分からなければ、利用者はもう一度押すかもしれません。

次章では、操作を受け付けたこと、処理中であること、成功や失敗をどう返すかを見ていきます。

参考資料

• Fitts, “The information capacity of the human motor system in controlling the amplitude of movement,” 1954. 距離と対象幅、速度と正確さの関係を扱った研究です。
• W3C WAI, “Understanding Success Criterion 2.5.8: Target Size (Minimum).” Web の操作対象サイズについて、例外を含めて説明しています。
• Android Accessibility Help, “Touch target size.” Android アプリのタッチ対象についての案内です。Web とは単位と対象が異なります。

第 II 部統合ケース　同じ目的でも、操作のしかたは変わる

第 10〜14 章では、注意、記憶、再認、選択、操作対象までの移動を見てきました。ここでは、イベントを探して申し込む同じ目的を、四つの利用状況から見ます。

どれが一番優れているかを決める話ではありません。人、機器、入力方法、周囲の環境が変わると、同じ画面でも困る場所が変わることを読み解きます。

1　マウスでは、見つけてからポインターを動かす

机の上でマウスを使うときは、まず押したい場所を見つけます。次に、画面上の矢印であるポインターをその場所まで動かし、クリックします。押す場所が小さければ、その範囲へ矢印を合わせる動きも慎重になります。

2　片手のタッチでは、指と揺れが加わる

移動中にスマートフォンを片手で使うと、体と一緒に画面も揺れます。マウスの矢印と違い、指は触れようとしている場所を隠します。持ち方によって、親指が楽に届く場所も変わります。

これは「タッチを使う人は不器用」という話ではありません。小さく隣り合う操作と、揺れる環境の組み合わせが誤操作を起こしやすくします。

3　キーボードでは、順番にたどる

キーボードでは、Tab キーなどを押して、リンクやボタンを順番に移動します。いま操作できる場所を示す印が「フォーカス」です。図の青い輪郭が、その印です。

見た目では隣り合う二つのボタンでも、HTML に書かれた順番が離れていれば、何度も Tab キーを押さなければたどり着けません。青い輪郭を消してしまうと、今どこにいるのかも分からなくなります。

4　スクリーンリーダーでは、構造を聞いて進む

スクリーンリーダーは、画面の内容を音声や点字で伝えるソフトウェアです。見出し、リンク、ボタンなどの名前と役割、選択中やエラーなどの状態を読み取ります。色や位置だけで示した関係は、そのままでは伝わりません。

マウスの移動時間と読み上げ時間を、そのまま同じ速さとして比べることはできません。目的は同じでも、対象を見つけ、到達し、確認する方法が違うからです。

5　誤操作は、起きやすさだけで決まらない

次の画面では、「閉じる」と「削除する」の見た目は離れています。しかし、実際に指へ反応する範囲が重なっています。指が境界付近へ触れたとき、どちらが実行されるのか分かりにくい設計です。

削除に触れると、商品が一覧から消えました。誤操作が何度起きるかだけでなく、起きたときに何を失うかも重要です。

削除後に「元に戻す」があれば、誤操作へ気づいた人は回復できます。

取り消す操作がなければ、同じ押し間違いでも影響は大きくなります。特に、元へ戻せない削除や支払いの確定では、確認画面を置く、危険な操作を離す、実行前に結果を具体的に書くなど、間違いを防ぐ手がかりも必要です。

6　一つの改善を、別の条件でも見る

指へ反応する範囲の重なりをなくせば、どちらの操作へ触れたのかが明確になります。ただし、間隔を広げるために画面上部の操作列を何段にも増やすと、今度は本文を読む場所が狭くなります。

一つの条件で改善しても、別の人や入力方法へ負担を移していないかを見ます。すべてを「タッチだから」「記憶力が足りないから」と人の能力へ戻さず、画面、機器、環境の組み合わせとして考えます。

第 II 部で扱った注意、記憶、選択、操作は、別々の法則として働くのではありません。現実の利用場面では重なり合います。だからこそ、誰が、何を使い、どんな場所で、何をしようとしているかへ戻ることが大切です。

第 III 部　人間は、勝手に予想する

初めて開いた Web サイトでも、私たちは何も分からない状態から始めるわけではありません。

虫眼鏡の印を見れば、検索ができそうだと思います。下線のある文字を見れば、押すと別のページへ進みそうだと思います。買い物かごの印を見れば、選んだ商品が入っていそうだと思います。

まだ押していなくても、過去に使った別のサイトを手がかりにして、次に起こることを予想しているのです。

この予想が当たれば、初めてのサイトでも迷わず使えます。反対に、見た目から想像した結果と実際の動きが違えば、利用者は立ち止まります。

たとえば、「戻る」と書かれたボタンを押したのに、入力した内容がすべて消えたらどうでしょう。青いボタンが三つの画面で「次へ進む」を表していたのに、四つ目の画面だけ「すべて削除する」になったらどうでしょう。同じ見た目を信じて操作した人ほど、間違えやすくなります。

画面の中でも、使い方を覚えていく

予想は、ほかのサイトで覚えた使い方から生まれるだけではありません。一つのサイトを使っている間にも、新しい規則を覚えていきます。

同じ位置にある青いボタンが何度も「申し込む」という働きをすれば、次の画面でも同じだろうと考えます。同じ形のカードを押すたびに詳しい内容が開けば、その形を「詳しく見る場所」として覚えます。

デザインの一貫性が大切なのは、すべてを同じ見た目にするためではありません。同じ見た目と同じ働きを結びつけ、次に起こることを予想できるようにするためです。

もちろん、例外が必要なこともあります。危険な操作や緊急のお知らせは、通常の操作と違って見える方がよいでしょう。その場合は、色だけを突然変えるのではなく、何が違うのか、押すと何が起きるのかを言葉でも伝えます。

操作したあとの返事も、予想を作る

ボタンを押したあと、何も変わらなければ、押せたのかどうか分かりません。もう一度押してよいのか、待つべきなのかも判断できません。

反対に、「送信中」「申し込みが完了しました」「通信できませんでした」と画面が返事をすれば、起きたことと次にできることが分かります。このような画面からの返事を、フィードバックと呼びます。

第15章では、利用者が画面へ持ち込む予想を見ます。第16章では、操作できそうな見た目と実際の働きが合っているかを考えます。第17章では、同じ見た目と働きを繰り返す意味を扱います。第18章では、操作後の返事が、成功、失敗、処理中をどう伝えるかを見ます。

「直感的だから」「普通はこうだから」で説明を終えず、どの見た目が、どの経験と結びつき、どの結果を予想させたのかを順に見ていきます。

第15章　人間は、知っている使い方を新しい画面へ持ち込む

初めて訪れたサイトでも、ロゴを押せばトップページへ戻る、下線付きの文字は別のページを開く、虫眼鏡は検索だと予想します。初めて見る画面にも、過去に使ったサイトや端末の経験を持ち込んでいます。

「直感的だった」という言葉だけでは、なぜ使えたのか分かりません。前に似た操作を使ったからかもしれません。ボタンの名前が分かりやすかったからかもしれません。一度失敗したあとに覚えたのかもしれません。

この章では、使い慣れた操作を借りることと、独自の表現を作ることを分けて考えます。

15.1 見た目から、押したあとの結果を予想する

サイトの左上にあるロゴを見ると、トップページへ戻る入口だと予想する人がいます。

文章中の下線付き文字には、別のページへ進む働きを予想します。

虫眼鏡の印には、検索欄を開く、または入力した言葉で検索する働きを予想します。

この予想は、形から自然に生まれたものではありません。別のサイトやアプリで、同じ形と結果を何度も経験したために生まれます。

誰にとっても同じ「普通」があるわけでもありません。スマートフォンの戻る方法は端末によって異なります。「申請のあとに上司が承認する」といった順序は、その仕事を知る人にしか分かりません。誰の経験を借りている画面なのかを考えます。

15.2 利用者は、次に起きることを予想して押す

文化祭の申込画面に「演目を選ぶ」という見出しと「次へ」ボタンがあれば、押したあとは連絡先の入力へ進むと予想できます。「2 / 3 連絡先」と表示されれば、最後にもう一段階あることも分かります。

利用者には、サイト内部のプログラムは見えません。見出し、ボタンの名前、現在の段階、操作後のメッセージから、「押したら何が起きるか」「戻ったら入力内容は残るか」を考えます。

このように、仕組みについて頭の中に作る予想をメンタルモデルと呼びます。サイトの中身を正確に知ることではありません。次に起きることをだいたい予想でき、外れたときに画面から修正できる状態です。

「次へ」のような名前だけでは、次に何があるか分からない場合もあります。ページの見出しや手順表示と組み合わせ、行き先を予想できるようにします。削除や購入のように結果が大きい操作では、「実行」のような曖昧な言葉を避け、何が起きるかをボタン名へ書きます。

15.3 見た目をまねるのではなく、結果のつながりを借りる

利用者は、ほかのサイトで覚えた使い方を新しいサイトにも持ち込みます。見慣れた操作なら、使い方を一から覚え直さずに済みます。

ただし、ほかのサイトの色や形をそのままコピーするという意味ではありません。借りたいのは、次のような操作と結果のつながりです。

• ロゴを押すとトップへ戻る
• 下線付きの文字から別の内容へ進む
• 入力に失敗した理由が、その入力欄の近くへ出る
• 戻っても、入力した内容が残る
• 閉じる操作には「閉じる」という名前がある

ブランドの色、写真、文字、余白、言葉遣いには独自性を持たせられます。購入、閉じる、戻る、エラーからやり直す方法まで独自にすると、使い方を覚える手間と、失敗したときの危険が増えます。

独自性を、何を見せるかと、どう操作するかに分けます。見たことのない美しい演出を使っても、申込ボタンの名前と結果は分かりやすくできます。

15.4 長押しだけの操作は、入口が見えない

次のイベントカードは、長押しすると保存や共有のメニューを開けます。しかし、画面上には長押しできる手がかりがありません。

カードを一度押せると分かっても、長押しという方法まで予想できるとは限りません。偶然長押しして成功しても、入口が分かりやすかった証拠にはなりません。

同じメニューを開く、見えるボタンを加えます。

長押しを知っている人はそのまま使え、知らない人はボタンから進めます。入口を二つにするため、画面上の操作は一つ増えます。それでも、保存や共有が重要なら、見つけられることを優先できます。

ボタンを押すと、操作名の分かるメニューが開きます。

保存を選んだあとには、結果を伝えます。

この流れには、入口を見つける、操作名から結果を予想する、保存結果を理解するという別々の段階があります。「直感的だった」という一言へまとめると、どこで迷ったのか分かりません。

独自の操作が悪いわけではありません。新しい操作そのものが製品の魅力で、安全に試せ、失敗しても戻れるなら、覚える価値がある場合もあります。ただし「普通の人なら分かる」とは決めつけず、初めての人にも見える入口と結果を用意します。

次章へ

画面から次の結果を予想できても、押したあとに反応がなければ、その予想が合っていたか分かりません。

次章では、操作を受け付けたこと、処理中であること、成功や失敗を画面から返す方法を見ていきます。

参考資料

• Norman, “Some Observations on Mental Models,” 1983. 人が仕組みについて作る、不完全で変化する理解を扱った研究です。
• ISO 9241-110:2020. 利用者が持つ予想と操作の関係を考えるための人間工学規格です。
• Nielsen Norman Group, “Jakob’s Law of Internet User Experience.” 他のサイトで得た経験を持ち込むという UX の経験則です。

第16章　人間は、同じ見た目に同じ働きを予想する

青い下線付きの文字を何度か押して別のページへ進めたら、次の青い下線付き文字にもリンクの働きを予想します。同じ形のカード、同じ位置のボタン、同じ色の状態表示が繰り返されると、画面の規則が見えてきます。

反対に、一つだけ違うものは目立ちます。しかし、目立ったからといって、なぜ違うのかまで分かるとは限りません。おすすめ、選択中、残りわずか、古い CSS の残り。理由は見た目だけでは決まりません。

この章では、同じ役割を同じ手がかりで繰り返し、必要な例外へ理由を添える方法を考えます。

16.1 反復が、画面の使い方を教える

ナビゲーションの項目が同じ文字と間隔で並べば、同じ種類の移動先だと分かります。設定画面の各行で、名前が左、現在の値が中央、変更ボタンが右に並べば、次の行でも同じ位置に操作があると予想できます。

反復されるのは、色だけではありません。

• 同じ役割の文字サイズと太さ
• 同じ種類のカードの画像比率
• 各行の名前と操作の位置
• 選択中を示す線や印
• 操作後に結果を返す場所

実装で同じ部品を使うことは、規則を守る助けになります。しかし、同じ部品でも長い名前で崩れたり、特定の状態だけ別の CSS が当たったりすれば、利用者には同じ規則として見えません。大切なのは、コード上の名前ではなく、最終的に画面へ現れた結果です。

16.2 一つだけ違えば目立つが、意味までは分からない

次の一覧では、六つの催し名のうち「演劇」だけが赤く大きくなっています。

おすすめなのか、現在選ばれているのか、残席が少ないのか、文字の設定を直し忘れたのか判断できません。

一つだけ違うものが記憶に残りやすくなる現象は、孤立項効果という言葉で説明されることがあります。ただし、「目立つものは必ず選ばれる」という法則ではありません。違いに気づくことと、その意味を理解すること、選ぶことは別です。

差を付けるなら、「おすすめ」「選択中」「残り 3 席」のような言葉や、置かれた場所から理由が分かるようにします。

16.3 申込・削除・選択中・通知は別の意味

画面で周囲と違って見せたいものには、さまざまな役割があります。

申込ボタンと削除ボタンは、どちらも強く見せる理由があります。しかし、同じ強い色と形にすると、進む操作と危険な操作の違いが弱くなります。削除には具体的な操作名と確認、必要なら取り消しを用意します。

選択中は現在地、残席は情報です。どちらもボタンとは限りません。色だけに意味を任せず、言葉、線、印、位置から役割を見分けられるようにします。

すべてを同じ「目立たせたいもの」として扱うと、画面内の差と意味の対応が分からなくなります。何を知らせる差なのかを先に決めます。

16.4 予想と結果が違うと、利用者は独自規則を覚える

青い文字をリンクだと予想して押したのに何も起きず、行全体を押したら移動できたとします。次に似た一覧を開いたとき、利用者は最初から行全体を押すかもしれません。このサイト独自の規則を、失敗から覚えたためです。

しかし、失敗を繰り返させて覚えてもらえばよいわけではありません。行全体が押せるなら、マウスを重ねたときやキーボードで選んだときに、行全体の輪郭や背景を変えます。操作後には、移動したことや保存できたことをはっきり返します。

規則は、説明文だけで教えるものでもありません。同じ見た目と同じ結果を繰り返すことで、次の操作を予想できるようになります。

16.5 例外には、見た目の差だけでなく理由を添える

次の商品一覧では、一件だけボタンの形と「今すぐ購入」という言葉が違います。

期間限定なのか、予約商品なのか、特におすすめなのか判断できません。もし古いボタン部品が残っただけなら、意図した例外ですらありません。

次の図では、商品の種類が違うことをラベルで示し、操作の形はそろえています。

「予約商品」という言葉が違いの理由を伝え、「詳細を見る」という同じボタンが共通の操作を伝えます。

例外の個数に決まった上限はありません。ただし、主要、セール、新着、警告、選択中をすべて異なる強い色で同時に示せば、どの差が何を意味するのか学びにくくなります。

通常の規則をまず繰り返し、本当に必要な違いだけを残します。そして、見た目の差だけで意味を当てさせず、理由を読めるようにします。

次章へ

同じ操作へ同じ見た目を使えば、押したあとの結果も予想しやすくなります。しかし、処理中や失敗の表示が曖昧なら、もう一度押してよいか分かりません。

次章では、操作を受け付けたことと、処理の結果をどのように返すかを見ていきます。

参考資料

• Hunt, “The subtlety of distinctiveness: What von Restorff really did,” 1995. 一つだけ異なるものに関する研究が、単純な「目立てば選ばれる」という話ではないことを整理しています。
• W3C WAI, “Understanding SC 1.4.1: Use of Color.” 色だけに意味を任せないための解説です。
• WAI-ARIA 1.2, “aria-current.” 現在地や選択状態を支援技術へ伝える仕様です。

第17章　人間は、押したあとに反応を待つ

ボタンを押したあとに何も変わらなければ、押せなかったのか、処理中なのか、失敗したのか分かりません。利用者はもう一度押し、前の画面へ戻り、操作を諦めるかもしれません。

必要なのは、派手なアニメーションではありません。操作を受け付けたこと、いま何を待っているか、最後に何が起きたか、次に何ができるかを伝えることです。

この章では、保存と申し込みを例に、操作後の時間を順に見ていきます。

17.1 ボタンがへこむことと、保存できることは別

マウスで押している間にボタンがへこんだり、指を触れた瞬間に色が変わったりすることがあります。これは「いまこのボタンへ触れている」という反応です。データが保存できたことまでは表しません。

保存には、少なくとも次の状態があります。

保存中は、押せたか分からない状態ではありません。処理が続いていることを文字で示します。何を保存しているのかも分かるようにします。

完了メッセージは、どの内容が保存されたか、次に何ができるかを理解できる場所へ置きます。短時間で消える通知だけでなく、必要なら更新時刻や履歴からも確認できるようにします。

保存後にもう一度編集すれば、状態は再び変わります。

一度「保存しました」と表示したままにすると、最新の変更まで保存済みだと誤解されます。内容が変わった時点で、状態表示も「未保存」へ更新します。

アニメーションは、これらの変化をつなげて見せる方法の一つです。動きを止めても、「保存中」「保存しました」「未保存」という意味が文字と最終状態から分かるようにします。

17.2 反応がないと、同じ操作をもう一度押してしまう

申し込みの送信に数秒かかるとします。押したあとに画面が変わらなければ、利用者は押せなかったと思って、もう一度押すかもしれません。

画面側では、送信を受け付けた直後に処理中だと伝えます。

ボタンを押せない状態にする場合も、薄い色だけでは理由が分かりません。「申し込み中」のように現在の処理を表示します。通信を中止できるなら、その方法も示します。

しかし、画面側で再操作を防ぐだけでは十分ではありません。通信が途中で切れ、利用者がページを開き直して再送する場合があります。

注文や決済では、同じ依頼を区別する番号などを使い、再送されても二重処理にならない仕組みが必要です。画面の「処理中」と、サーバーが一度だけ処理する仕組みは、別々の対策です。

結果が届いたか分からない場合は、すぐに同じ注文を作り直させません。「結果を確認しています」と伝え、すでに処理されたかを調べます。検索のように繰り返しても影響が小さい操作なら、すぐ再試行できる方が分かりやすい場合もあります。

17.3 処理中と、進み具合が分かる状態は違う

くるくる回る印は、処理が続いていることを伝えられます。しかし、何割終わったかは分かりません。

何を待っているのかを「会場情報を読み込んでいます」のように書きます。長く続く場合は、中止や別の作業へ進む方法も考えます。

全体量を測れる処理なら、実際の進み具合を示せます。

根拠のない進捗率を表示すると、99 パーセントで長く止まったときに、いつ終わるかを予想できません。測れるものだけを進捗として示します。

スケルトン表示は、文章や画像が入る場所を薄い形で先に示す方法です。配置の予告にはなりますが、処理の完了率は示しません。第6章で見たように、繰り返す光を付けなくても「読み込み中」という意味は残せます。

17.4 失敗したら、理由と戻り道を示す

「保存できませんでした」だけでは、次に何をすればよいか分かりません。通信が切れたなら再試行、入力内容に問題があるなら修正、権限がないなら権限を持つ人への依頼など、原因によって次の行動は変わります。

失敗したときにも、入力した内容を消しません。問題のある入力欄の近くへ、理由と直し方を表示します。画面の上部へエラーのまとめを置く場合は、各項目へ移動できるようにします。

サーバーの確定を待たず、手元の画面だけを先に成功したように変える方法もあります。すぐ反応して見えますが、実際の処理が早くなったわけではありません。失敗したら表示を戻す、未送信として残す、再試行できるようにする、といった回復が必要です。

金銭、在庫、権限のように、成功したという誤表示の影響が大きい操作では、確定前に成功を見せることへ慎重になります。

17.5 画面を見ていない人にも状態を伝える

画面に「保存しました」と表示しても、画面を読み上げて使う人へ自動で伝わるとは限りません。通常の完了は、現在の操作位置を奪わず、状態メッセージとして読み上げられるようにします。

すぐ対応が必要な失敗は、より強い通知として伝えます。ただし、すべての更新を警告にすると、読み上げが何度も割り込んで作業を邪魔します。通常の完了と、いま直す必要がある失敗を分けます。

見た目の色、実際に操作できる状態、支援技術へ伝わる状態は別々に作ります。色だけを変えたり、画面の端へ文字を追加したりするだけでは、全員に状態が届くとは限りません。

操作後の反応は、「押せた」という一瞬だけでは終わりません。受付、処理中、成功または失敗、次にできることまでを、時間の順に伝えます。

次章へ

操作の結果が分かっても、うまくいかなかった理由を利用者のせいにすれば、同じ失敗を繰り返します。

次章では、失敗を防ぎ、起きたあとに安全に戻れる画面を考えます。

参考資料

• W3C WAI, “Understanding SC 4.1.3: Status Messages.” 操作位置を移さずに、処理結果を支援技術へ伝える方法の解説です。
• WAI-ARIA 1.2, “status role.” 通常の状態メッセージを伝える役割の仕様です。
• WHATWG, “The progress element.” 測定できる進捗と、終了量が不明な状態を表す HTML 要素です。

第18章　人間は、自分が知っていることを忘れられない

自分で作った画面は、自分には分かりやすく見えます。ボタンを押したあとに何が起きるかも、見慣れない言葉の意味も、作った本人はすでに知っているからです。

しかし、初めて訪れた人が見られるのは、画面に書かれたことだけです。作り手が会議で聞いた説明や、頭の中で覚えている手順までは見えません。

この章では、作り手の頭の中にある情報と、画面に現れている情報を分けて考えます。

18.1 答えを知ると、手がかりまで見えた気になる

図 18-1A には、「申請」「承認」「設定」という三つのボタンがあります。どれも同じ大きさと色です。画面には、誰が何をしている途中なのかも書かれていません。これだけを見て、次に押すボタンを決めることはできません。

ところが、正解は「承認」だと教えられたあとでは、「承認」という文字が目立って見えます。画面に手がかりが増えたわけではありません。見る人の頭に答えが増えたのです。

結果を知ったあとに「最初から分かっていた」と感じやすくなることを、後知恵バイアスと呼びます。自分が知っていることを、知らない人の立場から想像しにくいことは、知識の呪いと呼ばれます。

用語を覚えることよりも、作り手の知識が画面の説明不足を隠してしまう、と知ることが大切です。

18.2 作り手には、画面の続きが見えている

文化祭サイトに、出し物を紹介するページを作る場面を考えてみます。

ページを書いた生徒が「公開を依頼する」ボタンを押すと、担当の先生へ確認依頼が届きます。先生が内容を確認すると、ページが公開されます。作り手は、この流れを知っています。

そのため、作り手には「確認待ち」という短い表示だけでも十分に思えます。しかし、ページを書いた生徒には、次のような疑問が残ります。

• 誰の確認を待っているのか
• 確認が終わるまで、自分は何もしなくてよいのか
• 内容を直したくなったら、どこから戻れるのか
• 公開されたら、どこで分かるのか

これらは、利用者の理解力が足りないから生まれる疑問ではありません。必要な情報が画面にないために生まれる疑問です。

「確認待ち」を「担当の先生が内容を確認しています」に変えると、誰が次に動くのかが分かります。「公開前でも内容を修正できます」と編集への入口を添えれば、自分ができることも分かります。

作り手が知っている流れを、利用者が必要とする場所へ少しずつ渡すのです。

18.3 短い言葉ほど、前提を隠すことがある

「送信」「処理中」「エラー」のような言葉は短く、画面へ置きやすい言葉です。しかし、それだけでは意味が足りないことがあります。

「送信」では、何を誰へ送るのかが分かりません。「先生へ確認を依頼する」なら、ボタンを押したあとの出来事を想像できます。

「処理中」では、待てばよいのか、別の操作が必要なのかが分かりません。「画像をアップロードしています。この画面を閉じずにお待ちください」なら、現在の状態と待つ理由が分かります。

「エラー」では、何が起きて、どう直せるのかが分かりません。「画像の容量が大きすぎます。10MB 以下の画像を選んでください」なら、次の行動が分かります。

長い説明をいつも表示すればよい、という意味ではありません。その場で判断するために必要な言葉を、省略しないことが大切です。

18.4 作り手は、初めて見る状態には戻れない

一晩置いて画面を見直すと、不自然な余白や読みにくい文章に気づくことがあります。それでも、作り手はボタンの意味や画面の続きを忘れてはいません。

「初めて見る人の気持ちになろう」と頑張るだけでは、頭の中の知識を消せません。そこで、人の気持ちを当てる代わりに、画面に実際に書かれていることを確かめます。

たとえば、公開前のページなら、少なくとも次の三点が画面から分かる状態を目指せます。

• いま何の途中なのか
• 次は誰が何をするのか
• 自分はいま何ができるのか

これは、すべての画面へ長い説明を加えるための決まりではありません。見出し、状態を表す一文、具体的なボタン名などを組み合わせ、必要な情報を必要な場所へ置くための考え方です。

18.5 「私は迷わない」は、画面の証明にならない

作り手が迷わず操作できるのは、画面が分かりやすいからかもしれません。しかし、作り手が答えを知っているからかもしれません。本人の操作だけでは、二つを見分けられません。

反対に、「初めて使う人は必ず迷う」と決めつけることもできません。同じようなサイトを使った経験があれば、説明が少なくても意味を予想できることがあります。

人を「初心者」と「専門家」の二種類へ分けるより、その操作に必要な情報が画面にあるかを見ます。サイトを使った経験がない人にも、仕事の流れを知らない人にも、判断の手がかりが見えていれば、経験の差へ頼りすぎずに済みます。

18.6 作り手の知識を、画面の手がかりへ変える

作り手が詳しいこと自体は、問題ではありません。その知識は、分かりやすい順序や言葉を考えるために必要です。

ただし、頭の中に置いたままでは、利用者には届きません。「何の状態か」「誰が次に動くか」「自分は何をすればよいか」という手がかりへ変えて、画面に渡します。

作り手は、答えを知らなかった自分には戻れません。それでも、頭の中だけにある情報と、画面に見えている情報は分けられます。その差に気づくことが、初めて訪れた人にも筋道の見えるサイトを作る第一歩です。

参考

• Camerer, Loewenstein & Weber (1989) — 自分の知識を持たない人の判断を予想しにくい現象を扱った研究です。
• Fischhoff (1975) — 結果を知ることが、結果を知る前の予想の見積もりへ与える影響を扱った研究です。

第 III 部統合ケース　規則を覚え、例外に出会い、回復する

第 15〜18 章では、人が過去の経験を持ち込み、繰り返しから次を予想し、操作への反応を期待することを見ました。ここでは、架空の権限申請サービスを初めて使い、通常の申請を繰り返し、例外と通信障害に出会う流れを追います。

人の頭の中を決めつける物語ではありません。画面で起きたことと、そこから考えられる説明を分けて読みます。

1　三回の反復から規則を予想する

一件目の共有フォルダ申請には、青い「申請する」ボタンがあります。

二件目の企画資料でも、同じ位置と色のボタンが同じ役割を持っています。

三件目の売上資料でも同じです。三回の反復によって、見た目と役割の関係が強くなります。

三つの画面では、資料名だけが変わり、青いボタンの位置、形、「申請する」という働きは繰り返されています。利用者は、まだ見ていない次の画面にも同じ規則が続くと予想するかもしれません。ただし、三回見ただけで全員が同じ規則を覚えたと断定はできません。

2　一件だけ違うと、予想が揺れる

四件目には、赤く角の丸い「緊急申請」ボタンが現れました。色、形、文言がそれまでと違います。

この違いには、緊急性を強く伝えるデザイン上の意図があるかもしれません。通常申請とは扱うデータや業務上の種類が違い、その差を見せた可能性もあります。反対に、古い部品や実験中の設定が一件だけ残っているのかもしれません。画面だけでは、必要な例外と実装上の取り残しを区別できません。

「一貫性がないから直す」とすぐ決めると、必要な警告まで消すかもしれません。表現の意図、データ、実装を別々に確かめます。

3　時間切れは、失敗したという意味ではない

申請ボタンを押したあと、画面には時間切れが表示されました。利用者から見ると、成功したのか失敗したのか分かりません。

この例では、サーバー側の申請はすでに成功していました。画面とサーバーで、知っている状態がずれています。

ここで申請ボタンをもう一度押すと、同じ申請が二重に作られるおそれがあります。送信時に発行した「受付番号 A42」を使い、最初の申請がどうなったかを確認します。受付番号は、一回の申請をあとから見分けるための番号です。

成功が確認できたら、画面を「申請済み」へ更新します。利用者の見える状態と、サーバーの状態が再び一致します。

4　「覚えた」を一回の成功だけで決めない

初回では、このサービスの規則をまだ知りません。そこで成功したなら、以前に使った別のサービスの慣習が助けた可能性があります。直後に同じ内容をもう一度使う成功には、いま見た画面を覚えている影響が大きくなります。

翌日に同じ内容を使えたなら、直後より長い時間を越えて規則が残った可能性があります。さらに、別の資料でも同じ操作を使えたなら、一つの画面を丸ごと覚えただけでなく、規則を別の内容へ移せたのかもしれません。初回、直後、翌日、別内容は、それぞれ違うことを示します。一つの成功を見て「直感的だった」「学習できた」とまとめません。

5　人は規則を使う。だから例外と回復も設計する

同じ見た目と役割を繰り返すと、次の操作を予想しやすくなります。例外が必要なら、何が違うのかを分かるようにします。操作の結果が分からない場合は、失敗と決めつけず、安全に確認して戻れる道を用意します。

人は知っている使い方を持ち込み、画面の反復から新しい規則を学びます。その予想を利用することも、必要な例外を説明することも、Web デザインの一部です。

第 IV 部　Web デザイナーは、どう見るか

ここまで、画面のまとまり、注意、記憶、予想、操作後の返事について見てきました。では、制作中の画面に「なんか変だ」と感じたとき、Web デザイナーは何をすればよいのでしょう。

たとえば、申し込みボタンを押しても画面が変わらないとします。

ボタンの色が悪いのでしょうか。押したことを示す表示がないのでしょうか。プログラムが動いていないのでしょうか。通信に時間がかかっているだけでしょうか。

見た瞬間に原因を一つへ決めることはできません。しかし、「なんか変」を、確かめられる小さな問いへ分けることはできます。

画面を見ると分かること

画面を比べると、ボタンの位置、文字、色、押す前と押したあとの変化が分かります。

「押したあとも、ボタンの文字と色が同じだった」「処理中を示す文章がなかった」と書けば、ほかの人も同じ画面を見て確かめられます。

一方、「分かりにくいボタンだった」だけでは、何を見てそう考えたのかが伝わりません。大きさなのか、言葉なのか、位置なのか、押したあとの変化なのかを分けると、直す場所が見えてきます。

HTML と CSS を見ると分かること

ブラウザに表示された画面は、HTML、CSS、JavaScript、画像、通信で届いたデータなどから作られています。

HTML を調べると、処理中やエラーを表示する場所が用意されているかが分かります。CSS を調べると、余白や幅がどの指定から来たのかが分かります。JavaScript の動きを調べると、クリックを受け取ったのか、通信を始めたのかが分かります。

画面に変化がないからといって、必ずしもボタンが動いていないとは限りません。通信は始まっているのに、そのことを画面へ表示していない場合もあります。

人が使うところを見ると分かること

画面とコードを調べても、利用者が表示の意味を理解できるかまでは分かりません。

「送信中」と表示したとき、その人は待てばよいと分かるでしょうか。エラーが出たとき、入力内容を直して戻れるでしょうか。キーボードや画面読み上げでも、変化が伝わるでしょうか。

人が使うところを見るときは、技術的に壊れていると分かっている画面を、そのまま試してもらう必要はありません。先にコードで確かめられる問題を直し、そのあとで、人にしか確かめられない理解や行動を見ます。

作って終わりではなく、作ったものから学ぶ

第19章では、「なんか変」を画面上の具体的な違いへ変えます。第20章では、考えられる原因を一つに決めつけず、確かめ方を考えます。第21章では、二つの案を比べるときの見せ方を扱います。

第22章では、画面幅、拡大、長い文章、通信状態を変えたときの崩れを見ます。第23章では、ブラウザの開発者向け機能で HTML や CSS を調べます。第24章では、人が実際に使う場面から何を読み取れるかを考えます。第25章では、作った画面から新しく分かったことを、次の制作へ戻します。

Web デザインは、一度で正解を当てる作業ではありません。見えたことを言葉にし、原因を確かめ、直した画面をもう一度見る。その往復によって、最初は言葉にできなかった違和感を、具体的な設計へ変えていきます。

第19章　「なんか変」を観察する

画面を見た瞬間の「なんか変」は、捨てなくてよい感覚です。ただし、そのまま修正指示にすると、何を、なぜ、誰のために変えるのかを共有できません。

「なんか変」は、まだ説明できていないだけで、無意味な感想ではありません。最初の言葉を残し、どこを見てそう感じたのかをたどると、画面で起きていることが少しずつ具体的になります。この章では、その変化を一段ずつ見ていきます。

19.1 違和感は捨てず、結論を急がない

「なんか変」は、余白が狭いのか、文字が弱いのか、そもそも内容が分からないのかをまだ区別していない言葉です。この時点で言い換えると、最初に気づいた感覚まで消してしまうことがあります。

たとえば、商品登録画面で「入力欄のあたりが窮屈に見える」と感じたとします。まず、どの入力欄とどの文字の間が気になったのかを見ます。最初の反応を残したまま、画面の具体的な場所へ近づいていきます。

19.2 見えたことと、そこから考えたことを分ける

図 19-2A では、「商品名」という文字とその入力欄より、商品名の入力欄と次の「価格」という文字の方が近くなっています。そのため、価格という文字が、上の商品名の入力欄にくっついて見えます。どこまでが一つの項目なのか迷いやすい配置です。

同じ項目のラベルと入力欄を近づけ、次の項目までは少し広く空ければ、距離が項目の区切りを助けます。ただし、まとまりは距離だけで決まりません。文字の見た目、左端の位置、境界線も一緒に見ます。

19.3 「ダサい」の手前に、何が見えたか

「ダサい」「いい感じ」は、個人の経験、文化、流行、ブランド期待を含む大切な反応です。しかし相手が次に何を観察すればよいかは示しません。

この例では、紫からピンクへ大きく変わる背景、斜めに傾いた大見出し、丸みの強いボタンが見えます。「ダサい」を禁止するのではなく、その言葉の手前に何が見えていたのかを、実際の画面から探しています。

ブランドが目指すものが「静かな信頼感」なら、強いグラデーションや跳ねる動きは、その意図から外れると評価できます。別のブランドが「遊び心と驚き」を目指すなら、同じ表現の評価は変わるかもしれません。

「ダサい」と感じたこと自体を間違いにはしません。強い色の変化、傾いた文字、丸い形の組み合わせが、どんな印象を作っているかを言葉にします。好みを消すのではなく、好みが生まれた場所を見つけます。

19.4 距離の違和感を、関係の説明へ変える

図 19-2A のフォームを見て「余白が足りない」と感じたのは、画面全体の空白が少ないからではありません。同じ項目の文字と入力欄より、入力欄と次の項目の文字が近いからです。空白の量ではなく、二つの距離の関係が、項目の区切りを曖昧にしています。

ここで見るのは距離だけではありません。入力欄の左端がラベルとそろっているか、同じ役割の文字が同じ見た目か、背景や境界線が別のまとまりを作っていないかも関係します。

19.5 見えたものから、目的に合うかを考える

観察だけを並べても、何を大切にするかは決まりません。マーケティングサイトでは驚きや余韻、業務システムでは速度とエラー回復、ミュージアムサイトでは没入や解釈の余地が重視されるかもしれません。

デザインを考えるときは、見えた形、表現の意図、見る人の経験、サイトの目的を結びます。測定できない美しさや文化的な印象も大切です。ただし、「心理学的に正しい」と言って好みを正解に見せる必要はありません。

19.6 「なんか変」から、見出しの差を見つける

この商品登録画面では、ページ見出し「商品を登録」が 24px、項目名の「商品名」が 18px です。見出しの方が大きいものの、二つの差は控えめです。これが「なんか平らに見える」という最初の違和感につながりました。

図 19-8B では、ページ見出しだけを 32px にしました。文言、太さ、位置、入力欄、ボタン、色は変えていません。図 19-8A と一枚ずつ見ることで、どこが変わったのかを落ち着いて比べられます。

図から直接分かるのは、見出しの大きさが変わったことです。実際に人が最初に読む場所まで変わったかは、図だけでは分かりません。見出しの言葉や上部の余白が影響している可能性もあります。

見出しを大きくすれば必ず良くなるわけでもありません。狭い画面では改行し、入力欄を大きく下へ押し出すかもしれません。違和感を具体的にすることは、すぐ一つの正解を決めることではなく、何を変え、何を確かめるのかを見えるようにすることです。

19.7 「なんか変」は、美しさを考える始まりになる

デザインの美しさは、数値だけで決まりません。余白が整い、文字が揃っていても、そのサイトが伝えたい気分や文化に合っていなければ、美しいとは感じにくいでしょう。一方で「美しいから」と言うだけでは、ほかの人と判断を共有できません。

最初の違和感を残し、見えたものを具体的にし、目的や表現意図へ照らす。この往復によって、感覚は消えず、理由だけが少しずつ見えるようになります。「なんか変」は、雑な感想ではありません。画面をよく見るための、最初の小さな合図です。

参考

• 第 I〜III 部の各章 — 概念名ではなく観察語と誤用上の注意へ戻ります。
• ISO 9241-210:2019 — Context of use と Evaluation を確認する入口です。
• WCAG 2.2 — プログラムから読み取れる状態等の仕様点検に使い、美的評価の答えにはしません。

第20章　名前を答えにしない

Web デザインを学ぶと、「近接」「認知負荷」「メンタルモデル」のような言葉に出会います。名前を知ると、画面で気になったことを人へ伝えやすくなります。しかし、名前を言えたことと、問題の理由が分かったことは同じではありません。

たとえば、項目が多い画面を見て「認知負荷が高い」と言っても、何を直せばよいかは分かりません。探す場所が多いのか、言葉が難しいのか、前の画面の内容を覚えておく必要があるのかで、直す場所は変わります。

この章では、専門用語を正解の札ではなく、理由を考え始めるための手がかりとして使います。

20.1 名前を付ける前に、画面で見えたことを言う

「これは近接の問題です」と言う前に、「商品名の入力欄と、次の価格という文字が近い」と言えば、どこを見ているかが伝わります。見えたことが具体的なら、専門用語を知らない人も同じ画面について話せます。

名前は、そのあとで役に立ちます。「近いものは同じまとまりに見えやすい」という考えを知っていれば、距離を変えた案を考えられます。ただし、距離だけが理由とは限りません。文字の強さ、言葉の意味、境界線、操作後の変化も関係することがあります。

一つの名前で話を終えず、「ほかの理由なら、画面のどこを見るだろう」と考える余地を残します。

20.2 同じ見た目のボタンでも、迷う理由は一つではない

図 20-5A には、「保存」と「登録」という二つのボタンがあります。大きさ、色、形が同じなので、見た目から主役を選ぶことはできません。これだけなら、片方だけを強く見せる案が思い浮かびます。

しかし、迷いの理由が言葉にある可能性もあります。この画面で「保存」と「登録」がそれぞれ何をするのか、初めて使う人には分からないかもしれません。その場合は色を変えるより、「下書きを保存」「商品を公開」のように、押した後に起きることが分かる言葉へ直す方が有効です。

さらに、押した後の画面が変わらず、どちらの操作が済んだか分からない可能性もあります。この場合に必要なのは、ボタンの見た目ではなく、完了したことを伝える表示です。

同じ「ボタンで迷う」という出来事でも、見た目、言葉、操作後の変化という三つの場所を考えられます。専門用語は、この候補を増やすために使います。

20.3 原因を見たいときは、変えるものを一つにする

距離が関係しているかを見たいなら、まず距離だけが違う二つの画面を比べます。

図 20-7A では、価格という文字が、上の商品名の入力欄に近く見えます。価格の入力欄よりも上の欄と組になっているように感じられ、項目の区切りが曖昧です。

図 20-7B で変えたのは、商品名の入力欄から次の「価格」までの間隔だけです。背景色、文字、入力欄の大きさは変えていません。そのため、二枚のまとまり方の違いを、間隔の違いと結びつけて考えられます。

これは「広い方がいつでも正しい」という意味ではありません。項目が多いフォームで間隔を広げすぎれば、画面が長くなります。ここで分かるのは、距離を変えると二つの項目の分かれ方も変わるということです。完成した画面では、読みやすさと全体の長さを一緒に整えます。

20.4 一見よくない形にも、役割があることがある

同じ商品が二つの分類にあると、重複はなくした方がよいように思えます。しかし、ノートを「文具」として探す人も、「勉強に使う物」として探す人もいます。二つの入口があることで、異なる探し方を助けている可能性があります。

図 20-8B では、星空ノートを文具だけに残しました。見た目は重複のない整った分類になります。その一方で、学習用品から探していた人には見つけにくくなるかもしれません。

二枚を見ただけで、どちらが探しやすいかは決まりません。「重複」という名前だけで悪いと判断せず、どんな人が、どこから商品を探すのかまで考える必要があります。

20.5 崩れて見える配置が、表現であることもある

図 20-9A では、「境界を越える」という見出しが画面の下端で二つに分かれています。業務用の入力画面なら、文字が切れた不具合に見えるでしょう。しかし、これは展覧会の入口で境界を感じさせるために、作者が意図した配置です。

意図があれば何でも許されるわけではありません。少しスクロールすれば全文を読めるか、画面を拡大しても文字が隠れたままにならないか、背の低い画面でも次の内容へ進めるかは別に考えます。

「正しい配置か、間違った配置か」という二択にせず、表現の意図を残しながら、内容へたどり着ける形を探します。

20.6 名前は、次に見る場所を増やす

近接、認知負荷、メンタルモデル、フィードバック。こうした名前は、画面へ貼る正解シールではありません。

役に立つ説明は、難しい名前を使った説明ではなく、画面のどこで何が起きているかが分かる説明です。そして、「距離だけでなく言葉かもしれない」「見た目だけでなく押した後かもしれない」と、次に見る場所を増やしてくれます。

名前を知る目的は、会話を終わらせることではありません。まだ見ていなかった場所へ、もう一度目を向けることです。

参考

• 第19章「『なんか変』を観察する」— 感じた違和感から、画面の具体的な場所を見つける考え方を扱います。
• 第2章「人間は、近いものを『同じ組』だと思ってしまう」— 距離とまとまりの関係を詳しく扱います。
• 第17章「人間は、反応がないと不安になる」— ボタンを押した後の表示が必要な理由を扱います。

第21章　並べると、違いが見えてくる

一つの画面だけを見ていると、「少し暗い」「少し狭い」と感じても、どれくらい違うのかは分かりにくいものです。別の案を隣へ置くと、それまで曖昧だった差が急にはっきりします。

比較は、Web デザインを考えるための便利な道具です。しかし、並べれば自動的に正しい答えが出るわけではありません。比べる画面の内容が違ったり、片方だけをよく見せる名前を付けたりすれば、判断も引っぱられます。

この章では、比較によって何が見えるのかと、比較を見るときに気をつけたいことを、三つの場面から考えます。

21.1 一つだけでは分からない差がある

図 21-1A には、一枚のグレーがあります。色見本の番号を知らなければ、この色が別のグレーより明るいのか暗いのかは分かりません。覚えている色と比べようとしても、照明や画面の明るさ、その日の記憶に影響されます。

図 21-1B では、二枚のグレーを隙間なく並べています。中央の境界を見ると、左が濃く、右が明るいことが分かります。色を正確に覚えていなくても、その場で二つの関係を見られるからです。

Web デザインでも同じです。見出しの位置、カードの幅、余白の大きさ、背景色の違いは、同じ大きさの画面を並べると見つけやすくなります。

ただし、見つけられる差が、すべて大切な差とは限りません。隣に置いたときだけ分かるほど小さな色の差は、普段そのページだけを見る人には気づかれないかもしれません。差を見つけたあとに、その差が読みやすさやサイトの雰囲気へどう関係するかを考えます。

21.2 比べるなら、関係のない違いを混ぜない

変更前と変更後の画面を比べる場面を考えます。変更前には商品が三件、変更後には五件ある。変更後だけ少し下へスクロールしている。片方だけ Web フォントの読み込みが終わっている。この状態では、画面にたくさんの差が生まれます。

本当に見たかったのがカード同士の間隔なら、商品名、商品数、画面幅、スクロール位置、文字、表示中の状態を同じにします。変えるのは間隔だけです。すると、二枚の違いを間隔と結びつけて考えられます。

原因を知るための比較では、一度に一か所だけ変えることが役立ちます。一方、完成したデザイン案を選ぶときは、文字、色、写真、余白をまとめて変えた案を比べることもあります。この二つは目的が違います。

• 一か所だけ違う比較は、何が見え方を変えたのかを考えるために使う
• 全体が違う比較は、それぞれの案が何を大切にしているかを考えるために使う

完成案 A は予定を早く探せるが、情報が密集して見える。完成案 B は静かな余白があるが、一画面に見える予定は少ない。この場合は、どちらが正しいかではなく、誰が何をするサイトなのかに戻って選びます。

21.3 名前だけでも、片方がよく見える

図 21-6A では、左にわざと魅力を抑えた「極端案」、右に整った「改善版」を置いています。右には最初から「改善」と書かれ、文字も赤く強調されています。この並べ方なら、内容を詳しく見る前から右を選びたくなります。

比較には、画面そのもの以外の情報も入り込みます。

• 「旧版」と「改善版」という名前
• 左右のどちらへ置くか
• どちらを先に見せるか
• 何と何を比較相手に選ぶか

案そのものを見たいときは、まず「A」「B」のような中立の名前にします。左右を入れ替えても同じ判断になるかも考えます。極端に悪い案だけを比較相手にせず、実際に選ぶ可能性のある案を並べます。

それでも完全に公平な比較になるとは限りません。大切なのは、並べ方もデザインの一部であり、人の印象を動かすと知ることです。

21.4 重ねる比較は、位置のずれを見るために使う

二つの画面を半透明にして重ねると、見出しやボタンの位置のずれを見つけやすくなります。ブラウザで実装した画面が、デザイン案と同じ位置になっているかを見るときに便利です。

一方、重ねると二つの色が混ざり、元のどちらにもなかった色が生まれます。色や雰囲気を比べたいときには、重ねず、同じ大きさで隣へ置きます。

比べ方は、見たいものに合わせます。

• 画面全体の印象や色を見るなら、同じ大きさで隣へ置く
• 要素の位置や大きさのずれを見るなら、半透明で重ねる
• 一つの変更点を見るなら、ほかの条件をそろえた二枚にする

方法の名前を覚えることより、「いま何の差を見たいのか」を先に決めることが大切です。

21.5 比較は、勝ち負けを決めるためだけにしない

比較すると、どちらか一方を勝者にしたくなります。しかし、デザイン案には、得るものと失うものが同時にあります。

情報をたくさん見せれば、予定を早く探せる一方で、静かな印象は弱くなります。大きな写真を使えば、展示への期待は高まる一方で、来館案内が画面の下へ移るかもしれません。余白を広くすれば、落ち着いて読める一方で、スクロールは増えます。

比較によって見つけたいのは、「どちらが優れているか」だけではありません。それぞれの案が、何を大切にし、代わりに何を手放しているかです。

小さな差を見つける。関係のない条件をそろえる。並べ方による誘導に気づく。そして最後に、サイトの目的へ戻る。この順番で見ると、比較は答えを押しつける演出ではなく、デザインについて詳しく話すための道具になります。

参考

• 第19章「『なんか変』を観察する」— 違和感を、画面の具体的な場所と結びつけます。
• 第20章「名前を答えにしない」— 一か所だけを変えた比較から、考えられる理由を整理します。
• W3C WAI, WCAG 2.2「Use of Color」— 色だけに意味を任せないための基準です。

第22章　ブラウザの幅を変えると、画面の続きが見える

Web サイトのデザインは、完成した一枚の画像ではありません。同じページでも、ブラウザの幅、文字の大きさ、文章の長さ、読み込みの状態が変わると、要素の並び方や必要な広さも変わります。

PC 表示とモバイル表示の二枚だけを作っても、その間にある幅で文字がぶつかることがあります。短い商品名では整っていても、本番の長い名前を入れるとカードが伸びます。通信中には、完成後にはない案内も必要です。

ブラウザの幅をゆっくり変えると、静止画の外側にある変化が見えてきます。この章では、変化が起きる五つの場面を一つずつ見ます。

22.1 「PC 幅」と「モバイル幅」の間でも、画面は変化する

横幅に余裕があるとき、見出しとボタンを横に並べられます。

図 22-3A では、左の見出しと右の予約ボタンの間に余裕があります。この一枚だけなら、横並びで問題ないように見えます。

ブラウザを少し狭くすると、見出しが折り返します。しかし、ボタンは同じ場所に残るため、二つが重なりました。

図 22-3B の 642px は、どのサイトでも使える特別な数字ではありません。この見出し、この文字の大きさ、このボタンを組み合わせたとき、重なりが現れた幅です。文章や書体が変われば、重なり始める幅も変わります。

さらに狭い画面では、見出しとボタンを縦に並べます。

大切なのは、最初に「何 px で切り替える」と決めることではありません。ブラウザを狭め、見出しとボタンの関係が苦しくなる場所を見つけ、その少し手前で並び方を変えることです。

画面の高さも変わります。小さなノート PC では、横幅が十分でも下のボタンが見えないことがあります。スマートフォンでは、文字入力中だけキーボードが画面の一部を覆います。横幅だけでなく、縦に何が見えているかも考えます。

22.2 拡大すると、文字だけでなく配置も変わる

Web ページを拡大して読む人もいます。まず、通常の大きさでは、住所と確定ボタンが一つの枠に収まっています。

ブラウザでページ全体を 200%に拡大すると、一度に見える横幅が狭くなります。文字も入力欄も大きくなり、ブラウザは内容を縦へ組み直します。

文字だけを大きくする設定もあります。図 22-4C では、ボタンの高さを固定したまま文字だけが大きくなり、文言が枠からはみ出しました。

この問題は、ボタンを少しだけ高くして終わりではありません。別の言葉なら二行になるかもしれないからです。上下の余白で高さが決まるようにし、文字が増えたときはボタンも一緒に伸びる設計にします。

22.3 本番の文章は、見本より長くなる

短い商品名は、ほとんどのカードにきれいに収まります。

ところが、実際の商品名には、素材、用途、個数などが含まれます。

図 22-5B では、カードの高さを文字に合わせて伸ばし、商品名を最後まで表示しています。最初から二行や三行になる場合を考えていれば、長い名前を無理に小さくしたり、途中で隠したりせずに済みます。

URL や長い英数字は、日本語と同じ場所では折り返せません。

長い URL が枠を押し広げないよう、途中で折り返せる指定が必要です。人名、金額、大きな数字、翻訳された文章も、見本より長くなることがあります。意味のない仮の文章だけでなく、そのサイトに本当に入りそうな長い内容を使って画面を見ます。

22.4 同じ一覧にも、表示する商品がない時間がある

商品一覧は、いつも完成したカードが並んでいるとは限りません。まだ商品が一件もないときは、空白だけを見せず、次にできることを伝えます。

通信中には、商品がないと決めつけず、読み込みが続いていることを伝えます。

一部だけ届いた場合は、届いた商品を隠す必要はありません。表示できた二件を見せながら、残り一件だけをもう一度読み込めるようにします。

権限がない場合は、待っていても商品は現れません。必要な権限と、誰へ連絡すればよいかを伝えます。

0 件、読込中、部分的な失敗、権限不足は、すべて見た目が空きやすい状態です。しかし、起きていることも次の行動も違います。完成した状態だけでなく、その前後にある時間までデザインします。

22.5 同じカードでも、置かれる場所の幅が違う

一つの商品カードを、サイトのいろいろな場所で再利用することがあります。広いメイン部分なら、画像と説明を横に並べられます。

同じカードを細いサイドバーへ置くと、横並びでは窮屈になります。

この変化を、画面全体の幅だけで決めると困ることがあります。同じ大きな PC 画面の中でも、メイン部分は広く、サイドバーは細いからです。

部品が置かれた場所の幅を見て並び方を変える CSS の仕組みを、コンテナクエリと呼びます。難しそうな名前ですが、考え方は単純です。「画面が PC かスマートフォンか」ではなく、「このカードが今使える幅はどれくらいか」を見る方法です。

コンテナクエリだけが正解ではありません。Flexbox で自然に折り返す方法や、画面全体の幅を見るメディアクエリもあります。守りたいのは技法ではなく、文字と画像が無理なく読める関係です。

22.6 ブラウザを動かすと、切り替える理由が見つかる

レスポンシブデザインは、PC 版とモバイル版の二枚を作ることではありません。その間の幅、短い高さ、拡大された文字、長い内容、通信中などにも、同じページが続いています。

最初に端末名や決まりきった数字を選ぶのではなく、ブラウザを少しずつ動かします。文字がぶつかる。ボタンが押し出される。カードの内容が窮屈になる。そうした変化が現れる場所に、並び方を変える理由があります。

数字は、その理由を CSS へ伝えるために使います。数字そのものを覚えるのではなく、どの関係を守るための数字なのかを考えることが、Web らしい画面設計につながります。

参考

• 第7章「人間は、押せそうなものを押してしまう」— ボタンの見た目と、押せる範囲を扱います。
• 第17章「人間は、反応がないと不安になる」— 読込中や失敗時に、現在の状態を伝える理由を扱います。
• W3C, WCAG 2.2「Resize Text」「Reflow」— 文字の拡大と狭い表示で、内容を失わないための基準です。

第23章　DevTools で、見た目の理由をたどる

Web ページを作っていると、「この空白は、どの CSS が作っているのだろう」「同じ位置へ置いたはずなのに、なぜ端がそろわないのだろう」と思うことがあります。

ブラウザには、表示中の HTML や CSS を調べるための DevTools（デベロッパーツール）があります。日本語では「開発者ツール」とも呼ばれます。Chrome、Firefox、Safari などで見た目は少し違いますが、ページの内側をその場で確かめられる点は同じです。

DevTools が教えてくれるのは、ブラウザが使った値や、要素の箱の大きさです。その数字が美しいか、言葉が分かりやすいかまでは教えてくれません。画面で気になった場所と、コードで起きていることを結びつけるために使います。

23.1 同じ空白に見えても、作り方は違う

画面に見える空白は、いつも一つの margin から生まれるわけではありません。CSS には、場所の違う空白がいくつかあります。

まず margin は、要素の輪郭より外側に空間を作ります。

図 23-2A の二つの箱には、どちらにも輪郭があります。輪郭と輪郭の間にあるのが、箱の外側の空間です。背景色はこの空間へ広がりません。

padding は、箱の輪郭と中身の間に空間を作ります。

図 23-2B では、薄い色の部分まで外側の箱に含まれています。ボタンの文字と輪郭の間や、カードの端と内容の間によく使います。

gap は、Flexbox や Grid で並べた項目の間へ、親要素がまとめて空間を配ります。

カードを三枚並べるとき、それぞれへ別々の余白を付ける代わりに、並べる親へ gap を指定できます。項目の数が変わっても、項目と項目の間だけへ同じ空間が入ります。

文字にも、目に見えにくい箱があります。line-height で決まる一行の高さは、文字の輪郭より大きいことがあります。

見出しの上下が広く見えるとき、margin だけでなく、この行の高さが関係していることがあります。だから DevTools では、「空白が何 px か」だけでなく、「どの箱の内側か、外側か、箱と箱の間か」を見ます。

23.2 上書きされた CSS と、実際に使われた CSS

一つの要素には、複数の CSS が当たることがあります。DevTools の Styles 欄には、その候補が並びます。

図 23-3A の gap: 16px には取り消し線があります。これは、その指定が候補にはなったものの、別の指定に上書きされたという印です。

実際に使われているのは gap: var(--space-form) です。--space-form という名前の箱に入った値を調べると、28px だと分かります。CSS 変数は、同じ間隔や色を何か所でも使えるよう、値へ名前を付ける仕組みです。

DevTools の Computed 欄では、さまざまな指定を計算したあと、ブラウザが最終的に使った値を見られます。しかし、そこに 28px と表示されても、28px がデザインの正解だという意味ではありません。分かるのは、今のブラウザが 28px を使っているという事実です。

23.3 ページの上へ補助線を重ねる

カードの左端がそろわないとき、目だけでわずかなずれを追うのは大変です。DevTools には、ページの上へレイアウトの補助線を重ねる機能があります。

図 23-4A では、三つのカードの列へ青い線を重ねています。カードがどの列に入り、列と列の間がどれくらい空いているかを一度に見られます。

補助線の色やボタンの場所はブラウザによって違います。青色を覚える必要はありません。大切なのは、画面で見えたそろい方が、どの列や間隔の規則から生まれているかを見つけることです。

23.4 CSS を一つだけ外すと、空白の原因が分かる

三枚のカードの間が、どの指定から生まれたのかを調べます。最初の画面では、親要素の gap: 24px が使われています。

DevTools で、この gap だけを一時的に無効にします。

ほかの CSS を変えていないのに間隔が消えたため、この空白を作っていたのは gap だと分かります。値を 32px へ変えれば、広げた場合の見た目もその場で試せます。

DevTools で行った変更は、普通はページを再読み込みすると消えます。これは原因を調べるための試着です。採用する変更は、制作中の CSS へ書き戻し、ほかの画面幅や状態でも崩れないかを確認します。

23.5 見た目を出すことと、本当に操作できることは違う

キーボードで Web ページを使うと、現在選ばれているリンクやボタンに輪郭が出ます。この状態をフォーカスと呼びます。

DevTools では、フォーカスしたときの見た目だけを強制して表示できます。

図 23-6A から、輪郭の太さや色は分かります。しかし、実際にキーボードだけで確認ボタンへ移動できるか、どの順番で選ばれるかは分かりません。

そこで Tab キーを実際に押します。

図 23-6B では、戻る、確認、送信の順に移動し、送信ボタンへ到達しました。見た目を強制する確認と、実際に操作する確認では、分かることが違います。

同じように、通信エラーの色だけを表示しても、送信中から失敗へ正しく変わるかは分かりません。通信を本当に失敗させると、処理の流れまで見られます。

23.6 DevTools に分からないこと

DevTools は、CSS の値、要素の大きさ、上書きされた指定、並び方を調べるのが得意です。どこから空白が生まれたのか、なぜ要素が重なったのかを、コードまでたどれます。

一方、利用者が「確認」と「送信」の違いを理解できるか、文章を読んでどう感じるか、ブランドの雰囲気に合っているかは、数値の欄には表示されません。

DevTools を使う目的は、数字を集めることではありません。画面で見えたことと、HTML や CSS で起きていることをつなぎ、「なぜこの見た目になったのか」を説明することです。原因が分かったあと、どのように直すかは、ページの目的と画面全体へ戻って考えます。

参考

• Chrome for Developers「Inspect and change the page」— DevTools で HTML と CSS を確認する公式案内です。
• Firefox Source Docs「Page Inspector」— Firefox の開発者ツールで要素とレイアウトを確認する案内です。
• 第17章「人間は、反応がないと不安になる」— 操作後の状態を画面へ返す理由を扱います。

第24章　人が使うと、作者の予想から外れる

デザイナーは画面を作りながら、「この分類なら商品を見つけられる」「このボタンならすぐ押せる」と予想します。しかし、初めてその画面を見る人は、作り手が考えた順番どおりには動きません。

見出しではなく検索欄から読み始めるかもしれません。作者には当たり前だった言葉で止まるかもしれません。反対に、作者が難しいと思っていた場所を迷わず通り過ぎることもあります。

人が Web サイトを実際に使う様子を見る調査を、ユーザビリティテストと呼びます。テストされるのは参加した人の能力ではありません。画面や言葉が、作り手の予想どおりに伝わったかを確かめます。

24.1 作り手は、画面のことを知りすぎている

商品一覧を作ったデザイナーは、どの分類に何が入っているかを知っています。「文具」を押せばノートが見つかることも、「保存」と「公開」の違いも知っています。

初めて来た人には、その知識がありません。だから、作者自身が迷わず操作できても、画面が分かりやすい証明にはなりません。

人が使うところを見るときは、答えを先に教えません。「文具を開いて、青いボタンを押してください」と伝えれば、その通りに進めます。しかし、それでは分類やボタンを自分で見つけられるかは分かりません。

たとえば、「来週火曜に最も早く届くノートを選び、購入する直前まで進んでください」と伝えます。どこを押すかではなく、達成したいことだけを示します。すると、その人がどの情報を探し、どんな順番で商品を比べたかが見えてきます。

参加する人の経験も大切です。オンラインストアを毎週使う人と、初めて使う人では、知っている決まりが違います。スマートフォンとパソコンでも操作は変わります。「利用者なら誰でも同じ」とまとめず、どんな経験の人が、どの機器で使った場面なのかを考えます。

24.2 止まったことと、止まった理由は同じではない

ある参加者が、ノートを探す場面を見てみます。最初に検索を使い、その後で二つの分類を行き来しました。24 秒のところで操作が止まり、34 秒で商品を選びました。

図 24-4A から確実に分かるのは、画面上で起きた四つの出来事です。「分類の名前が分からず迷った」とは、まだ言えません。文章を読んでいたのかもしれません。商品を比べて考えていたのかもしれません。通信を待っていた可能性もあります。

同じ 24 秒のところで、参加者は「探しています」と話しました。

この言葉から、ただ休んでいたのではなく、何かを探していたことが分かります。それでも、何が分からなかったのかまでは決まりません。

行動、実際に話した言葉、作者が考えた理由を分けると、想像を事実のように扱わずに済みます。その後で画面を見返すと、分類名、検索結果、商品の並び方など、次に確かめたい場所が見つかります。

24.3 すぐ助けると、その先の行動が見えなくなる

参加者の操作が止まると、作り手は「そこではなく、右のボタンです」と教えたくなります。しかし、答えを伝えた瞬間、その人が自分で次に何をしようとしていたかは分からなくなります。

少し待つと、説明を読み直す、前の画面へ戻る、検索を試すといった次の行動が現れることがあります。それでも課題を忘れてしまった場合は、押す場所ではなく、「来週火曜に届くノートを探します」のように最初の目的だけを伝え直します。

ヒントを出したあとで商品を見つけられても、一人で見つけた場合とは分けて考えます。ヒントが悪いのではありません。先の画面を見るために助けることはあります。ただし、どこから助けが必要だったかを消さないことが大切です。

安全は別です。個人情報を本当に送信しそうなとき、苦痛を感じているとき、金銭やアカウントへ影響が出そうなときは、観察を続けず止めます。調査より参加した人を守ることが優先です。

24.4 「使いやすかった」と、途中の行動は両方残す

操作を終えた人が、「使いやすかったです」と話すことがあります。その感想は大切です。しかし、途中で分類を何度も往復した行動まで、なかったことにはなりません。

感想と行動は、どちらか片方が正しいのではありません。全体としては使いやすかったが、商品を探す場面だけ時間がかかったのかもしれません。気を遣って肯定的に答えた可能性もあります。反対に、途中で戻っていても、本人には自然な確認だったこともあります。

「どの場面が使いやすかったですか」「探していたとき、何を見ていましたか」と具体的な場面を聞くと、短い感想と行動を結びつけやすくなります。

一人が困ったことを、「一人だけだから」と無視する必要はありません。その人が実際に出会った問題です。一方で、一人の行動を「全員がこうする」と広げることもできません。誰が、どの機器で、どんな目的を持って使ったときに起きたのかを残します。

24.5 記録する前に、本人が選べるようにする

人が使う様子には、個人に関わる情報が含まれます。画面に名前が映るかもしれません。声から本人が分かることもあります。操作の記録から、仕事や生活の状況が見える場合もあります。

そのため、調査を始める前に、何を記録し、何のために使うのかを説明します。

図 24-7A では、画面録画、音声録音、操作記録を一つずつ選べます。音声は断り、画面と操作だけを許可することもできます。集めるのは、本人が内容を理解して選んだ記録だけです。

本物の住所やクレジットカードを入力させず、調査用の架空データを用意します。参加者を募集するための連絡先と、調査中の記録も分けて保管します。報告には、目的に必要な部分だけを使います。

同意は、一度ボタンを押せば終わりではありません。途中で止めたくなったときの方法や、いつまで記録を削除できるかも、始める前に伝えます。先生と生徒、上司と部下のように断りにくい関係では、参加しなくても不利益がないことを特にはっきりさせます。

24.6 予想と違ったところが、次のデザインになる

作り手は「分類が重複しているから迷った」と考えていたかもしれません。しかし、実際には分類名の意味で止まっていた可能性があります。検索結果に必要な情報がなかったのかもしれません。重複した分類が、別の探し方を助けていたことも考えられます。

人が使うところを見る目的は、自分の案が正しかったと証明することではありません。予想と違う行動から、画面だけを見ていたときには気づかなかった理由を見つけることです。

作者の予想、画面上で起きた行動、本人が話した言葉を分ける。そして、分からなかったことを残したまま、次の画面を考える。この繰り返しによって、デザインは作り手の頭の中だけにある正解から、実際に使われる形へ近づいていきます。

参考

• GOV.UK Service Manual「Using moderated usability testing」— 進行役が参加者と一緒に行う調査の公式案内です。
• 第19章「『なんか変』を観察する」— 見えたことと、その理由について考えたことを分けます。
• 個人情報保護委員会「個人情報保護法について」— 記録を扱う前に確認したい日本の公式情報です。

第25章　作ると、次に見るものが現れる

Web デザインは、頭の中で完成させてから、その通りに組み立てるだけの仕事ではありません。実際の文字を入れ、ブラウザで動かし、人が使うところを見ると、作る前にはなかった条件が現れます。

長い商品名が折り返す。通信が終わるまで時間がかかる。使う人によって押せるボタンが違う。こうした変化は、最初の案が無駄だったという意味ではありません。最初の案を作ったからこそ、次に考えることが見えるようになったのです。

最終章では、一つの案が現実の条件に出会い、少しずつ変わっていく流れを見ます。そして最後に、序章で見た画面へ戻ります。

25.1 見本の文字は、たいてい短い

商品カードの最初の案では、「山のノート」のような短い名前だけを使っていました。一行で収まり、下のボタンも決めた位置へきれいに置けます。

しかし、本番の商品名には、素材、用途、数量などが入ります。

図 25-1B では、長い商品名が二行になりました。カードの高さは文字に合わせて伸びています。ボタンを下へ押し出すのか、カードの下端へそろえるのかも、ここで初めて具体的に考えられます。

見本の一行だけを基準に高さを固定していたら、文字がボタンへ重なるか、途中で切れていたかもしれません。実際に入りそうな内容を置くことは、完成後の事故を先に見つける方法でもあります。

25.2 一瞬で終わる間は、デザインされていない

制作中のパソコンでは、送信を押すと結果がすぐ返ってくることがあります。その速さだけを見ていると、押してから完了するまでの途中を忘れます。

通信を遅くすると、待っている時間が見えるようになります。

何も変わらないまま待たされると、ボタンを押せなかったと思い、もう一度押す人がいます。二回送信されたり、同じ注文が重なったりするかもしれません。

必要なのは、派手な動きとは限りません。「送信しています」と表示する、ボタンを一時的に押せない状態にする、完了後に結果を伝える。時間の途中にも現在の状態が分かれば、待つ理由を理解できます。

25.3 同じ画面でも、できることは人によって違う

管理する人には編集できても、見るだけの人には編集できない画面があります。

図 25-1D では、「編集する」ボタンが使えません。これだけでは、読み込み中なのか、故障なのか、権限がないのか分かりにくい場合があります。南京錠だけに頼らず、「編集する権限がありません」のように理由も伝えると、待っても変わらないことが分かります。

操作を隠す方がよい場面もあります。存在を知る必要がなく、表示するとかえって混乱する場合です。一方、申請すれば使える機能なら、使えない理由と申請方法を見せる方が役立ちます。同じ「押せないボタン」でも、次にできることによって表し方が変わります。

25.4 一つ変えると、何が関係したか分かりやすい

待ち時間の問題を見つけたあと、画面全体の色やボタンの位置まで同時に変えると、どの変更が役立ったのか分かりにくくなります。まず、「送信しています」という表示だけを加えます。

プログラムを調べれば、クリックを受け取ったか、通信が始まったか、二重送信を防いだかを確認できます。読み上げソフトへ状態を伝える HTML になっているかも確かめられます。

一方、「送信中だと人に伝わったか」はコードだけでは分かりません。表示に気づかず、もう一度押す人がいるかもしれません。「送信しています」の文字がボタンと離れすぎて、関係のない案内に見えるかもしれません。

実装が動いたことと、その意味が人へ伝わったことは別です。どちらも確かめて初めて、変更した表示が目的に合ったかを考えられます。

25.5 序章の画面を、もう一度見る

序章では、一つの権限申請画面を見ました。締切、必要な権限、承認される順番、理由の入力欄が一画面に並んでいました。

本を読み始めたときは、「情報が多い」「少し使いにくそう」と感じたかもしれません。今は、もう少し具体的に見られます。

「必要な権限」の箱と「承認ルート」の箱は横に並び、同じくらい強く見えます。しかし、申請する人が最初に決めるのは権限で、承認ルートは選んだ内容から決まる情報かもしれません。役割が違うなら、同じ強さで並べる必要があるかを考えられます。

理由欄と申請ボタンの間は近く、入力から送信へ進む流れは見えます。一方、締切は画面の右端にあり、横幅が狭くなったときに切れないかを確認したくなります。申請を押した後の待ち時間や完了表示は、この静止画だけでは分かりません。

「近接」「階層」「フィードバック」という言葉を言えることがゴールではありません。どの要素が、どんな関係に見えるか。条件が変わると何が起きそうか。静止画から分からないことは何か。そこまで具体的に話せれば、次に見る場所が分かります。

25.6 公開は、画面が現実へ出会う日

公開前に、すべての状況を知ることはできません。実際に公開すると、想像していなかった長い名前が入ります。通信の遅い場所から使われます。問い合わせや操作の失敗から、新しい問題が見つかります。

だからといって、危険が分かっているまま公開してよいわけではありません。個人情報が漏れる、キーボードで操作できない、重要な内容が読めないといった問題が残るなら、期限より人を守る判断が必要です。

公開後に見つかった問題は、失敗を隠す材料ではなく、次のデザインを考える材料です。問い合わせが多い言葉を直す。長い内容で崩れたカードを伸びるようにする。待ち時間が伝わらない画面へ状態を加える。

Web デザインを見る目とは、正解を暗記することではありません。画面で起きていることに気づき、具体的な言葉にし、ほかの理由も考え、実装と人の行動から確かめる力です。

作る。見る。気づく。言葉にする。一つ変える。比べる。そして、また作る。

次に作る画面が、この本の続きです。

参考

• 第17章「人間は、反応がないと不安になる」— 待っている間と、操作後の状態を扱います。
• 第22章「ブラウザの幅を変えると、画面の続きが見える」— 長い内容や異なる表示条件を扱います。
• W3C, Web Content Accessibility Guidelines (WCAG) 2.2 — 公開前に確認するアクセシビリティ基準です。

第 IV 部統合ケース　違和感を、公開判断まで運ぶ

第 19〜25 章では、画面の違いを言葉にする方法、二つの案の比べ方、ブラウザで HTML や CSS を調べる方法、人が使う場面の見方を扱いました。ここでは、架空の権限申請サービスにある一つの違和感を、公開するかどうかの判断まで著者が順に追います。

気になったのは、「申請ボタンを押しても画面が変わらない」ことです。以下は説明用に作った架空の画面であり、実在する利用者の調査結果ではありません。

1　最初に、見えた事実を言葉にする

パソコンの画面で申請ボタンを押しました。通信には 4 秒かかるように設定しています。押す前と、押してから約 0.5 秒後を比べても、ボタンの色や文字は同じままで、処理が始まったことを伝える表示もありません。

この画面だけから分かるのは、見える変化がないことです。ボタンが押されたことをプログラムが受け取ったか、申請がサーバーへ届いたか、画面読み上げへ変化が伝わったかは、まだ分かりません。

2　原因を一つに決めつけない

見えるフィードバックが足りないのかもしれません。クリックイベントが動いていない、通信結果を失った、状態を伝える HTML がない、といった別の原因も考えられます。

まず、「送信しています」という表示だけを加えます。この言葉が表すのは、送信を始めて返事を待っていることです。申請が受け付けられた、処理が成功した、という意味ではありません。

3　画面の条件を一つずつ変える

一つの画面幅で成立しても、別の条件では状態表示が操作から離れることがあります。まず 320px 幅で、ボタンと状態表示が近いまま読めるかを見ます。

200%へ拡大すると、文字と部品が大きくなり、下にある情報が画面外へ移りやすくなります。

長い共有フォルダ名は複数行に折り返し、その下の操作を押し下げます。短いテストデータだけでは見えなかった変化です。

オフラインでは、いつまでも「送信しています」と表示しても回復できません。接続できないことと、次に何をすればよいかを伝える必要があります。

この四枚は、幅、拡大、文章の長さ、通信状態を別々に変えています。全部を一度に変えると、どの条件で問題が現れたのか分からなくなるためです。

4　画面から実装へたどる

もう一度、元の画面を見ます。送信後の変化はありません。

ブラウザの開発者向け機能で HTML を見ると、入力フォームとボタンはありますが、「送信中」や「完了」を入れる場所がありませんでした。開発者向け機能は、表示中のページを作っている HTML や CSS、通信などを調べるための道具です。

次に、ボタンを押した記録を見ます。プログラムはクリックを受け取り、送信処理を始めていました。つまり、「ボタンが押されたことを受け取れていない」という原因ではなさそうです。

ブラウザからサーバーへ申請のデータも送られていました。ただし、「ブラウザが送った」ことと「サーバーが申請を保存した」ことは別です。この記録だけでは、申請が成功したとは言えません。

ここまでで、クリックと通信は始まる一方、送信中の状態と表示場所がないことが分かりました。利用者が表示を理解するかは、人の行動を見る別の問いです。

5　人を見る前に安全を確かめる

イベントや HTML の欠落は、まず技術検査で調べられます。人の行動を見る価値があるのは、状態を理解できるか、もう一度押すか、失敗から戻れるかといった問いです。

実際に人を対象にする場合は、第24章で見た同意、記録媒体、データの保存、中止条件を先に整えます。本番のアカウントや個人情報は使いません。技術的に壊れていると分かっている試作品へ、必要もなく参加者を巻き込みません。

6　公開だけを成功にしない

二重処理を防ぎ、状態が見えるだけでなく支援技術にも伝わり、失敗から回復できることを確かめたら、公開を選べます。

根拠が足りない場合は保留します。期限が来たことは、不明な問題が解決した証拠にはなりません。

重大な不具合が見つかった場合は、変更を取り消します。取り消しは制作の失敗ではなく、利用者を危険へさらさない判断です。

自分に決定権がない場合は、観察条件、分かった事実、未確認の範囲を、判断できる担当者へ渡します。

公開後に重複処理、回復できない失敗、問い合わせの増加が起きたら、いったん終えた判断を再び開きます。

このケースで最初にあったのは、「押せたか分からない」という小さな違和感でした。それを具体的な画面差へ変え、別の原因を残し、一つだけ変え、画面条件と実装を確かめることで、公開判断まで筋道をつなげられました。

デザインを見る力は、すぐに修正案を出す速さではありません。何が見え、何がまだ分からず、次にどの根拠が必要かを区別できることです。

詳しい技術仕様と参考資料は、第19章から第25章の参考文献にまとめています。

付録 A　用語集

本文で出てきた言葉を、もう一度確かめたいときのための用語集です。すべてを暗記する必要はありません。

短い説明だけでは足りない言葉には、詳しく扱った章へのリンクを付けています。専門用語は、画面へ貼る正解の名前ではありません。目の前の画面で、どの要素にどのような関係があるかを先に確かめてください。

まとまりと見え方

近接の原則

近いもの同士が、一つのまとまりに見えやすいことです。Web では、項目名と入力欄、画像と説明、カード内とカード外の間隔を考える手がかりになります。近ければ必ず関係する、余白は広いほどよい、という意味ではありません。詳しくは第2章で扱います。

類同の原則

色、形、大きさなどが似たものを、同じ仲間だと感じやすいことです。同じ働きのボタンを同じ見た目にするときに役立ちます。ただし、見た目が同じだけで、HTML 上の働きまで同じになるわけではありません。第4章を参照してください。

閉合

輪郭が途中で切れていても、残りを補って一つの形として見ることです。すべてを線で囲まなくてもまとまりが伝わる場合がありますが、省略すれば必ず美しくなるわけではありません。第5章で図を使って説明します。

共通領域

同じ囲いの中にあるものが、一つのまとまりに見えやすいことです。カードや入力項目のグループが例です。囲みを増やしすぎると、どの境界が重要なのか分かりにくくなります。

図と地

前にある対象と、その背景を分けて見る関係です。ページの上へ重なる確認画面では、確認画面が「図」、その後ろのページが「地」になります。背景を暗くするだけで、操作の前後関係まで正しくなるわけではありません。

良い連続

線や並びが滑らかにつながると、一つの流れとして見えやすいことです。要素の端をそろえた列や、グラフの線を読むときに関係します。整列と似ていますが、同じ意味ではありません。

プレグナンツ

複雑な形を、できるだけ安定したまとまりとして見ようとする働きをまとめた歴史的な言葉です。「単純な画面ほど必ず優れている」というデザインルールではありません。

運動知覚

時間とともに位置や形が変わるものを、動きとして見ることです。通知の移動、画像の切り替え、読み込み中の表示などに関係します。動きは注意を引きますが、内容の理解を必ず助けるとは限りません。第6章を参照してください。

整列

複数の要素が、同じ左端、右端、中心、文字の基準線などを共有することです。そろえる基準は一つではありません。第3章では、基準ごとに別の図で説明します。

見た目に合わせる位置調整

数値上の中心へ置いた形がずれて見えるときに、形を保ったまま位置だけを少し動かすことです。英語では optical alignment と呼ばれます。感覚だけで自由に動かすのではなく、数値上の位置と調整後を比べ、何を直したか分かるようにします。

注意、記憶、選択

注意

多くの情報の中から、一部へ意識や処理を向ける働きです。大きいものや動くものが注意を引くことはありますが、目を向けたことと、内容を理解したことは同じではありません。

選択的注意

目的に合う情報へ注意を向ける一方、ほかの情報を取りこぼすことです。利用者が何を探しているかによって、同じ画面でも見つけるものは変わります。第10章で扱います。

視覚的顕著性

周囲との色、大きさ、明るさ、動きなどの差によって目立つ性質です。目立つものが、利用者にとって重要なものとは限りません。

視覚的階層

文字の大きさ、太さ、色、位置、余白などを使い、情報の強さや読む順番に差を作ることです。大きさだけの順位表ではありません。

ワーキングメモリ

情報を短い間覚えながら、考えたり比べたりする働きです。前の画面の番号を覚えたまま入力する場面などで使います。誰でも同じ個数までしか覚えられない、という単純な決まりではありません。第11章を参照してください。

チャンク化

複数の情報を、知識や規則によって一つのまとまりとして扱うことです。見た目を囲っただけで、記憶の中でも自動的に一つになるわけではありません。

認知負荷

考える、覚える、学ぶときにかかる負担を表す言葉です。「情報が多くてごちゃごちゃしている」という感想の言い換えではありません。探す場所が多いのか、覚え続ける必要があるのか、選択肢を比べにくいのかまで分けると、直す場所が見えます。

再生

答えが見えていない状態で、記憶から思い出すことです。コマンドを最初から入力する場面が例です。

再認

表示された候補を見て、知っているものかどうかを判断することです。最近使った項目や入力候補から選ぶ場面が例です。第12章では、再生と再認を別々の画面で比べます。

ヒック・ハイマンの法則

選択肢の情報量と、選んで反応するまでの時間との関係を扱う研究上のモデルです。「メニューは七個以下にする」といった個数のルールではありません。Web では、分類、検索、絞り込みを考える入口として使えます。第13章を参照してください。

フィッツの法則

ポインターを、ある距離だけ動かして一定の広さの対象へ合わせる時間を扱うモデルです。「すべてのボタンは必ず何ピクセル以上」という直接の寸法ルールではありません。マウス、指、姿勢、画面の揺れなども合わせて考えます。第14章を参照してください。

予想と操作後の返事

メンタルモデル

物事がどう動くかについて、経験から作られた理解や予想です。買い物かご、保存、戻る操作などで、利用者は過去の経験を持ち込みます。すべての人が同じ理解を持つわけではありません。第15章で扱います。

フィードバック

操作を受け取ったこと、処理中であること、成功や失敗などを画面から返すことです。色の変化、文章、音、振動などを使えます。単なるアニメーションの別名ではありません。

システム状態の可視性

いま何が起きているのかを、適切な時点で利用者へ伝える考え方です。「送信中」「保存しました」「通信できませんでした」などが例です。画面へ文字を一つ置けば終わりではなく、次に待つのか、直すのか、やり直すのかも伝えます。

ヤコブの法則

人は、ほかの Web サイトで覚えた使い方を新しいサイトにも持ち込む、という実務上の考え方です。慣れた方法を借りると学びやすくなりますが、独自の表現をすべて禁止する法則ではありません。

フォン・レストルフ効果

似た項目が続く中で、一つだけ異なる項目が記憶に残りやすくなることがある、という現象です。目立たせれば必ず押される、という法則ではありません。

知識の呪い

自分が知っていることを、知らない人の立場から想像しにくくなる傾向です。制作者だけが知っている略語や手順を、説明なしで画面へ置く問題を考える手がかりになります。

確証バイアス

自分が正しいと思っている説明に合う情報を集めやすい傾向です。好きな案の長所だけを見るのではなく、別の原因や反対の結果も考える必要があります。

馴化

同じ刺激が何度も続くと、反応が小さくなることです。通知やアニメーションを繰り返せば、いつでも同じように注意を引けるとは限りません。

一貫性

同じ意味や働きへ、同じ見た目、言葉、動きを使うことです。次に起こることを予想しやすくします。危険な操作など、違いを伝えるための例外まで消すことではありません。

Web 制作と調べ方

デザイントークン

色、余白、文字の大きさなどへ名前を付け、複数の画面で共有する仕組みです。CSS のカスタムプロパティなどで実装できます。値を共有しただけで、使い方まで正しくそろうわけではありません。

レスポンシブ Web デザイン

画面や部品の幅、文字の大きさ、入力方法などの条件に応じて、内容を読みやすく組み直す設計です。PC 版をそのまま小さく縮めることではありません。第22章を参照してください。

再配置

画面幅や拡大率が変わったとき、内容が折り返されたり縦へ積み直されたりすることです。英語では reflow と呼ばれます。

コンテナクエリ

画面全体ではなく、部品が置かれた領域の広さなどを条件にして、その部品の CSS を変える仕組みです。同じカードを広い本文と狭いサイドバーの両方で使うときに役立ちます。

ユーザビリティ

特定の人が、特定の状況で、目的をどの程度達成できるかを表す考え方です。製品に一つだけ付けられる「使いやすさの点数」ではありません。

ユーザビリティテスト

人が試作品やサービスで目的を達成する過程を見て、問題を知る方法です。感想だけを集めることとは異なります。実施には説明と同意、記録の扱い、途中でやめられる条件が必要です。第24章で著者の例を説明します。

考えていることを声に出す方法

画面を使っている間に、考えていることを言葉にしてもらう方法です。英語では think aloud と呼ばれます。発話は考えの手がかりになりますが、心の中をそのまま読み取れるわけではなく、話すこと自体が操作へ影響する場合もあります。

観察

どの画面で、いつ、何が起きたかを、ほかの人が確かめられる形で表すことです。「ボタンが分かりにくい」ではなく、「商品名の入力欄より価格の文字が近くにある」のように書きます。

別の説明候補

同じ出来事に対して考えられる、もう一つの原因です。ボタンを押しても画面が変わらないとき、ボタンが動いていない場合だけでなく、通信中を表示していない場合も考えられます。

判断の記録

何を見て、何を変え、何が分かり、なぜ公開や保留を選んだのかを残す記録です。結論を正しく見せるためではなく、あとから判断の理由と、まだ分からないことを確かめるために使います。

付録 B　曖昧なレビューの言葉を、次の会話へつなげる

デザインを見ていると、「ダサい」「いい感じ」「分かりにくい」のような言葉が出ることがあります。

こうした言葉を禁止する必要はありません。まだ理由を説明できない違和感や好ましさが、最初に短い言葉として出てくることはあるからです。

大切なのは、その一言で会話を終えないことです。

「ダサい」と言われたら

「どこがダサいですか」と聞くだけでは、答える人も困ります。画面を一緒に見ながら、文字、色、形、写真、余白のどこが気になったかを聞きます。

たとえば、見出しは線の細い明朝体、ボタンは太く直線的な書体、補助の言葉は手書き風だったとします。それぞれの書体が違うこと自体ではなく、どの役割にどの書体を使うのかが画面内で繰り返されていない、と説明できます。

流行から外れていること、個人の好みと違うこと、目的に合っていないことは別です。「ダサい」を、誰にとっても同じ美しさの基準にはしません。

「いい感じ」と言われたら

肯定的な言葉も、理由を聞く価値があります。何を残したいのかが分からなければ、次の修正でよかった部分まで消してしまうからです。

「見出しが本文よりはっきり大きくなり、何のページか先に分かる」「写真のまわりに余白ができ、作品と説明が競わなくなった」のように、変わった場所と役割を言葉にします。

「メリハリがない」と言われたら

まず、何と何が同じ強さに見えるのかを探します。

主要な申し込みボタンと、前のページへ戻るリンクが、同じ色、同じ太さ、同じ大きさで並んでいるのかもしれません。ページ名と項目名の文字サイズがほとんど同じなのかもしれません。

すべてを強くすると、強さの差はまた消えます。大切なものを決めたうえで、ほかの要素との大きさ、太さ、色、面積の差を考えます。

「余白が足りない」と言われたら

画面全体の余白を一度に増やす前に、どの二つの要素の間が問題なのかを確かめます。

項目名と入力欄の間より、入力欄と次の項目名の間が狭ければ、どの入力欄がどの項目に属するか分かりにくくなります。この場合は、すべての余白を広げるのではなく、一つの項目の内側と、次の項目までの距離を分けて直します。

「分かりにくい」と言われたら

何をしようとしたとき、どこで分からなくなったのかを聞きます。

送信ボタンを押したあとに画面が変わらず、待つのか、もう一度押すのか分からなかった。売り切れの商品が色だけで示され、購入できない理由が分からなかった。このように時点と対象が分かれば、必要な表示を考えられます。

実際に人が理解できなかったと確認する前なら、「分からないはずだ」と断定せず、「判断する手がかりが画面にない」と、見えている事実を説明します。

「直感的ではない」と言われたら

「直感」は、何も学ばず生まれつき分かることだけを意味しません。ほかのサイトで覚えた使い方が、新しい画面の予想を助けることがあります。

画面左上のロゴを押してもトップページへ戻らないなら、多くのサイトで覚えた使い方と違います。独自の操作が悪いとすぐ決めるのではなく、どの経験からどの結果を予想したのかを確かめます。

「UX が悪い」と言われたら

UX は、一枚の画面の見た目だけではありません。サイトを知り、使い始め、目的を終え、必要ならあとから戻るまでの経験を含む言葉です。

パスワードを再設定できても、元の申し込み画面へ戻るリンクがなく、トップページから探し直す必要があるなら、その途中の流れを具体的に説明します。「UX が悪い」を、ボタンの色が好みではないという意味には使いません。

「認知負荷が高い」と言われたら

何を覚え、何を比べ、何を考え続けなければならないのかを分けます。

三つ前の画面で選んだ権限名を覚え、現在の画面にある略称と比べなければならない。三十個のプランに違いの説明がなく、名前だけを一つずつ開かなければならない。二つでは、直す場所が異なります。

情報量が多いという見た目だけで、利用者の頭の状態を決めつけないようにします。

短い言葉から、具体的な言葉へ

曖昧な言葉が出たら、次の四つを順に確かめます。

1. 画面のどの場所について話しているか
2. 何と何を比べてそう感じたか
3. その場所は、どのような目的や操作に関係するか
4. 画面から確認できたことと、まだ予想にすぎないことは何か

長い決まり文句へ置き換えることが目的ではありません。「余白が足りない」から「項目名と入力欄より、入力欄と次の項目名の方が近い」へ進めば、同じ画面を見ながら次の修正を話せるようになります。

付録 C　参考資料一覧

本文の内容をさらに詳しく調べたい人のための資料です。研究論文は、実験の条件と結果を分けて読んでください。Web の仕様は更新されるため、リンク先で現在の版も確認してください。

E.1 知覚心理学

• [E1-01] Max Wertheimer, “Laws of Organization in Perceptual Forms,” 1923. ゲシュタルト心理学における、知覚のまとまりを扱った原典。歴史的文脈と現代研究を分けて読む。
• [E1-02] Kurt Koffka, Principles of Gestalt Psychology, 1935. ゲシュタルト心理学の体系的な古典。画面設計ですぐ使える法則集ではない。
• [E1-03] Stephen E. Palmer, Vision Science: Photons to Phenomenology, MIT Press, 1999. 図と地、まとまり、奥行きなどを広く学ぶ専門書。

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. 条件つきで短期記憶の容量を論じた資料。画面の項目数を決める万能ルールにはしない。
• [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.

三論文はいずれも、実験条件と数式による説明を読むための一次資料です。選択肢の数や、クリック領域の大きさを決める万能ルールには変換しません。

E.5 HCI

• [E5-01] ISO 9241-210:2019, Human-centred design for interactive systems — 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 — 利用者、目標、Context と Usability の定義。
• [E6-02] James R. Lewis, “Sample Sizes for Usability Studies: Additional Considerations”, Human Factors, 36(2), 1994 — 問題発見と参加人数の考え方。特定の人数を万能ルールにしない。
• [E6-03] GOV.UK Service Manual, “Using moderated usability testing” — 実務的な入口。組織・地域の倫理規程を別に確認する。

E.7 UX リサーチ

• [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 — Formative／Summative と Process。医療 EHR 文脈をそのまま一般化しない。
• [E7-03] U.S. HHS OHRP, The Belmont Report — Respect、Beneficence、Justice の歴史的入口。各地域の法令・審査を置換しない。

E.8 Web デザイン

• [E8-01] Ethan Marcotte, “Responsive Web Design,” A List Apart, 2010. Responsive Web Design という整理の歴史的入口。
• [E8-02] W3C, Design Principles — Web Platform 設計原則。個別 UI の見た目 Rule ではない。
• [E8-03] W3C Design Tokens Community Group, Design Tokens Format Module — 公開時点の Draft status と版を確認する。

E.9 CSS とブラウザ

• [E9-01] MDN Web Docs, CSS — 読みやすい仕様入口。Normative source は対応する W3C／WHATWG 仕様。
• [E9-02] CSS Working Group, CSS Containment Module Level 3 — Container Queries を含む仕様。
• [E9-03] CSS Working Group, CSSOM View Module — Viewport、Geometry、Scroll 等。
• [E9-04] WHATWG, HTML Living Standard — 入力フォーム、ボタン、キーボード操作時の選択位置、HTML が伝える意味の正式な仕様。
• [E9-05] WHATWG, DOM Standard — DOM と Event の正本。

E.10 アクセシビリティ

• [E10-01] W3C, Web Content Accessibility Guidelines (WCAG) 2.2 — Success Criteria と Conformance。
• [E10-02] W3C, WAI-ARIA 1.2 — Role、State、Property の意味論。ARIA だけで挙動を自動実装しない。
• [E10-03] W3C, ARIA Authoring Practices Guide — 操作部品の実装例。製品ごとの要件確認と、ブラウザ・支援技術での検証を別に行う。
• [E10-04] W3C WAI, Understanding WCAG 2.2 — Success Criterion の意図と例を読む補助資料。Normative 本文と区別する。

検索結果に表示された短い要約だけで判断せず、可能なら元の論文や公式仕様を開き、本文で扱っている内容と条件が合うかを確認してください。

索引

この電子版では、ページ番号の代わりに、その言葉を詳しく扱う章へリンクします。短い意味を確かめたい場合は、付録 A の用語集を参照してください。

画面のまとまりと見え方

• 近接 — 関係する情報の距離
• 整列 — 左右の端、中心、文字の基準線
• 類同と一貫性 — 似た見た目と同じ働き
• 閉合、共通領域、図と地 — 輪郭、囲み、前後関係
• 動きと注意 — 通知、画面の切り替え、動きを減らす設定
• 文字の形と文字組み — 書体、行間、文字の強さ
• 色とコントラスト — 周囲との関係、状態、読みやすさ
• 構成、反復、余白 — 画面全体の情報量とリズム

注意、記憶、選択、操作

• 注意と視覚的階層 — 目立つものと探しているもの
• ワーキングメモリとチャンク化 — 覚えながら考える負担
• 再生と再認 — 思い出して入力することと、候補から選ぶこと
• 選択肢、検索、絞り込み — 多くの候補を選べる形へ整理する
• フィッツの法則と操作できる範囲 — マウスや指で対象を選ぶ

予想、規則、操作後の返事

• メンタルモデルと Web の慣習 — 過去の経験から次を予想する
• 操作できそうな見た目 — 見た目と実際の働き
• 一貫性とフィードバック — 同じ規則と操作後の返事
• 知識の呪い、確証バイアス、馴化 — 制作者の知識と繰り返しの影響

制作中に画面を調べる

• 画面の違いを具体的に言葉にする
• 専門用語だけで原因を決めない
• 二つの案を公平に比べる
• 画面幅、拡大、長い内容、通信状態
• ブラウザの開発者向け機能 — HTML、CSS、通信、アクセシビリティツリー
• 人が使う場面から分かること — ユーザビリティテスト、発話、同意
• 作った画面から次の改善を見つける — 判断の記録、公開、保留

よく使う実装用語

• デザイントークン
• レスポンシブ Web デザイン
• 再配置
• コンテナクエリ
• ユーザビリティ
• 観察
• 別の説明候補
• 判断の記録

曖昧なレビュー表現を具体的な言葉へ直す例は、付録 B「曖昧なレビューの言葉を、次の会話へつなげる」にまとめています。