更新日：
1. はじめに
機器やソフトウェアのユーザビリティの面から、システムからユーザにあたえるフィードバックの重要性は非常に高い。しかしフィードバックに関して、実際の開発に役立つ形での体系的な研究や書籍はほとんど見あたらないというのが現状である。本稿では、さまざまな事例やこれまでユーザーインターフェースのデザイン活動のなかで得られたことを中心にまとめていく。
またシステムからユーザに対して提示されるさまざまな情報の「表現」という面に関しても、主にフィードバックという切り口から見ていきたいと思う。
2. フィードバックとは
最初にフィードバックに関する簡単な定義をしておこう。ここで対象となるのは、図1のような操作のループを持つインタラクションシステムである。一般的な意味でのフィードバックは、「2. ユーザの操作」の直後にシステムから返される情報と考えられるが、2. の直前に提示されてユーザの操作を助ける情報もここではフィードバックに含めて考える。後に出てくるロールオーバーの例やフォーカスなどはマウス移動などの直後に出るものであるが、次の操作のために存在する情報である。またフィードバック情報は、主たるタスクを表す情報というより、操作を助けるためにシステム側から提示されるものである。
図1
フィードバックは何もディスプレイへの視覚的な表現に限ったことではない。サウンドによるフィードバックも時として非常に有効であるし、触覚のフィードバックに関してもすでに研究段階からカーナビゲーションシステムなどによって実用の段階に入ってきている。
3. フィードバックの重要性
フィードバックの重要性ということについて、次のような指摘をしておきたい。HTMLで構成された標準的なWebページはフィードバックという観点から見ると、非常に貧弱な環境である。たとえば通常のPCの環境では当たり前のボタンのクリックに対する押し込まれたようなフィードバックもないし、タブのように表現されたものも、操作をしてみるとすぐにそれは単なる「タブの形をした絵」であることがわかってしまう。それでも毎日、世界中の多くの人々に使われて、情報の収集や交換に大いに役に立っている。だとすると、情報収集などに関してはフィードバックはそれほど重要ではないのだろうか？
もし当初からHTMLの仕様の中にフィードバックに関する要素が入っているか早い段階で取り入れられていれば、もっと豊かでスムーズな操作感が実現されて、比較できればであるが、より満足度の高い使用体験がユーザに与えられていたと考えられる。現状ではJavaScriptやFlashなどの高度な手法を駆使できる人のみが、リッチなフィードバックを実現するにいたっているが、これらは残念ながらその場限りの対応になっているといえるだろう。ここでのフィードバックによる成果とは、相対的により満足度の高い使用体験ということになる。
もう少しクリティカルな操作の例をあげると、最新鋭の航空機のコックピットにはコンピュータディスプレイが組み込まれているが、それらのユーザインターフェースにフィードバックの要素がなかったとしたら、と考えてみよう。フィードバックをつけたからといって、事故につながるミス操作をすべて防げるわけではないが、おそらくは何％かのミスは未然に防げることだろう。つまり、フィードバックは、必須でそれがなければ成り立たないものというより、コミュニケーション効果をより高めるもの、場合によって大きな事故の確立を下げる可能性のあるもの、といった性格の要素なのである。しかしそれでも、十分に取り組むべき価値のある課題ではないだろうか。
4. フィードバックの目的
フィードバックの目的には、以下のことが挙げられる。フィードバックをデザインし、作り込むことには少なからずコストがかかることだが、ユーザビリティを上げようとすれば適切なレベルで導入すべきである。
4-1. 操作感を高める
特にユーザの操作に対して、機敏にできるだけ適切な反応を返すこと。人は理由もなく待たされることを好まないし、いつまで待たされるかわからない状態であれば、なおさら不快である。場合によっては、機械がハングアップしていると思われてしまう。スクリーンボタンの押し下げなどに対するフィードバックの反応速度は早いに越したことがない。ボタンのフィードバックが1秒を越えたら、むしろシステムを実際以上に鈍重なものに見せてしまうかもしれない。
4-2. ミスの可能性を減らす
操作のミスにはいろいろなことが考えられるが、多くのミスはその場で気付ければ訂正は容易なものであり、その場で誤りを阻止できれば、行く先の大きな障害に至らなくてすむ可能性が高い。ミスを「気付かせる」ためには、内容やシチュエーションにもよるが、書かれた言葉によりも視覚および聴覚に訴えることが有効である。アニメーションなどの動的な表現も効果的である。
4-3. システムの状態や操作の理解の助けになる
操作前の状態と操作後の結果の関係を目に見える形で表示すれば、ユーザは自分の行った操作の結果を体感的に理解することができる。例えばウィンドウを縮小してアイコン化するときに、縮小の状態をスムーズにアニメーションで見せれば元のウィンドウとアイコンの因果関係がはっきりする。もしもこれが何もフィードバック無しで行われたら、小さいアイコンが生まれたことには気づかずに、ただウィンドウが消え失せたように見えてしまうだろう。
このように、フィードバックとは本来的な元の情報や結果の情報の間を埋めるものであったり、本来は目に見えない情報「つながり」や「順序性」を感じさせたりといった、ある意味ではニッチな情報であるとも言える。しかしこういった表現の積み重ねがユーザビリティの向上に少なからず役に立っているのである。
5. フィードバックの事例(1)
ここでは一般的に用いられているフィードバックの例をいくつか紹介しよう。
5-1. ボタン
もっとも端的なフィードバックの例がスクリーン上のボタンである。スクリーンに現れるボタンは、ハードウェアの操作部品をメタファとしたものである。この仮想のボタンは物理的に出っ張った形状（の表現）をしており、マウスなどで押（実際はポイントとクリック）されると、押し込まれた表現になることによってフィードバックする。こういったアニメーションによって、操作感を高めている。主にタッチスクリーンやポインティングディバイスなどによるGUI作法で用いられる。
Webページでもマウスでクリック可能なものはボタンと呼ばれるが、必ずしも物理的な形状を真似ていないものも多い。場合によっては文字だけのものもあり、押されても文字の色が変わるだけというフィードバックという面からは素っ気ない反応しかしない。時にはまったくフィードバックを返さないものも見かけるが、操作感として拍子抜けがする。リンク先のページの読込に時間がかかるようだと、ユーザは押していないと勘違いして、何度も同じボタンを押してしまう、などのミスが発生する可能性がある。
ボタンをフィードバックも含めてきちんとデザインしようとすると、表1のような5つの状態を作りコントロールしなければならない。また、マウス（タッチパネルの場合もほぼ同様）による動作の詳細を図2のチャートに示す。
| 状態 | 説明 |
|---|---|
| (1) 通常／Normal | 何も操作がされていない状態を表す。 |
| (2) 押し下げ／Pushed | ボタンが押された瞬間で手を放す前の状態を表す表現。狭い意味でのフィードバックの表現である。 |
| (3) 選択／Selected | 押された状態を保持するタイプのボタンをシミュレートするもので、ON状態（選択状態）を表す。さらにはn個のステートを持つ場合は、n個の状態を表現することになる。 |
| (4) ロールオーバー／Roll over | マウスがボタンの上に来たときに、ボタンが押下げ可能であることを表現する。この表現も物理的ボタンを超えたものであるが、特に押せることが自明でない文字だけのボタンなどでは、有効なものである。 表現としてはボタンそのものの表現を変える場合もあるが、マウスカーソル自体を矢印から手の形に変えるといった少々変形的なフィードバックが行われる場合もある。これは、マウスなどのポインティングディバイスのときのみ有効なものである。（指によるタッチパネルでは有効でない） |
| (5) ディスエイブル／Disable | ボタンが使えない（押しても何も起きない）状態であることを表す。これは物理的なボタンを超える表現であるが、一般には受け入れられ、認知されている。 |
表1
図2
ボタンは、いわゆるWidget（Window Gadget）の代表選手であるが、その他にもウィンドウ、エントリーフィールド、スライダー、タブ、などのGUI部品もそれぞれ特有のフィードバックを持っている。
5-2. フォーカス
概念的にはボタンにやや近いが、リモコンによるテレビなどの操作や携帯電話、デジタルカメラなど多くの非ポインティングディバイス系の機器に用いられる。多くは十字方向（上下左右）に配置されたハードウェアボタンおよび決定の意味を持つボタンとで操作される。
基本的には、スクリーンに一つだけ存在する注視点（フォーカス）を十字ボタンで移動して、決定したい内容がフォーカスされたら決定ボタンを押す、という操作になる。フォーカスの表現には表2のようなものがあるが、それぞれデザインによって注意すべき点もある。表に述べた以外の留意点として、次の事に注意する。
表2：フォーカスの表現
特に色面による表現などで、二者択一の選択肢から選ぶようなときどちらが選ばれているのかわかりにくくなることがある。三択以上の時は選ばれているもの（フォーカス）が一つに対して選ばれていない物が二つ以上なので間違いは起きにくい。これは実際にユーザテストなどをすれば一定確率で間違いが生じるのですぐに判明するが、本来絶対に間違いが生じてはいけないポイントなので注意が必要である。
画面上にフォーカス移動可能なポイントが多く並べるときは、できるだけグリッド上に配置し上下左右の使用ボタンが紛らわしくならないように配慮しなければならない。携帯電話のiModeでは、ディバイスの都合上フォーカス移動を上下ボタンで行っているが、次のフォーカスが横に並ぶときなどは間違いが起きやすい。
5-3. 待ち状態の表現
基本的にはユーザを待たせない工夫を第一にすべきであるが、システムが内部処理中でどうしてもユーザの操作を受け付けられないときは、そのことをユーザに知らせる必要がある。待ち時間の長さのレベルや待ち時間の質によって、さまざまな表現がありうる。
5-3-1. スクリーンの一部やウィンドウを用いる
数秒以上の待ち時間があるときは、スクリーン全体ないし一部の領域を使って処理中であることを表現する。例としては、ファイルのコピー操作、ソフトウェアのインストール、ネットからのファイルのダウンロードなど。処理時間がある程度計算できるときは、処理の進行状況や待ち時間の目安となる表示をアニメーションなどで表現する。進展度合いを示すものは特に時間でなくても、コピーされるファイルの数などおおよその目安がわかるものであればよい。数値によるものよりアナログ的な量の情報が適している。
システム的に終了時間を決める手がかりがないときは、繰り返しのアニメーションなどを出すことも有効である。何の変化もしないスクリーンが数十秒続いたら、システムのハングアップと区別が付かなくなりユーザは大いに不安である。
5-3-2. お待たせマーク（アイコン）など
画面の定位置に処理中のマークやメッセージを表示する。きちんとユーザが気づける位置に表示することが重要であるが、待っている間にユーザが参照できる情報を隠さないことも大切である。例えば写真データの読込み中のアイコンを中央に表示すると、直下に見えている写真の一番重要な部分を隠してしまう。待っているいる間は何も操作できないとはいえ不親切である。
5-3-3. マウスカーソルによる表現
PCなどでは比較的短い待ち時間の場合に用いられる。マウスポインターはもっもとユーザの注意を引きつけているGUI部品なので、そこに待たせるメッセージを載せるというのは理にかなっている。また待たせている間はマウスが使用できないとすると、不用意にクリックさせてしまうというミスを未然に防いでいると言える。
これらの方式はバランスを考えて用いるべきである。例えば、比較的頻繁に短い時間（1〜2秒）ユーザを待たせなければならないようなシステムが、毎回ダイアログウィンドウを出すのはよくないし、あまりに長い時間マウスカーソルだけで待たせるのもバランスが悪い。
また待ち画面への切り替え自体が遅いと、印象がかえって悪くなることにも注意したい。表示処理に手間取ると、待ち時間にさらに余計な表示処理時間を加えることになる。
6. フィードバックの事例(2)
Apple Computer社は、GUIのデザインでは常に先進的な提案を行っているが、フィードバックという面でも非常に詳細で神経の行き届いた実装を行っている。ここでは同社を中心とした高度なフィードバックの例をみてみよう。
6-1. ウィンドウのオープニング
Macintoshでは、1985年のもっとも初期のバージョンからウィンドウのオープン／クローズにアニメーションを採用している。小さなアイコンが拡大してウィンドウとして開く過程を、波線でできた矩形によるアニメーションで表している。これによってアイコンとウィンドウの関係が視覚的に印象づけられる。またこのアニメーションは一様なスピードではなく、徐々にスピードが増すようなアクセラレーションがかかった動作をする。最新版のバージョンXでは、紙面で表現するのはむずかしいが、ジニー効果と呼ばれるアラジンの魔法のランプの魔神（ジニー）が現れるような表現効果でウィンドウがドック（格納場所）から現れる。また、ドックはマウスがロールオーバーするとアイコンがスムーズに拡大される。
6-2. iPod
iPodは大成功している音楽の保存再生用の機器で、基本的な機能は録音されている音楽（500曲から1万数千曲）を選び出してヘッドフォンから再生をすることである。この成功を支えている何％かは、フィードバックを含めたユニークな操作感によっていると言えるだろう。
ジャンルやアーティストなどで仕分けされているとはいえ、1万におよぶデータにアクセするのは簡単なことではないが、数cmのタッチセンサー付きのホイールによって解決している。タッチセンス自体は何のフィードバックも生じないが、2インチ程度のディスプレイへの非常にレスポンスのよいスクロール表示と、あまり目立たないが内蔵スピーカから擬似的なクリック音を出すことによって反応を機敏なものに感じさせている。また、最近の同社のローラー付きのマウスもスピーカが仕込まれており、ローラーの操作に合わせた操作音を出している。これによって本当に物理パーツが音を出している錯覚に陥る。
7. フィードバックのデザイン
ここでは、フィードバックデザインするという面から、いくつかの点をみていくことにする。フィードバックの実質的な機能とは、システムがどういう状態にあるかということをユーザに知らせることである。それをどういうタイミングで、どのような内容と表現でユーザに提示するのかが、フィードバックデザインの内容となる。
7-1. タイミング
フィードバックのデザインでは、タイミングという要素が非常に大きい。例えば、ボタンの押されるフィードバックに時間がかかっていたら、本来の操作の結果が出てしまう。これではユーザは余計混乱してしまうし、フィードバックは出さない方がましである。
フィードバックは、ユーザの操作の前後に発生すると考えられるが、時間的な視点からフィードバックの項目をまとめてみると表3のようになる。また図3にパスワード入力のシークエンスの流れにそって具体的なフィードバックの機能例を示す。
| 状態 | 情報 | 内容 |
|---|---|---|
| 操作前 | 説明情報 | マウスのロールオーバーによって機能の説明、動作の説明を表示するなど。 |
| 選択可能情報 | 操作対象オブジェクトの選択によって、可能な操作選択肢を提示する。コンテクストメニューなど。 | |
| 選択不可情報 | 現在は操作ができないことを表示する。ボタンのディスエーブル状態、選択リストのグレーアウト状態など。 | |
| 待ち情報 | システムは処理中であり、すべての操作が受け付けられないこと。 処理にどれくらいの時間かかるのか。待ち時間。 |
|
| 操作後 | 操作反応 | ボタンが押された、キーが押されたなどのイベントに反応を返す。 |
| 適正操作判定 | 実際の処理を進める前に、ユーザの操作が適正なものであるかを判定し、適正でなかったらその時点で訂正を促す。 | |
| 実行確認 | ファイル削除など、後戻りできない操作に関する実行の確認をとる。 | |
| 操作結果情報 | 操作が完了した／操作が完了できなかった。 得られた結果の確認。 |
|
| 操作過程表現 | ウィンドウからアイコンへ、アイコンからウィンドウへのアニメーション。 コピー元からコピー先へのアニメーションなど |
表3
図3
7-2. メタファ
フィードバックを考える上でメタファとの関係をよく考慮する必要がある。メタファとは「喩え」のことで、PCの操作をデスクワークに喩えるデスクトップメタファは特に有名である。GUIでの操作を考えるにあたって、物理的な機械部品ではないのでディスプレイには何を表現しても構わない。だからこそ比喩の表現が重要になるといえる。ウィンドウを紙や巻物（スクロール）に見立てたり、「ボタン」を押して機能を発動させることはもはや非常にあたりまえになっているが、本来はそうである必然性は何もないのである。
ここでは、そのような必然性のないことをやめようと言っているのではなく、積極的に活用しようということを言っているのである。ユーザインターフェースの表現の上では、必然性ということは必ずし重要ではない。それが操作をうまく説明できて、ユーザがその気になれる操作における舞台設定であれば、用いる理由は十分でなのである。フィードバックもメタファと適切にフィットする形でデザインしなければならない。
これもApple社の例だが、HyperCardというシステムでは、紙（カード）の束（スタック）というメタファを用いていたが、カードの移動に際しては、さまざまにカードがめくれる様をフィードバックとして指定することができる。こういった効果がまったくなければ、カードもスタックも単なる概念的な名前にすぎなくなってしまうだろう。
7-3. アニメーション
アニメーションは連続的な絵によって動きを表現するテクニックであるが、特に視覚的なフィードバックを表現するのに適しており、PCではかなり使われるようになってきた。例えばドロップダウンするメニューは、一気にメニューが描画されるのではなく、じょじょに現れるような表示工夫がされている。また伸び縮みするエリアも「伸びる」ないし「縮む」アニメーションが用いられる。
アニメーションの表現ではある程度の描画速度が要求されるので機器によっては処理が重くなる。しかし、CPUパワーに余裕ができれば取り入れることによってフィードバックの表現の幅は大きく向上する。
アニメーションに関しては、ディズニーによる「生命を吹き込む魔法／Disney Animation The Illusion of Life」(*1)によってさまざまな原理が解き明かされているが（表4）、ここでは一例を紹介する。
| 内容 |
|---|
| (1) スクオッシュ（潰し）とストレッチ（伸ばし） |
| (2) アンチシペーション（予備動作） |
| (3) ステージング（演出） |
| (4) ストレート・アヘッド・アクション（逐次描き）とポーズ・トゥ・ポーズ（原画による設計） |
| (5) フォロースルーとオーバーラッピング・アクション（あと追いの工夫） |
| (6) スロー・インとスロー・アウト（両端づめ） |
| (7) アーク（運動曲線） |
| (8) 副次アクション |
| (9) タイミング |
| (10) 誇張 |
| (11) 実質感のある絵 |
| (12) アピール（訴える力） |
表4：アニメーションの原則
7-3-1. スロー・インとスロー・アウト（両端づめ）
アニメーションは物理的な物の動きがベースになっている。実際の世界ではあらゆる物の動きは、一瞬でトップスピードに達するわけでも、一瞬でスピードがゼロになって止まるわけでもない。ゆっくり動き始めて加速し、次に徐々に減速して止まることが自然に見える秘訣である。
8. 最後に
8-1. フィードバックのコスト
フィードバックを導入するにあたって、コストパフォーマンスを正確に計算することは難しいだろうと思う。コストはなんとか積み上げて計算できるかもしれないが、効果をどう計るかは意見が分かれるだろう。
認知心理学者のD.A.ノーマンは、楽しいことや美しいことは使いやすさに大きな影響を与えると述べている(*2)。少なくともフィードバックが使う楽しさを演出してくれたりその気にさせてくれることは、ゲームマシンを例に出すまでもなく自明である。（ゲームマシンはフィードバックの固まりである。）
8-2. 組込技術との関連
ユーザインターフェースやフィードバックは最終的にユーザに触れる部分であるが、この実現にはハードウェアで処理するのが適切な場合やベースとなるソフトウェアレベルでのサポートが必要な場合もある。したがってこれらが融合した形で設計を進めることが本来的な在り方ではないだろうか。
多くの組込機器では、まだまだコストとのバランスで思うような表現が存分にできるとはいえないと思う。しかしPCにもキャラクタディスプレイやモノクロディスプレイの時代があったが、例えばスプレッドシートというすばらしいメタファはそのころの貧弱な表現の中で発明されたものである。つまりは工夫次第で表現は後からついていてくるものである。
アランケイは、ユーザインターフェースについて次のような表現をしている。「ユーザインターフェースとは、イルージョンの持続である」つまりユーザインタフェースは、操作のために作り出された幻影だというのである。ユーザは何らかの目的があってシステムの操作を行うわけであるが、仕事の結果が得られればどのような表現で操作が組み立てられていても構わない。また使う人は、一般にシステムの内部の動作や構造を理解しているわけでも、できるわけでもない。したがって操作方法をどう伝えようとしても、どこからかは説明のための「お話」にならざるを得ない。であれば、良質なお話でユーザをだまして上げなければならないといえる。フィードバックあるいはユーザインターフェースのデザインとはそのようなものである。
（第3回・おわり）
- *1 生命を吹き込む魔法／Disney Animation The Illusion of Life, フランク・トーマス、オーリー・ジョンストン著, スタジオジブリ翻訳／徳間書店
- *2 エモーショナル・デザイン／Emotional Design, ドナルド・A・ノーマン著, 岡本他訳（新潮社）
- *3 別冊サイエンス／Scientific American「コンピューター・ソフトウェア」
