Webアプリケーションのユーザーインターフェイス[1]

ユーザーにとっては
“ユーザーインターフェイス”こそが製品そのもの

ソシオメディア　上野 学
2005/6/2

■インタラクションデザイン

　人とコンピュータの間のコミュニケーションを仲介するのがユーザーインターフェイスの役割であると述べましたが、では、人とコンピュータの間のコミュニケーションとは何でしょうか。複雑な情報処理が可能になった現代のコンピュータでは、ユーザーはコンピュータと対話式に操作を進めるのが普通です。

　つまりある利用目的を達成するためには、まずユーザーが何らかの入力操作を行い、それを受け取ったシステムが内部で何らかの計算を行って処理結果を出力する、というやりとりを繰り返します。そのため、使いやすく利用効率の高いシステムを設計するには、表面的なユーザーインターフェイスを適切にデザインするだけでなく、対話がスムーズに進むように、人とコンピュータのインタラクション（相互作用）全体を適切にデザインしなければならないのです。これを、インタラクションデザインといいます。

図4　人とコンピュータの相互作用のデザイン＝インタラクションデザイン

　インタラクションデザインは、ユーザーが各コントロールに操作を加えた際のフィードバックや、作業を進めていくうえでの画面遷移などを決定します。つまりそのシステムが扱うユースケースや、実現しようとしているビジネスモデルといった、基本的な設計と関連しています。しかし一般的にインタラクションデザインを専門に行うデザイナーは少なく、プログラマーやグラフィックデザイナーが手探りで行っているのが現状でしょう。

　特にプログラマーがシステムの振る舞いを考える場合、データ処理の効率や、手間の掛からない実装などを優先してしまうため、ユーザーにとっての利用効率や、ユーザーにとって手間の掛からない操作手順などが犠牲になってしまうことがよくあります。ユーザーは目的に釣り合った努力しかしないため、いくら機能要件を満たしたシステムが完成しても、それを利用するのが思った以上に面倒だと、結局ユーザーは使うのをやめてしまうか、あるいは大きなストレスを感じ続けることになってしまいます。

■インタラクションデザインの論理性

　 良いインタラクションデザインの基本は、まず、ユーザーがある目的をできるだけ少ない労力と時間で達成できるようにすることです。同じ結果が得られるのなら、コントロールの組み合わせによって、より少ない操作数で作業が完了するようにします。例えば、次の2つの画面を見てください。

図5　どちらが良いインタラクションデザインか

　これらは両方とも、「特定のリストの中から商品を選び、発注、または見積もり計算する」というタスクを行うための画面です。この場合、どちらがより良いインタラクションデザインといえるでしょうか。答えはBです。なぜなら、Aの画面では、ユーザーはまず「発注する」か「見積もり計算する」のどちらかを選び、次に商品を選び、そして「OKボタン」を押すという、3段階の操作をしなければなりません。それに対してBの画面では、ユーザーはまず商品を選び、そして「見積もり計算する」か「発注する」のボタンを押すという2段階の操作で済むからです。

　AとBの違いを、もう少し細かく見てみましょう。Aの画面における3段階の操作は、「ラジオボタンによる選択」「チェックボックスによる選択」「OKボタンを押す」という構成になっています。最後の「OKボタン」には選択オプションがないため、単にタスクを完了する「合図」の意味しか持っていません。

　一方、Bの画面では、タスクの最後に2つのボタンによる選択オプションを提示することで、タスク完了の合図を省略することができています。つまり、1つの操作が持つ情報量（ビット数）に違いがあるのです。画面Aの「OKボタン」を押す操作は0ビットです。この場合OKボタンを押さないという選択肢はないので、無意味な操作になっているのです。画面Bのボタンは2つオプションを持つ選択肢なので、1ビットの情報となります。このような考え方で無意味な操作を減らすと、インタラクションを効率的にすることができます。

　AとBのもう1つの大きな違いは、インタラクションのイディオムにあります。Aの画面では、最初に、発注するか見積もり計算をするかという「コマンドの選択」を行い、その後で、商品という「対象の選択」を行っています。文法にすれば、「動詞→目的語」という順序になります。一方Bの画面では、最初に「対象の選択」を行い、次に「コマンドの選択」を行う、つまり「目的語→動詞」の順序になっています。手続き型のインタラクションを取るコマンドラインインターフェイスにおいては、Aの「動詞→目的語」のイディオムで操作するのが一般的ですが、対話型のGUI においては、Bの「目的語→動詞」のイディオムの方が適しています。

