第25章　作って、見て、また作る

最初の案だけで、まだ分からない全条件に正しい画面を作れないことは、制作の失敗ではありません。作る前には見えなかった内容、状態、利用者、技術条件が、作って動かすことで初めて見えるからです。既に分かっている法令、安全、プライバシー、アクセシビリティの非交渉要件まで「試してから考える」という意味ではありません。

本章では、本書で学んだ観察、概念、実装、比較、利用者検証を、一度きりの手順ではなく反復可能な制作習慣へまとめます。反復は必ず円形に一周するわけではありません。途中で前へ戻り、別の仮説へ枝分かれし、十分な根拠が得られたら止めることも含みます。

読み始める前の確認

序章で観察メモを残した人は、この先の著者例を読む前に 読後の観察メモ を開いてください。序章のメモはまだ見ずに、同じ画面をもう一度 30 秒だけ見て、最初に目に入ったものと気になった場所を書きます。その後で、時間を気にせず観察を広げます。

序章で観察メモを残していない人は、最初と最後の比較はできません。その場合は、単独観察メモ を使い、別の初見画面を読後の観察練習として見ます。ここで書かなかった記録を、後から自己 Before／After として補うことはしません。

25.1 最初から正解を作れないのは、失敗ではない

企画時には短い商品名しかなくても、本番では長い名前、在庫切れ、通信遅延、権限差、支援技術による操作が現れます。最初の案は、未知を発見するための外在化でもあります。

反復を「最初のデザインが下手だった証拠」と捉えると、作者は案を守り、都合の悪い観察を例外にしやすくなります。案を暫定的な仮説と捉えれば、変更は敗北ではなく学習になります。ただし、無期限に作り直すことも目的ではありません。重大なリスク、未解決の不確実性、変更コスト、公開期限を見て、次に何を確かめる価値があるかを選びます。

25.2 Best Practice は文脈つきの候補である

「選択肢を減らす」「一貫させる」「動きを抑える」は、出発点にはなりますが、目的を離れた正解ではありません。救急時に選択肢を隠せば危険になり、意図された警告まで一貫させれば区別できず、状態変化を伝える動きをすべて消せば結果を見失うことがあります。

候補を採用する前に、誰が、どの状況で、何を達成し、失敗すると何が起こるかを記します。理論やガイドラインは判断の根拠の一部です。ブランド、内容、アクセシビリティ、プライバシー、性能、実装・運用コスト、法令、安全性も同じ表に置きます。すべてを一つの点数へ潰さず、譲れない条件とトレードオフを残します。

25.3 目的と利用状況へ戻る

局所的な Before／After で整って見えても、タスク全体を悪化させることがあります。ボタンを大きくした結果、重要な比較表が画面外へ押し出されるかもしれません。入力を段階化した結果、全体を確認したい熟練者の往復が増えるかもしれません。

変更ごとに次を確認します。

• 対象となる利用者と利用状況は何か。
• 支える目標と、守るべき表現意図は何か。
• 成功、失敗、回復を何で観察するか。
• どの制約を固定し、どの制約を交渉できるか。
• 改善が別の人、状態、入力方法へ移したコストはないか。

「ユーザーのため」と作者が代弁するだけでは足りません。観察した行動、発言、実装状態、組織上の要件を出所つきで分けます。

25.4 作る―見る―気づく―言葉にする

まず、考えられる最小の形を作ります。完成品に限らず、紙、静止画、HTML、本番に近い仮データなど、確かめたい問いに必要な忠実度を選びます。

次に、第19章のように、読む前の塊、距離、揃い、類同、強さ、状態、例外を見ます。「ダサい」「分かりにくい」と評価する前に、見えた差を記述します。

観察: 同じ完了操作を持つ三つのボタンのうち、二つは右端、一つはカード左下にある。

気づきを早く修正案へ変えず、スクリーンショット、表示幅、内容、時刻、状態を残します。言葉にすることで、後の自分や他者が同じ対象を確認できます。

25.5 名前を知る―疑う―仮説を立てる

観察に「一貫性」「近接」「再認」などの名前を接続すると、見落としていた比較軸や先行研究を探せます。しかし名前は原因の確定ではありません。

私は、三つ目のボタンだけ位置が異なることを観察した。反復した位置から次の操作を予測している人は、三つ目を見つけるまで余分な探索をする可能性がある。位置を揃えると最初の到達が早まるのではないか。

