Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

第 III 部統合ケース 規則を学び、例外に出会い、回復する

第 15〜18 章では、過去経験からの予測、反復が作る規則、行為へのフィードバック、作者と利用者の知識差を見ました。実際の Web 利用では、それらが時間の中で重なります。

本ケースでは、架空の権限申請サービス「Michi Access」を初めて使い、申請を繰り返し、例外に出会い、通信障害から回復し、翌日に再訪する流れを追います。

目的は、利用者の頭の中を物語として決めることではありません。各時点の画面、操作、状態、発言、実装を分け、どの概念が説明候補になり、何がまだ未観察かを記録します。

到達目標は、一つの時刻付き観察から第 15〜18 章を横断する複数仮説を作り、追加根拠、実装監査、一軸介入、反証、別段階への副作用まで追跡できることです。

共通タスクと二つの観察系列

閲覧権限を申請し、オーナー承認後に IdP 設定を完了する。途中で一件の例外申請と応答消失が発生する。

全段階で固定するのは、画面条件、画面文法、タスク目標です。アカウント、カテゴリー、緊急性、権限、内容、ネットワーク障害は試行ごとの条件として記録します。統合物語では連続して見せますが、観察研究で全障害を一人へ必ず順番に注入する設計ではありません。

  • 自然行動系列: 事前に予測を尋ねず、最初の操作から観察する。
  • 明示予測系列: 別参加者に、操作前の予測を尋ね、その質問の影響下で操作を追う。

二系列をつないで一人の心的更新にしません。初回、同セッション内の反復、24 時間後の保持、別内容への転移も別試行として記録します。

共通 Task、二系列、三時点の設計を示す図。
図 III-1 共通 Task、二系列、三時点の設計

第 1 段階 初回――持ち込まれた期待と作者の前提

ロゴ、ボタン、パンくずリスト、承認という語から、利用者は過去の Web、プラットフォーム、業務経験を持ち込みます。一方、作者は SCIM、IdP、オーナー、承認後の別システムを知っています。

観察台帳を分けます。

根拠記録
画面見えるテキスト、名前、役割、状態、リンク
作者前提知識、意図、概念モデル
自然行動最初の操作、停止、戻り、完了
回顧発言操作後の予測説明
実装ルート、権限、状態、イベント

「初見者は用語を知らない」「管理者なら分かる」と決めず、領域経験、同種 UI 経験、言語、デバイス、支援技術を記録します。

初回の五つの Evidenceを示す図。
図 III-2 初回の五つの Evidence

第 2 段階 反復――規則を学ぶ

三件の通常申請では、青いボタンは申請、右端の山形アイコンは詳細、承認後は次操作リンクが現れる、という表現と役割が反復します。

観察された反復と、推測された規則と、実装仕様を分けます。三回続いたから全員が学習したとはしません。次の同型画面で最初の操作が変わるか、規則を説明できるか、24 時間後も保持するかを別に確認します。

同じ通知への反応が減っても、直ちに馴化と呼びません。刺激の反復、反応指標、刺激特異性、回復を観察する手順が必要です。

反復、推測規則、実装仕様を示す図。
図 III-3 反復、推測規則、実装仕様

第 3 段階 例外――何が違い、なぜ違うか

四件目は subject_type=contractorurgency=urgentpermission=read の権限申請です。契約者種別、緊急性、危険度、権限は別データ項目で、どれが赤、ラベル、角丸へ対応するかは監査前には未確定です。差は意図された優先、危険状態、別カテゴリー、ブランド表現、実験条件、権限、旧部品残存のどれでも説明でき、複数が同時に成立する場合もあります。

まず色、角丸、ラベル、位置、動きという物理差と出現条件を記録します。データ、部品、バリエーション、トークン、権限、機能フラグを監査します。顕著性、注意、理解、選択、完了を一つの「目立った」にまとめません。

改善候補は一軸ずつ比べます。カテゴリーラベルだけを加える案、ボタン文法だけを揃える案を別案にします。ブランド上の価値、学習コスト、誤申請リスク、回復可能性を並べます。

例外の物理差、七仮説、一軸介入を示す図。
図 III-4 例外の物理差、七仮説、一軸介入

第 4 段階 待機と失敗――結果不明から回復する

申請ボタンを押し、サーバーでは処理が成功しましたが、応答だけが失われます。クライアントにはタイムアウトが見えます。これは失敗確定ではなく、結果不明です。

受付、処理中、成功、失敗、取消要求中、結果不明、再照会、回復を状態表にします。リクエスト ID、操作 ID、冪等性キーを同義にしません。新しい申請を再試行する前に、同じ操作を再照会します。

フィードバックはアニメーションだけではありません。「申請状況を確認中」という見えるテキスト、操作可能性、プログラム上の状態、ステータス通知を同期します。役割があること、特定環境で通知されたこと、意味が理解されたことは別の根拠です。

結果不明と回復の状態機械を示す図。
図 III-5 結果不明と回復の状態機械

第 5 段階 再訪――保持と転移を分ける

24 時間後の保持試行では同じアカウント/内容/規則を使います。その後の転移試行で、規則を固定してアカウント/内容だけを変えます。時間間隔と内容変更を一条件へまとめません。作者は正解を知ったままなので、再訪した作者の自己評価を初見根拠にしません。

初回操作、タスク固有の到達基準、即時再試行、24 時間後の保持、別内容への転移を分けます。二回連続成功はこの画面条件の運用基準で、人間一般の学習成立条件ではありません。初回で失敗して一度で学べた UI と、毎回迷う UI を区別します。一人の保持を全利用者へ一般化しません。

