ユーザインタフェース設計

ユーザインタフェース設計に有用な基礎理論の多くは、GUIが商業的に一般化する過程と並走するかたちで1980年代に確立されています。本節では、 HCI 研究をしていると必ずといってよいほど名前を聞く 3 名の研究者、 Stuart Card、 Ben Shneiderman、 Don Norman の成果を中心に紹介します。いずれも、ユーザとシステムの間のインタラクションをモデル化した成果です。

認知心理学に関する内容をさらに網羅的に知りたい場合、和書なら「インタフェースデザインの教科書」をおすすめします。

人間情報処理モデル（Model Human Processor; HMP）

Card らは 1983 年の書籍「The Psychology of Human-Computer Interaction」の中で人間情報処理モデルを提唱しました。これは、システムと対峙するユーザの中で起きることを3種類のプロセッサによる一連の情報処理過程としてモデル化するもので、それぞれ、おおむね次のとおりの処理時間がかかることが報告されています。

1. 知覚プロセッサ（100 ms）
2. 認知プロセッサ（70 ms）
3. 運動プロセッサ（70 ms）

人は総じて数百ms程度で応答できると考えれば、システム側の処理がそれ以上かかる場合には、プログレスバーなどを表示して間を持たせたほうがよいことになります。

また、プロセッサは主に短期記憶を参照して処理を行いますが、人が一時的に覚えられる意味のまとまり（チャンク）は 7 ± 2 個に限定されることも説明されています。この数字はマジックナンバーとも呼ばれ、インタフェース設計で頻繁に使われます。実例としては、クレジットカードの番号入力欄が4文字ずつ4個に分かれていたり、メニューの項目数や推薦システムの提示する案の数がこの範囲に収められていたりしますね。

Cardらは同じ書籍で、 MHP に続いて、文章編集タスクに特化したGOMS モデルを提唱しています。実用上はこちらのほうが有名なモデルと言えると思います。これは、モデルを構成する4要素、すなわち遂行したいタスク（Goal）、タスク遂行に向けた動作の最小単位（マウスカーソルの移動、キャレットの移動、打鍵など; Operator）、タスク遂行までの一連の動作（Goal を分割したサブゴールと Operator の組からなる配列; Method）、 Methodが複数ある際の選択規則（Selection rule）の頭文字を取って命名されています。

このモデルの利用者は、自ら設定したGoal、Operator、Selection ruleから最短Methodを求め、各Operatorの所要時間を足し合わせることでタスク全体の予測時間を得られます。 GOMS は手軽なうえ実際には文章編集に限定されない汎用的なモデルなため、派生モデル（KLM、NGOMSL、CPM-GOMSなど）も含め、今日にいたるまでインタフェース研究の評価実験にしばしば活用されています。ただし、これらのモデルはユーザがミスする可能性を考慮できないため、習熟ユーザの定型タスクに限り適用できるものです。

フィッツの法則（Fitts' law）

Card は、フィッツの法則（Fitts' law）が、マウス操作の効率を測るモデルとして適していることを明らかにしました。

この法則は、対象の領域に移動するためのおおよその所要時間（Movement Time; T）が、領域の中心までの距離（Distance; A）と対象物の大きさ（Width; W）の関数で次のとおりシンプルに表せるというものです。

つまり、マウスでクリックする対象が遠ければ遠いほど時間がかかるが、対象領域が大きければ大きいほど時間が節約できるということです。

この法則によれば、ディスプレイの四隅に配置されたボタン（Windowsの「スタート」ボタンなど）やパイメニュー（マウスの位置に放射状に表れるメニュー）は、実際に見えているボタンや選択項目よりも対象領域をずっと広く取れます。例えば「スタート」なら左下にどれだけ行き過ぎても選択できるため、左下方向に無限の広さを持つと考えられます。そこで、カーソルの現在位置によらずほぼ定数時間で選択でき、素早く選択しやすいと言えます。

なお、このモデルは階層型メニューのように経路が制限される場合には適用できません。階層型メニューでは、深い階層に辿り着くためにポインタを何度か真っ直ぐ動かす（ステアリングする）必要があります。

このように軌跡が制限されていても適用できるモデルが 1997 年に提案されています。経路がトンネルを繋いだ形状に制限される場合、所要時間はトンネルの長さ（A）と幅（W）で次のように表せます。

さらに、これらのモデルにはポインタの占める面積が対象領域よりも十分小さいという暗黙の前提があります。タッチ入力ではポインタとなる指の大きさが無視できないため、タッチの場合に正確な予測を行うモデルが 2013 年に提案されています。

