APIは高速なのにユーザーがボタンを連打してしまうUI
エンジニアがボタンの送信機能を実装し、完璧なロジックでバックエンドの処理を高速化させたとします。しかし、ユーザーがそのボタンを押したあと、画面上に何の反応も起きず、実際にはバックエンドで処理中である状況を想像してみてください。
ログや通信状況を見れば処理中だと分かるエンジニアとは異なり、ユーザーは内部処理を見ておらず、画面の反応だけで状況を判断します。いくら内部でシステムが動作していても、ユーザーに伝わらなければ「止まっている」のと同じです。画面に変化がないと、ユーザーは「押せていない」と判断し、システムがすでに処理を開始しているにもかかわらず、ボタンを何度もクリックしてしまいます。
こうした連打は、単にユーザーを不安にさせるだけではありません。二重送信によってデータの不整合が生じたり、同じ処理が繰り返し実行されることでサービス全体の動作が遅くなったりする原因になります。決済を伴う操作では、二重決済のような重大な問題につながるおそれもあります。
なぜこのような「反応がないUI」が作られてしまうのでしょうか。要因の一つとして、エンジニアの開発環境が挙げられます。エンジニアは高スペックなPCを使い、ローカルサーバーで開発しているため、1～2ミリ秒で通信が終わってしまいます。しかし、実際のインターネット環境や電車の中などでは通信に300ミリ秒ほどかかる場合もあり、その遅延を考慮できていないケースがあるのです。
また、AIを使って自動テストする場合も、ローカルサーバーへのアクセスであれば同様の問題が起こり得ます。その結果、ローディング表示やボタンの無効化（Disable）といった実装が抜け落ちてしまいかねません。AIが見落としやすいこうした点を、人間が実際の利用環境を想定して補う必要があります。
ユーザーに「体感上の安心感」を与えるフィードバックの設計
では、ユーザーを不安にさせないためには何が必要なのでしょうか。その答えが「フィードバック」と、その前段にある「対応付け」です。
ユーザーが迷わず操作するには、「何を操作すれば、何が起きるか」が分かる必要があり、操作後には「実際に何が起きているか」が伝わらなければなりません。前者が「対応付け」、後者が「フィードバック」です。フィードバックには視覚・聴覚・触覚によるものがありますが、Webでは音や振動に技術的・セキュリティ上の制約があるため、画面上の変化による「視覚的フィードバック」が中心となります。
具体的には、エレベーターのボタンを押すと点灯する、自動販売機で商品選択ボタンを押すと光る、といった「操作を受け付けたこと」を伝える視覚的な変化が身近な例です。改札を通過するときの「ピッ」という音は、聴覚的フィードバックの代表例といえます。
Webでも基本的な考え方は同じです。例えば、スマートフォンでボタンをタップした瞬間にボタンが一瞬沈み込む動作は、視覚的フィードバックの一例です。こうした状態変化によって、ユーザーは自分の操作が確かに受け付けられたことを瞬時に理解できます。
重要なのは、一つの操作に対しても「操作を受け付けた」「処理中」「成功した」「失敗した」といった複数の状態が存在することです。UI設計では、それぞれの状態を適切なフィードバックによってユーザーに伝える必要があります。