文化、世代、プラットフォーム、支援技術で期待が異なる可能性は、文脈別の仮説です。人物属性を原因とせず、利用履歴、入力方法、提示された手がかり、実装状態を確認します。

初回から再訪までの Evidence 境界を示す図。
図 III-6 初回から再訪までの Evidence 境界

予防、検出、影響緩和、回復

エラーをゼロにするだけが設計ではありません。

  • 予防: 誤解されるカテゴリー差や重複操作を減らす。
  • 検出: 受付、競合、結果不明を利用者とシステムが知る。
  • 影響緩和: 入力データを保持し、重複業務処理を防ぐ。
  • 回復: 再照会、修正、取消、サポートへ到達できる。

どの層を変えたかを分けます。ボタンラベルの変更はサーバー冪等性を作らず、冪等性は状態理解を自動で作りません。

一本の観察を四章で読む

時点観察横断仮説追加根拠一軸介入反証・副作用
T+18s四件目で入力なし。その後戻る慣習と予測の不一致/三件の反復規則との衝突/受付状態の誤読/契約者用語・権限前提/読解・外部中断行動後発言、ボタンイベント、権限、ネットワーク契約者ラベルだけ追加ラベル後も停止/通常申請の密度増加
T+31s送信後に再度送信受付フィードバック不足/イベント重複/応答消失/サーバー処理不明/作者だけが再照会手順を知る操作/リクエスト/サーバーログ、DOM、状態見える受付テキストだけ追加利用者試行で再押下が変わらない

時刻は記入形式を示す例の値で、利用者の実測結果ではありません。実調査では元イベントを保存し、何秒を「迷い」とする普遍的閾値を置きません。

統合手順は、観察→四章横断の複数仮説→必要根拠→状態所有者別の実装監査→一軸介入→反証→別段階・入力方式・対象者への副作用確認です。

問い

  1. いま観察した事実を、第 15〜18 章のどの複数概念で説明できますか。
  2. 仮説を見分けるため、画面、行動、発言、実装、サーバーの何が必要ですか。
  3. 誰が、どの状態を、いつ知れる/知れないですか。
  4. 一つだけ何を変え、何を固定しますか。
  5. どの結果なら仮説を弱め、別段階や入力方式へ何を悪化させますか。
  6. ブランド価値、学習コスト、領域リスク、回復をどの根拠源から記録しますか。

答えの例

四件目で停止したという一つの観察に、過去のボタン慣習との不一致、三件で推測した規則との衝突、フィードバック不足、契約者用語・権限の前提、読解や通信という仮説を残します。観察は操作が一定時間なかったことと戻る操作だけで、原因はまだ不明です。行動後発言、権限、ネットワーク、部品バリエーションを追加します。

申請後のタイムアウトは失敗確定ではありません。同じ操作 ID を再照会し、サーバー成功なら完了状態へ同期します。「再送」ラベルだけを「状況を確認」へ変える案と、サーバーの冪等性を加える案は別に検証します。結果不明注入数を分母に確定到達率、重複業務処理率、状態説明を記録します。

別解として、緊急申請が法的・業務的に異なるカテゴリーなら、差を消すより理由を明示する方がよい場合があります。よくある説明の「一貫性がない」「フィードバックがない」「初見者には難しい」だけでは、対象、時点、状態、根拠が不足します。

別の観察例 1――承認後に次へ進まない

観察は、承認済み表示の後に同じページを往復し、IdP 設定へ到達しなかったことです。承認でタスク完了と予測した、反復した青ボタンを次操作と認識しなかった、状態更新を検出できなかった、IdP という前提を作者だけが知る、リンクがフォーカス順外という仮説を残します。行動後発言、アクセシビリティツリー、フォーカス順、ルート、権限を追加根拠にします。次操作リンクの見えるラベルだけを変え、到達率を承認済み試行数で割ります。到達が変わらずフォーカス順が壊れていれば、文言仮説は弱まります。よくある考え方は「承認済みと出ているので分かる」です。状態の検出、意味理解、次操作は別です。

別の観察例 2――再訪で通常申請も止まる

観察は、24 時間後の同一内容の保持試行で通常申請の前に戻ったことです。規則を保持しなかった、初回はヘルプに依存した、例外の赤ボタンが通常規則を更新した、アカウント状態が変わった、単に中断されたという仮説があります。接触履歴、ヘルプ、開始時の画面記録、行動後説明、部品版を確認します。ヘルプ表示だけを固定して保持試行を再設計し、正しい初回操作/保持試行数と副作用のヘルプ依存を記録します。内容を変える転移試行は別にします。「翌日できないので UI が直感的でない」だけでは、保持、状態差、追加接触を分けていません。

独習と倫理

紙上では記入済みログを根拠の層と四章の仮説へ分類します。一人では架空の画面条件を操作し、機能点検と自分の行動を別にします。他者観察では、自然行動か明示予測の一系列、一つの障害注入だけに限定します。

自由意思、同意、休止・中止、録画/音声/操作ログの別同意、仮名化、閲覧者、保存期間、撤回を定めます。同僚・部下が断っても不利益を受けないようにし、安全情報を隠しません。応答消失と権限例外は架空環境だけで注入し、実アカウントや本番環境へ接続しません。

共通評価観点

観察と推論、四章横断の最低二仮説、必要根拠、知識と状態の所有者、一軸介入、分母、反証、副作用、一般化範囲を確認します。

セルフチェック

  • 初回、反復、例外、失敗、再訪を別試行として記録した
  • 画面、作者、自然行動、回顧発言、実装を分けた
  • 例外に複数仮説を残し、一軸介入を選んだ
  • 失敗確定と結果不明、再照会と再試行を分けた
  • ブランド価値と学習コスト、リスクを単一スコアにしなかった