このようなモデルを活用することで、ユーザテストを何度も繰り返さなくても、作業効率の高いユーザインタフェース設計を行うことができます。

ダイレクトマニピュレーション（Direct Manipulation; DM）

Shneiderman は1983 年の論文でダイレクトマニピュレーションインタフェースを提唱しています。ユーザインタフェースのなかでも、とくに以下の条件を満たすものが DM インタフェースです。

1. システムの状態とその変化が継続的に見える
2. ユーザが入力をすばやく、徐々に、可逆的に実行できて、しかも実行結果がすぐ返ってくる
3. 複雑な構文のコマンド入力でなく、システムの状態を表すオブジェクトを個々に操作できる

これらの条件を満たせば、ユーザはコンピュータを意識せず、システムの状態を直接操作しているように感じられる、というヒューリスティックな設計指針です。

DM が提唱されたのは、パソコンのデスクトップで一般的なウィンドウ、アイコン、メニュー、ポインタからなる WIMP メタファが確立した時期と重なります。そのため、稀に DM＝WIMP と解釈されることがありますがこれは誤りで、 DM の実装例が WIMP という関係です。

DM の WIMP 以外の実装例として、スマートフォンのタッチインタフェースが挙げられます。これは、複数のウィンドウをディスプレイ上に置くことを諦め、ポインタをなくし、指で直接操作できるようにしたものです。また、近年 Virtual Reality（VR） 用の高性能なヘッドマウントディスプレイが安価に市販されています。これは、3Dで表現されたオブジェクトを直接操作できる新たな DM プラットフォームと言えます。

実行の溝と評価の溝（Gulf of Execution and Evaluation）

Norman は 1986 年に書籍「User Centered System Design」を編纂し、ユーザとシステムの間のインタラクションをユーザ視点（User-Centered）で 7 段階に分けてモデル化しています。

1. ユーザが目標を決定する
2. ユーザが望ましいシステムの状態を意図する
3. ユーザが意図どおりの状態を実現するための入力を選択する
4. システムがコマンドを実行して応答を返す
5. ユーザがその状態を知覚する
6. ユーザが知覚した内容を解釈する
7. ユーザが、はじめに意図した状態と実際の状態を比較評価する

インタフェース設計においては、この各段階の間に存在するトレードオフを把握し、想定しているユーザに最適化することが重要となります。

例えば、コマンドを文字で自由入力する場合と、メニューから選択する場合を考えてみます。すでに利用可能なコマンドを覚えきっている熟練者にとっては、前者のほうが（1）から（4）まで一気にできて望ましいでしょう。メニューだと選択して実行する手間が多く感じられるかもしれません。ところが、初心者にとっては、そもそもどんなコマンドがあるか分からないので、自由入力だと（3）の選択プロセスが難しく、メニュー表示のほうが適しています。ただ、ユーザが徐々にシステムに習熟していくことを考えると、どちらが正解とも言えません。この例に関しては、近年、コマンドの自由な入力、検索、選択ができるコマンドパレットと呼ばれるインタフェースが一般化しつつあります。（The History of Command Palettes: How Typing Commands Became The Norm Again）

ここで、システムへの入力に至る（1）から（4）までのプロセスと、システムの出力を次の入力に繋げるための（5）から（7）までのプロセスは、実際には細かく分けて考えづらいこともあります。 Norman は、それぞれをユーザ・システム間の隔たりと考え、前者を実行の淵（Gulf of Execution）、後者を評価の淵（Gulf of Evaluation）と呼んでいます。この淵をいかに狭くするか、つまりユーザにとっての認知的な負荷をいかに軽くするかが、インタフェース設計の腕の見せ所になります。

なお、この「淵」というアナロジーは、書籍のダイレクトマニピュレーションに関する章（Chapter 5. Direct Manipulation Interfaces）を改稿する過程で出てきたものだそうです。「ダイレクト（直接）」という言葉は、すなわちユーザが淵を意識しないで済む状態です。（The Glossary of Human Computer Interaction 19.0.2）

ヒューリスティック評価

ユーザビリティ評価の最も簡単な方法は、エキスパートが作成した経験則的なチェックリストの各項目を確認することです。 Nielsen の書籍では Usability Heuristics という章がこれに当たり、チェックリストは Nielsen と Norman が立ち上げた会社（Nielsen Norman Group）のWebサイト上に転記され継続的に更新されています。