代替仮説として、ラベルが異なる、カードの見出しが弱い、画面外にある、キーボードのフォーカス順が違う、三つ目だけ権限がない、などを残します。「位置を揃えても探索経路が変わらない」は仮説を弱める結果です。

25.6 変える―比べる―人間を見る

第21章のように比較したい差を一つに絞り、第 22・23 章のようにブラウザと DevTools で状態・幅・内容・実装を点検します。その後、第24章のように、人の行動で仮説を確かめます。

すべての問いに利用者テストが必要なわけではありません。CSS の重複、フォーカス不可、表示名の欠落は実装監査で確かめられます。業務用語の理解、予測、回復経路は人を見なければ分からないことがあります。証拠源を問いに合わせます。

比較後は「改善した」で閉じません。固定条件、変えた軸、観察単位、分母、反証、悪化した側面を記録します。結果が曖昧なら、仮説を保持する、別仮説を調べる、計測を直す、変更を戻す、保留する、のいずれも正当な判断です。

25.7 反復の記録を残す

記録がなければ、同じ議論を繰り返し、過去の制約が永久のルールへ変わります。短い判断記録に、少なくとも次を残します。

判断記録は結論を正当化する装飾でも、担当者の評価表でもありません。予想と違った結果、欠測、途中で変わった条件、少数意見も残します。閲覧者、保持期間、変更履歴を定めます。個人データは複製せず、必要最小限の権限制御された場所へ参照し、その参照先が削除された状態も記録します。

一件を最後まで通す――送信後に変化がない

以下は手順を示す著者作成の例であり、実参加者から得た結果ではありません。

利用者観察を選ぶ場合、同意、記録媒体、記録の保持期間、撤回できる範囲、組織内の確認を第24章の手順へ接続します。速度のために参加者保護を省略しません。利用者や当事者が、目的設定、リスク判断、結果解釈へ関わることが適切な案件もあります。

25.8 序章と同じ画面を、もう一度見る

本書の最初に見た架空の申請画面を、もう一度見ます。序章で残した観察メモと、この章で書いた読後の観察メモを並べます。著者の例を読んだ後で書き足すと比較にならないため、読後の観察メモは本章冒頭で先に書いておきます。

これは教材効果を因果的に証明する実験ではなく、自分の記録の変化を見る内省課題です。画面を覚えている影響もあります。序章の観察メモがない場合は、Before／After とは呼ばず、未見の別画面を使う練習へ切り替えます。

最初の記録が「余白が変」「どこを押すか分かりにくい」だったとします。読了後には、次のような観察になるかもしれません。

• ラベルと対応する入力欄より、入力欄と次のラベルの距離が近い。
• 主要操作と補助リンクの色・面積・位置が同程度で、最初の視覚的優先を分けにくい。
• 送信後の受付、処理中、結果不明を示す見える状態が画面にない。支援技術へ状態が伝わるかは画面観察だけでは不明で、実装監査が必要である。
• 前画面で選んだ権限名を再生しなければ、現在の選択を照合できない。

これは画面の唯一の診断ではありません。観察から仮説、必要な証拠、確かめ方へ進めるようになったことを比べます。

25.9 増えた言葉ではなく、変わった観察を確かめる

専門用語の数で上達を測ると、Concept Dropping を促します。Before／After を次の観点で読みます。

1. 具体性: どの要素間の、どの差かを指せるか。
2. 証拠の境界: 見た事実、解釈、評価を分けたか。
3. 複数性: 一つの違和感に代替仮説を残したか。
4. 検証可能性: 何を変え、何を見れば仮説を弱められるか。

用語を使わなくても、この四点が増えていれば目は変わっています。逆に用語が多くても、「認知負荷が高いから悪い」で止まれば観察は進んでいません。

25.10 共通の診断結果を置かない。書き方の例は置く

同じ画面でも、利用者、タスク、状態、画面幅、業務リスクが違えば重要な問題は変わります。共通の診断結果を置くと、読者は画面を見る代わりに著者の語を探します。そこで、結論の正解ではなく、観察と推論を分ける書き方の一例を示します。

ただし「何でもあり」ではありません。観察対象を指せるか、証拠と推論を分けたか、別説明を検討したか、確かめ方が対象に合うかは相互に検討できます。答えを一つに固定せず、推論の質を話し合います。

