ユーザーインターフェイスは、デスクトップアプリケーション、Webまたはモバイルアプリケーションなど、アプリケーションの使用時に重要な役割を果たし ます。ユーザーインターフェイス設計におけるソートリーダーであるAlan Cooper氏(リンク)が執筆した本『About Face』(リンク)は、アプリケーション用UIの作成に関する興味深い有用なガイダンスを提供しています。この本の最も注目すべきアイデアをいくつか紹介します。
中級ユーザー向けの設計
Cooper氏は、あらゆるソフトウェア製品の大半のユーザーを中級ユーザーに分類できると論じています。中級ユーザーとは、基本的に製品の使用方法を 知っていて、通常いつも同じ操作を実行するためにその製品を使用しているユーザーのことをいいます。Cooper氏は、製品を使用するユーザーの約80% が中級ユーザーであり、残りの20%は上級ユーザーと初心者ユーザーに均等に分布していると推定しています。
しかしCooper氏は、製品ユーザーの大半が中級ユーザーであるにもかかわらず、多くの場合に彼らのニーズがUI設計において無視されている、と 指摘しているのは興味深いところです。経営サイドの人間はたいてい接触する相手が初心者ユーザーであるため、初心者ユーザーのニーズを支持する傾向にあ り、一方、開発者は当然ですが製品のエキスパートユーザーであるため、エンドユーザーもエキスパートであると考える傾向にある、とCooper氏は述べて います。Cooper氏は、中級ユーザーがユーザーの大部分であるにもかかわらず、混乱して迷う傾向にあると感じています。
彼は、この3タイプのユーザーのニーズは製品への精通度の違いにより異なると説明しています。エキスパートは操作を実行する素早い方法とアプリケー ションをカスタマイズできる機能を望みますが、初心者はツールの基礎の概観に最も関心があります。中級ユーザーは、ツールを使用して繰り返し同じ操作を実 行する傾向にあり、作業プロセスをインターフェイスによって邪魔されたくないと思っています。
初心者から中級ユーザーになる助けとなるツールの使用
初心者は製品ユーザーのたった10%であるにもかかわらず、製品の全ユーザーが初心者ユーザーの状態を経験しなくてはなりません。したがって、新しいユーザーがアプリケーションの基本を学ぶことができるインターフェイスを設計することに特別な注意を払う必要があります
初心者を中級ユーザーへ移行させることがUI設計の目標ですが、Cooper氏は、ユーザーが初期段階から次の段階に移行したら、その達成を助けたUIは あまり役に立たないものになってしまうということを、いち早く指摘しています。実際、それがユーザーのワークフローを妨げることになるでしょう。
初心者を教育しようとする製品は多数ありますが、同時にそれらは、製品の中級ユーザーには非常に煩わしいものでもあります。たとえば、VS2008 では、初心者ユーザーがユニットテストの様々なコンポーネントを理解できるように、私たちは生成したユニットテストコードにコメントを挿入しました。それ らのコメントは十分に目的を果たす一方で、ユーザーがコンポーネントを理解した後はユーザーの妨げになります。そのため、VS2010ではそれらを削除し ました。
ユーザーが中級ユーザーになるのを助けるには、製品の使用方法についてユーザーに概要情報を提供するようなものをUIに追加するということを、 Cooper氏は提案しています。また、そうした情報を、ユーザーがオフにしたいときはUIから削除できるようにすべきであると示唆しています。これは典 型的に、製品の機能の概要を示す「Getting Started（はじめに）」ビデオの形をとります。
Cooper氏は、オンラインヘルプとツールヒントは実際、初心者よりも中級ユーザーに最もよく役に立つと考えています。それは彼らのニーズが若干 異なっているからです。中級ユーザーは、参照する上で役に立つドキュメントを検索し、一方、初心者は、そうしたドキュメントの概要に最も関心がある傾向に ある、とCooper氏は主張しています。
より少ないことは、より豊かなこと（Less is More）
私は次の引用句を気に入っています: 「どんなにクールなインターフェイスでも、その（インターフェイス）の機能は少ないほうがいい（No matter how cool your interface is, less of it would be better）」。
時々UI設計において、私たちはユーザーが特定の目標を達成するためのツールとして製品を使用しているということを忘れていると思います。時々私た ちは、クールなナビゲーションツールに心を奪われて、それをUIに入れ過ぎてしまいます。木に釘をしっかりと打ち込むことができないのなら、暗闇で光る紫 色のハンマーはやはり使いものにはなりません。
Cooper氏は、すべてのオプションが目的のあるものでダイレクトであるべきというミニマルな(必要最小限の)設計を提唱しています。彼は、イン ターフェイスにおいては、よりダイレクトなオプションが少ない方を支持しています。きちんと編成されたUI設計では、UIは自然とユーザーのメンタルモデ ルに従うためユーザーにはほとんど見えない（トランスペアレントな）ものになる、と彼は述べています。
実行される可能性が高いもののために設計し、実行される可能性があるものに備える
Cooper氏は、製品を設計してアプリケーションのメインラインフローのために最適化を行うときはユーザーのメンタルモデルに従う、ということを提唱し ています。これはしばしば、プログラマが操作を快適に感じられなくなるほど多くのオプションがある場合は、ダイアログから排除すべきであるということを意 味しますが、より複雑で高度なことを行う方法があってはならないという意味ではなく、単にアクセスしにくくすべきだということです。
アプリケーションワークフローのある段階でユーザーが実行できるアクティビティの種類について概説するとしたら、Cooper氏は、最も実行される 可能性が高い1つか2つのアイテムが必ずあると感じています。したがって、インターフェイスは、ユーザーがこれらのアクティビティを見つけられるように最 適化されるべきであり、単にすべてのオプションを常に一覧するのではなく該当のワークフローにユーザーを導くべきです。主流でないアクティビティにユー ザーがアクセスする方法は存在すべきですが、その使用のためにUIを最適化するべきではありません。
私は、Officeリボンは実行される可能性が高いもののために最適化するが実行される可能性があるものにも考慮するという見事な仕事をしたと思い ます。リボンでは、ユーザーが最も使用する可能性があるアイテムは1クリックで使用でき、それよりも使用頻度が低いと考えられるアイテムは2クリックで使 用でき、あまり使用されないと考えられるアイテムは3クリック以上で使用できるようになっています。明らかに、実行される可能性が高いもののためにUIが 最適化されています。
エラーダイアログや確認ダイアログの排除
ユーザーのメンタルモデルに従い、中級ユーザーのフローを邪魔になりかねない障害を削除するというテーマに沿って、Cooper氏は、製品からすべてのエ ラーダイアログや確認ダイアログを排除することを支持しています。彼は、アプリケーションは統計的に正しい可能性が高いアクションを行うが、そのアクショ ンを元に戻すオプションをユーザーに提供すべきであると感じています。
ユーザーは、自身が利用可能なオプションを見て、アクションを実行した後、そのアクションが正常に行われたという確認を得ることを好む、と Cooper氏は述べています。アクションが行われたという確認がなければ、ユーザーは実際にそのアクションが行われたかどうか心配に思います。 Cooper氏は、アクションの結果を伝えるために、ポップアップ通知を提供するのではなく、インライン状態でのアラートや肯定的な音によるフィードバッ クを支持しています。
私は、すべての状況において確認ダイアログを排除することが理想的であるということに同意しますが、それらを完全に排除することはあまりに極端すぎ て私の好みには合いません。Cooper氏が提案することを実施するには、開発者は、ユーザーが実行する各アクションをリバーシブルにする必要がありま す。それは、コストがかかりますし、私の考えでは、必要のないことです。私は、確認ダイアログを排除してアクションをリバーシブルにすることに最善の努力 はしますが、ディスクフォーマットやファイル削除などの極端なアクションの場合には、確認ダイアログをポップアップ表示することが良いと思いますし、実際 にユーザーもそれを望んでいるかもしれません。
一方で、私は、エラーダイアログは製品から完全に排除すべきであるというCooper氏の意見に賛成です。エラーダイアログはプログラマには理解できます が、エンドユーザーには理解できないことが多いと思います。ダイアログが表示されるとワークフローが妨げられるため、多くのユーザーが非常にフラストレー ションを感じているのを私は目にしてきました。Cooper氏は、エラーダイアログはコードに何か不具合があることを伝えるために使われているのに、ユー ザはそれを「私が何か間違ったことをした」と解釈する傾向にあると指摘しています。ユーザーは繰り返し間違っていると言われると、その製品を嫌いになり始 めます。私は最近、MacのUIを使用してみて、それらのいくつかが絶えず例外を飲み込んでいるようだと分かって驚きました。もちろん、問題は発生してい ます。単にユーザーの目には触れないようになっているのです。
投稿者について
Naysawn Naderi氏は、MicrosoftのVisual Studio Team Testのプログラムマネージャです。Naderi氏は現在、マニュアルテスターがより良くテストを行いソフトウェアチームのメンバーとより効率的に協働 できるよう、適切なユーザーエクスペリエンスを構築することに重点的に取り組んでいます。彼はマギル大学の電気工学の学位を有しています。また、 Testmundo(リンク)というブログを公開しています。
原文はこちらです：http://www.infoq.com/articles/UI-Principles-Naysawn-Naderi