開発しているアプリケーションが特定のプラットフォームを対象としている場合、プラットフォーム側が提供するツールキットに付随するガイドラインがこうしたチェックリストを含んでいることもあります。有名な例として Apple Human Interface Guidelines が挙げられますが、 Microsoft や Google なども同様のガイドラインを提供しています。

なお、デザインのガイドラインをまとめることは、 OS を作っているプラットフォーマーでなくとも、デザイナー間の意思統一をはかれたり、複数のサービスを横断して一貫したユーザ体験を提供するために便利だったりと、いろいろなメリットがあります。本稿では詳しく取り上げませんが、こうしたガイドラインはデザインシステム（Design System）と呼ばれることがあり、とくに大規模な制作現場で開発されることが増えています。

定性的ユーザビリティテスト

実際のターゲットユーザとなる人々にインタフェースを使ってもらい、その様子を観察できれば、ユーザビリティ上の問題を発見できます。こうした定性的テストは、開発の初期段階でまだインタフェースの要件が固まっていない場合にとくに有効です。頭に浮かんだことを随時声に出してもらう思考発話法（Thinking Aloud）を使えば、ユーザがインタフェースを試す間に何を考えているかが分かるため、さらに効果的です。なお、発話により操作効率が落ちる場合は、事後のインタビューで代替したほうがよいこともあります。

もっとも重要なのは、人数は少なくてよいので、開発が進捗するごとに反復的にユーザビリティテストを実施することです。Nielsenは、テストの参加人数と発見できる問題数の関係を調査し、5人いれば問題の9割程度が発見できることを報告しています。なお、ターゲットユーザに頼むことが難しい場合、設計者自身が試すことももちろん有用です。ユーザの身になってステップバイステップで使い方を確認していき、問題点を見つけ出していくプロセスは認知的ウォークスルー（Cognitive Walkthrough）と呼ばれています。

定量的ユーザビリティテスト

ユーザビリティを他の案と比較したり、開発過程でどれくらい向上しているか確認したりしたい場合は、定量的な調査のほうが適しています。例えば、同じタスクを行ってもらい、タスクの達成率やエラー数などを計測すれば、統計的にユーザビリティの優劣を判断できます。すでにユーザが多数いるシステムで比較したいインタフェースが A 案 B 案のように具体的なら、ユーザをランダムにグループ分けすれば両案の計測結果を容易に比較できます。これが A/B テストと呼ばれるものです。

一般的な定量調査の指標としては、 Brooke が提案した System Usability Scale (SUS) が挙げられます。これは、 10 の質問に 5 段階のスケール（全くそう思わない～強くそう思う）で回答してもらうものです。同様の指標は他にもあり、 Brooke の後年の論文で比較検討されていますが、ここでは深く触れません。

より簡単に多くの回答を集めたい場合は、 1 つの質問で済む Net Promoter Score (NPS) が有効です。これは「このシステムをどれだけ友人に勧めますか？」という質問に 0-10 の 11 段階のスケールで回答してもらうものです。Webサイトやスマートフォンのアプリケーションで、一度は目にしたことがあるのではないでしょうか。

ユーザビリティテストの限界

本節では、インタフェースの使い勝手を評価するための指標としてユーザビリティを挙げ、 3 種類の評価手法を紹介してきました。こうした評価と改善を繰り返すプロトタイピングにより、使い勝手を向上できるでしょう。

ただし、ユーザビリティも万能な考え方ではなく、一つの指標に過ぎないことに注意する必要があります。まず、紹介した評価手法は主に 1 人のユーザを対象とする手法が多く、複数名が共同作業する Computer-Supported Cooperative Work (CSCW) のアプリケーションにはうまく対応できません。また、ユーザビリティは語義からしてインタフェースが使いやすい（想定されているタスクを遂行しやすい）ことしか保証しません。ユーザは使いやすさ以外にも様々な観点で価値判断を行っています。例えば、ユーザに開発過程に参加してもらう Participatory Design (PD) は、ユーザの満足度を向上させ、システムへの愛着を湧かせる非常に有効な手段となります。さらに、システムが革新的な機能を実現するものである場合、開発の初期段階でユーザビリティを測ってしまうとその可能性の芽を摘んでしまう可能性があります。

このように、ユーザにとっての価値を高めるために考えることは多く、デザイン手法も様々です。もっと具体的な手法を知りたい場合は、 100 手法を紹介しているカタログ的書籍がありますので、ぜひ読んでみてください。