　なぜなら、Aの「動詞→目的語」のイディオムでは、最初に動詞を指定した段階でシステムは目的語が入力されるのを待つような状況になります。そのときシステムはユーザーがリストの中からいくつの商品を選ぶか予測できないため、ユーザーは最終的にタスクを完了するための「合図（OKボタンを押す）」を与えなければなりません。

　その点、Bの「目的語→動詞」のイディオムでは、商品を選んでいるときにユーザーはまだ最終的なコマンドを決心している必要はなく、システムに与える命令の種類に依存した心理的な保留状態に入らなくて済むからです。このようなイディオムの違いをEコマースサイトに例えて考えると、違いは明らかです。オンラインでショッピングをする際に、通常は商品をまず選んでショッピングカートに入れ、それから購入手続きに移動します。しかしこれが、最初に購入モードに入ってから商品を選ばなければならないとしたらどうでしょうか。おそらく心理的なストレスが大きく、キャンセルの手間も掛かり、あまりスムーズな利用フローにはならないでしょう。

　実際には、必ずしも操作数を減らせばそれだけ使いやすくなるわけではありませんし、いつでも「目的語→動詞」のイディオムが適しているわけではありません。例えばコマンド（動詞）の種類に応じて対象物（目的語）のセットがそっくり変化してしまうような場合です。しかしそもそもGUIは、操作対象を現実世界のものになぞらえて目に見えるように表現したものなので、まずオブジェクト単位でユーザーの操作を待ち受けるような利用フローを設計する方がよいでしょう。動詞の選択を先に促すような利用フローは、ユーザーが「合図」をするためのダイアログが多くなってしまう傾向があり、心理的な保留状態を伴うモードを次々に作らなければならなくなります。

　このように、論理的な考え方で個々の画面やシステム全体のインタラクションを考えることは、ユーザーに対する製品の受容性を最大化するために非常に大切なことだと思います。システム構築の上流工程において、ユースケースを使ってオブジェクト指向にモデリングを行うのであれば、実際にそれがGUIを伴って実装された際の振る舞いも考慮してクラスなどを定義していく必要があるでしょう。GUI の構成要素は、それぞれがオブジェクト的に振る舞わなければ不自然な操作性になってしまいますし、システムアーキテクチャの制約によって理想的な画面遷移が実現できなければ本末転倒だからです。

■Webアプリケーションのユーザーインターフェイス

　リッチクライアントが充実してきたことにより、その開発者も、そしてそれを利用するユーザーも、Webアプリケーションのユーザーインターフェイス表現に注目しています。これまでのWebは、互いにリンクされたドキュメントが紙芝居風に表示されるものという感覚で受け入れられてきましたが、デスクトップアプリケーションに近い豊富な視覚表現が可能なクライアント技術と、XMLなどの標準化技術の利点を生かすことで、Webはネットワークを介したインテリジェントな情報アプリケーションとして新しい利用者体験を提供し始めています。

　しかし、新しい技術によって従来の枠組みを超えたダイナミックな世界観の提供が可能になったとしても、それを利用するユーザーの世界観はすぐには変化しません。むしろ開発者やデザイナーは、人が道具のユーザーインターフェイスに接する際の認知的な特性に合わせて、新しい技術の実装方法を考えなければならないのです。ユーザーにとっては常に、ユーザーインターフェイスこそが製品そのものだからです。

　この連載では、従来のデスクトップアプリケーションで培われたGUIの原則や、ハイパーメディアにおけるインタラクションの在り方などを通して、Webアプリケーションのデザインを考えていきたいと思います。

2/2

INDEX
Webアプリケーションのユーザーインターフェイス（1）
	Page1 はじめに／ユーザーインターフェイスとは／メンタルモデル／アフォーダンス
	Page2 インタラクションデザイン／インタラクションデザインの論理性／Webアプリケーションのユーザーインターフェイス

関連記事

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）