第 IV 部　Web デザイナーは、どう見るか

ここまで、近接、注意、記憶、期待、フィードバック等の名前を知りました。しかし、名前を画面へ貼ればレビューが完成するわけではありません。

「これは近接の原則です」「認知負荷が高いです」「知識の呪いです」という言葉は、観察を省略すると結論だけを強くします。第 IV 部では、理論を答えとして当てるのではなく、違和感を第三者が確かめられる記録へ変えます。

三つの根拠

• 画面: 距離、位置、色、文字、状態、変化として何が見えるか。
• コード: DOM、CSS、データ、部品、イベント、ネットワークに何が実装されているか。
• 人: 何を予測し、どこで止まり、何を操作し、結果からどう回復するか。

三つは互いの代わりではありません。CSS 値が揃っていても視覚的に揃うとは限らず、画面が分かりやすそうでもタスクを完了できるとは限りません。一人が完了しても、すべての利用者へ一般化はできません。

観察、解釈、評価

第 IV 部では、記録を三つへ分けます。

• 観察: 第三者が同じ条件で確認できる記述。
• 解釈: なぜ起きたかについての仮説。
• 評価: 目的や価値に照らした判断。

分ける目的は、評価や美的判断を捨てることではありません。どこで事実から仮説へ進み、何を大切にして判断したかを話せるようにするためです。

一つの変更で一つの仮説を見る

比較するときは、可能な範囲で一つだけ変えます。余白、ラベル、順序、状態表示を同時に変えれば、どの仮説が支持されたか分かりません。

実務では複数変更を含む完成案も必要です。その場合は、因果を調べる比較と、統合した設計案を分けます。改善、正解、ベストプラクティスという言葉を、測定前の案へ付けません。

第 IV 部の流れ

1. 違和感を観察語へ変える
2. 名前を使って複数仮説を作る
3. 並べ、重ね、差を見る
4. ブラウザを動かして壊れる条件を見る
5. DevTools で実装を監査する
6. 人の行動で仮説を限定的に確かめる
7. 作り、見て、疑い、また作る

最終章では、第1章と同じ画面へ戻ります。模範解答を当てるのではなく、最初には持っていなかった観察語、仮説、確かめ方を使い、自分の目がどう変わったかを確認します。