第 IV 部統合ケース　違和感を、公開判断まで運ぶ

第 19〜25 章では、画面の違いを言葉にする方法、二つの案の比べ方、ブラウザで HTML や CSS を調べる方法、人が使う場面の見方を扱いました。ここでは、架空の権限申請サービスにある一つの違和感を、公開するかどうかの判断まで著者が順に追います。

気になったのは、「申請ボタンを押しても画面が変わらない」ことです。以下は説明用に作った架空の画面であり、実在する利用者の調査結果ではありません。

1　最初に、見えた事実を言葉にする

パソコンの画面で申請ボタンを押しました。通信には 4 秒かかるように設定しています。押す前と、押してから約 0.5 秒後を比べても、ボタンの色や文字は同じままで、処理が始まったことを伝える表示もありません。

この画面だけから分かるのは、見える変化がないことです。ボタンが押されたことをプログラムが受け取ったか、申請がサーバーへ届いたか、画面読み上げへ変化が伝わったかは、まだ分かりません。

見えるフィードバックが足りないのかもしれません。クリックイベントが動いていない、通信結果を失った、状態を伝える HTML がない、といった別の原因も考えられます。

まず、「送信しています」という表示だけを加えます。この言葉が表すのは、送信を始めて返事を待っていることです。申請が受け付けられた、処理が成功した、という意味ではありません。

一つの画面幅で成立しても、別の条件では状態表示が操作から離れることがあります。まず 320px 幅で、ボタンと状態表示が近いまま読めるかを見ます。

200%へ拡大すると、文字と部品が大きくなり、下にある情報が画面外へ移りやすくなります。

長い共有フォルダ名は複数行に折り返し、その下の操作を押し下げます。短いテストデータだけでは見えなかった変化です。

オフラインでは、いつまでも「送信しています」と表示しても回復できません。接続できないことと、次に何をすればよいかを伝える必要があります。

この四枚は、幅、拡大、文章の長さ、通信状態を別々に変えています。全部を一度に変えると、どの条件で問題が現れたのか分からなくなるためです。

もう一度、元の画面を見ます。送信後の変化はありません。

ブラウザの開発者向け機能で HTML を見ると、入力フォームとボタンはありますが、「送信中」や「完了」を入れる場所がありませんでした。開発者向け機能は、表示中のページを作っている HTML や CSS、通信などを調べるための道具です。

次に、ボタンを押した記録を見ます。プログラムはクリックを受け取り、送信処理を始めていました。つまり、「ボタンが押されたことを受け取れていない」という原因ではなさそうです。

ブラウザからサーバーへ申請のデータも送られていました。ただし、「ブラウザが送った」ことと「サーバーが申請を保存した」ことは別です。この記録だけでは、申請が成功したとは言えません。

ここまでで、クリックと通信は始まる一方、送信中の状態と表示場所がないことが分かりました。利用者が表示を理解するかは、人の行動を見る別の問いです。

イベントや HTML の欠落は、まず技術検査で調べられます。人の行動を見る価値があるのは、状態を理解できるか、もう一度押すか、失敗から戻れるかといった問いです。

実際に人を対象にする場合は、第24章で見た同意、記録媒体、データの保存、中止条件を先に整えます。本番のアカウントや個人情報は使いません。技術的に壊れていると分かっている試作品へ、必要もなく参加者を巻き込みません。

二重処理を防ぎ、状態が見えるだけでなく支援技術にも伝わり、失敗から回復できることを確かめたら、公開を選べます。

根拠が足りない場合は保留します。期限が来たことは、不明な問題が解決した証拠にはなりません。

重大な不具合が見つかった場合は、変更を取り消します。取り消しは制作の失敗ではなく、利用者を危険へさらさない判断です。

自分に決定権がない場合は、観察条件、分かった事実、未確認の範囲を、判断できる担当者へ渡します。

公開後に重複処理、回復できない失敗、問い合わせの増加が起きたら、いったん終えた判断を再び開きます。

このケースで最初にあったのは、「押せたか分からない」という小さな違和感でした。それを具体的な画面差へ変え、別の原因を残し、一つだけ変え、画面条件と実装を確かめることで、公開判断まで筋道をつなげられました。

デザインを見る力は、すぐに修正案を出す速さではありません。何が見え、何がまだ分からず、次にどの根拠が必要かを区別できることです。

詳しい技術仕様と参考資料は、第19章から第25章の参考文献にまとめています。