問い

序章と同じ画面を見て、一つの違和感を観察、仮説、代替仮説、変更、反証条件へ展開してください。

答えの例

観察は「スクリーンショットでは送信ボタンを押した後、ボタンの見た目と文言、見えるステータス、フォーカス表示に変化がない」です。操作できるか、支援技術へ状態が伝わるかはまだ不明です。主仮説は送信中状態を検出できず再送する可能性、代替仮説はクリックイベント自体が発火していない、応答が失われ結果不明、支援技術へステータスが通知されない、です。

まずネットワーク、イベント、DOM、アクセシビリティツリーを確認します。送信直後にステータス領域を新設し、「送信しています」と表示する条件を作ります。ボタン状態と支援技術への通知は固定したまま、同じ遅延条件で比べます。再押下が変わらずイベント未発火なら、フィードバック不足という仮説は弱まります。公開候補では、支援技術への通知、二重送信防止、結果不明からの回復を追加で確かめます。

別の答え方

送信より前の入力グループに注目し、距離、見出し、エラー関連付けの複合仮説を立てても構いません。その場合は送信後状態を直す答えと競争させず、タスクのどの段階を扱うかを明記します。

よくある考え方

近接の原則とフィードバックを適用すればよい。

注意点

原則名だけでは、どこで何が起き、誰のどのタスクをどう支えるかがありません。複数の変更を同時に行うと、何が結果へ寄与したかも分かりません。

25.11 また作る

本書の流れは次のように書けます。

作る → 見る → 気づく → 言葉にする → 名前を知る → 疑う → 仮説を立てる → 変える → 比べる → 人間を見る → また作る

しかし実務では、どこから始めても構いません。比較中に観察記述へ戻り、人を見る前に実装不具合を直し、リスクが高ければ公開を止め、十分なら次の問いへ移ります。法令、安全、プライバシー、重大なアクセシビリティ破綻は公開前に必ず確認します。公開した場合も運用指標、問い合わせ、障害、支援技術での利用を監視し、再検討や取り下げの条件に達したら再び問いを開きます。矢印は命令ではなく、現在地を共有する地図です。

Web デザインを見る目とは、正解を知ることではありません。画面で起きていることに気づき、考えるための言葉を持ち、その言葉を疑い、人間と実装を見ながら確かめ続けることです。次に作る画面が、このループの続きになります。

セルフチェック

• 最初の案を正解でなく検証可能な案として扱った
• ベストプラクティスの対象、目的、制約を記した
• 観察、解釈、評価、実装事実を分けた
• 主仮説に代替仮説と反証条件を付けた
• 問いに合う証拠源を選んだ
• 変えた軸と固定条件を記録した
• 改善と同時に悪化・移転したコストを確認した
• 判断記録に未解決点と戻す条件を残した
• 用語数でなく観察の変化を比べた
• 十分な根拠で止める条件と次の問いを決めた
• 人を対象にするとき倫理・プライバシー確認を通した
• 公開後の監視と、再検討・取り下げの条件を決めた
• 自己比較を教材効果の実証と呼ばなかった

参考

• ISO 9241-210:2019, Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systems, https://www.iso.org/standard/77520.html — Human-centred design の活動と反復を確認する公式規格。規格本文は有料で、本書は特定の直線工程として単純化しない。
• Donald A. Schön, The Reflective Practitioner, Basic Books, 1983 — 行為の中の省察を考える古典。Design 手順のチェックリストではなく、専門実践の認識論として読む。
• Horst W. J. Rittel and Melvin M. Webber, “Dilemmas in a General Theory of Planning,” Policy Sciences 4, 1973, pp. 155–169, https://doi.org/10.1007/BF01405730 — 問題設定と解決が相互に変化する課題の入口。すべての UI 問題を同じ種類の Wicked Problem と呼ばない。
• Thomas P. Moran and John M. Carroll (eds.), Design Rationale: Concepts, Techniques, and Use, Lawrence Erlbaum Associates, 1996 — Design 判断と根拠を残す方法を深く調べる資料。
• W3C, Web Content Accessibility Guidelines (WCAG) 2.2, https://www.w3.org/TR/WCAG22/ — アクセシビリティを任意のトレードオフへ落とさず、適用要件と検証方法を確認する一次資料。