200ミリ秒の遅延がユーザーに違和感を与える
人間は自分の動作に対して反応が「200ミリ秒（0.2秒）」遅れると、違和感を覚えると言われています。
Blakemore、Frith、Wolpertらの研究では、被験者がロボットを操作して自分の手をくすぐる実験が行われました。通常、自分で自分をくすぐってもあまりくすぐったく感じませんが、操作から刺激までの時間を遅らせると、くすぐったさが増していくことが分かっています。特に、遅延が0ミリ秒から200ミリ秒程度まで大きくなるにつれて、自分の動作による刺激として認識しにくくなり、外部からくすぐられた感覚に近づくというのです。
結果として、人間は「自分が操作した」という事実だけでなく、「操作に対して、期待したタイミングで反応が返ってくること」によって、自分の行為と結果を結びつけていることが分かります。
UIでも全く同じことが言えます。ユーザーがボタンを押したり入力したりした際に、画面がすぐに反応しないと、「押せていないのではないか」「操作が失敗したのではないか」という不安が生じます。ネットワーク処理などで結果の表示に時間がかかる場合でも、まずはローディング表示、押下状態の変化、トースト通知、スケルトンUIなどを活用し、「操作を受け付けた」ことを即座に伝えることが重要です。最終的な結果をすぐ返せない場合であっても、処理が開始されたことだけは直ちにフィードバックすべきです。
「処理の高速化だけでなく、体感上の安心感を設計することが重要である」とよく言われますが、この「安心感」とは「自分の操作が確かに受け付けられた」という感覚を指します。
会話に例えるなら、質問した時に相手が5秒間無言のままだと「怒っているのだろうか」と不安になりますが、「少し考えるから待って」という一言があれば安心できるはずです。この「考えるから待って」という一言こそがフィードバックであり、人が安心して次の行動に移るために不可欠な情報なのです。UIにおいても、同様の違和感や不安がより短い時間軸で生じていると考えると理解しやすいでしょう。
冒頭で提示した事例では、ネットワーク処理中の画面に何の変化も起きないことが連打を引き起こしていました。この問題を解消するには、適切なフィードバックとして、ボタンを押した瞬間に「送信中」、完了時には「送信しました」と表示されるようUIを改善する必要があります。
問い合わせページにおけるダメなUIの例も考えてみましょう。エラーが発生した際に「送信に失敗しました」とだけ表示されても、ユーザーには「今何が起きているのか」が分かりません。
ここでのポイントは、エラーメッセージで「何が起きたか」と「どうすれば解決できるか」の双方を伝えることです。送信失敗の原因が通信回線にあると分かれば、ユーザーは「通信環境を確認する」という次のアクションへスムーズに移ることができます。
原則として、ユーザーが操作できるすべての要素には何らかのフィードバックが必要です。例えば、Googleドキュメントのメニューなどは、カーソルを合わせるとクリック可能な要素が必ず何らかの反応を示します。「確定」のような重要なボタンの挙動は意識されやすいものの、「ファイル」「編集」「表示」といった基本的なボタンのフィードバックについては、開発者も見落としがちです。
こうした見落としを防ぐため、エンジニアは以下の2段階でチェックを行うとよいでしょう。
（1）自分で一通り触って確認する
まずは、すべてのボタンにカーソルを合わせて色の変化を確認し、クリック時の反応をチェックします。フィードバックが不十分な部分は、ユーザーに対して「なんとなく使いづらい」といった言語化できない違和感を与えてしまいます。
（2）ネットワーク速度を意図的に制限してチェックする
ブラウザの開発者ツールで通信速度を意図的に制限し、処理に時間がかかる状況を再現します。遅延が発生した際に、ローディングが表示されるか、ボタンが無効化されるかを確認します。
AIによる生成にも見落としは発生するため、最終的には人間による検証工程が極めて重要となります。
