『誰のためのデザイン？ 増補・改訂版 ―認知科学者のデザイン原論
ケーススタディ: 居酒屋の店員呼び出しボタン
ひとつ目のケーススタディとして、居酒屋などに置かれている店員を呼び出すためのボタンを考えてみよう。
まずはボタンそのもののデザインとして、多くの場合はボタンを押した時に「カチッ」という押した感じと、その後にボタン自体が上に押し戻されるというシンプルなフィードバック機能は備えられていることは多い。この「カチッ」という感覚をユーザーにフィードバックすることで、「このボタンは問題なく動作し、押すことができた」ということをユーザーが認識できるようになっている。
このフィードバック機能自体はほとんどのボタンに実装されているため、問題ではない。さすがに「ボタンの押した感じが得られないボタン」というのはここの議論では無いとしよう。
音が鳴るボタンと鳴らないボタン
このケーススタディで議論にあげたいのは、ボタンを押した時に流れる音声の有無とその内容だ。居酒屋によって、ボタンを押した時に音声が全く流れない場合（パターンA）もあれば、ユーザーに聞こえる範囲でそのボタンから「ピッ」という音が流れる場合（パターンB）、店内全体に「ピンポーン」という音声が流れる場合（パターンC）などの様々なパターンが存在する。
これらの音声は全てフィードバックだ。この音声がUXに対して大きな影響を持つ。例えば、ボタンを押して暫くたっても店員が来ない場合があるとしよう。この状況下で、ボタンを押した時に店内全体に音声が流れている仕組み（パターンC）であれば、あなたは「店員が聞き逃したのかも」と想像するだろう。これに対して、ボタンが「ピッ」となるだけの場合（パターンB）だと、「ちゃんとこのボタンは店員に伝わってるのか？」と思い、もう一度ボタンを押すだろう。さらに別の場合で、ボタンから音声フィードバックがない場合（パターンA）だと「このボタンはちゃんと動いてるのか？」と思い、2,3回連続でボタンを押した経験はないだろうか？
フィードバックがストレスを左右する
このように、フィードバックによってユーザー体験は大きく異なり、ユーザーが取りうるアクションが変わってくる。このケーススタディだと、ユーザーが感じるストレスはパターンC→パターンB→パターンAの順に大きくなり、パターンAが最も最悪だと言える。パターンAだと、最終的に「すみませーん！」と言ってボタンを使わず店員を呼ぶ人が生まれてしまうのである。つまり、デザインとしての欠陥がフィードバック機能の質によって浮き彫りになった形だ。
この例の中でも最もユーザーのストレスが軽減されているパターンCでも、「店員に伝わったのか」ということが確認できないためベストなデザインとは言えないだろう。居酒屋店のコストを無視して考えるのであれば、ボタンのすぐ近くに「確認しました」「すぐお伺いします」「少々お待ち下さい」のような項目に対してランプが付き、店員からのフィードバックがユーザーに伝わるような設計が理想だ（あくまでもコストを無視してデザインだけに議論をフォーカスした場合だともう一度書いておく）。
フィードバックはユーザーの「イライラ度」を左右する
上記の例の他にも、押しボタン式信号の押しボタンが反応したかわからない問題や、図書館などの書籍検索タッチパネルや切符購入時の検索ボタンをおした時にローディング中なのかボタンが反応していないのかがわからない問題などがある。アプリやWebサイトでは、ローディング画像系がその最たる例だろう。
フィードバックの質が悪いことはユーザーをとても苛つかせる。自分が取ったアクションが正しく機械に伝わっているのか「わからない」から、次にどうしたらいいのかも「わからない」。わからないがわからないを生み、ユーザーは立ち往生してしまう。
Webサイト等で言えば、ボタンを立体的にしておした時に少しボタンがへこむようなフィードバックも大切だが、どちらかというとボタンをおした時に次のステップへの移行中であることを示すフィードバックの方が重要だろう。なぜなら、ボタンをクリックしたときにボタンがへこんだからと言って、その後にローディングアイコンなどが全くなく２、３秒待たされる方がユーザーとしては心配になるからだ。
デザインにおけるフィードバックはUXにおいて重要な役割を果たすため、プロダクトをデザインする時には頭の片隅に入れておきたい。
