ユーザー・エクスペリエンス

使い勝手を氷山に例えると

今回の記事は、アプリケーション設計への見識を高めようとするデベロッパーを対象とする、Dick Berry によるコラムの第 1 回です。ここでは、ルック・アンド・フィールが氷山の一角に過ぎない理由を説明します。Web ユーザーと非接続ユーザーの別を問わず、まずユーザー・エクスペリエンスから始めることによって、アプリケーションの設計を改善できる理由を見極めてください。

Dick Berry, User Experience Design, IBM Ease of Use Team

Dick Berry は、Texas 州 Austin の IBM Ease of Use Architecture and Design チームの優れたエンジニアです。1980 年以来、人とコンピューターのインターフェース、ユーザー・オブジェクト・モデル、および使いやすさの設計と開発に焦点を当ててきました。彼は、IBM の共通ユーザー・アクセス (CUA: 1987 年に初めて発表された、ユーザー・インターフェース・スタイル) のいくつかの世代の設計主任でした。Dick は、ビジュアル・プログラミングの設計や、バーチャル・リアリティーの技法を使ってオフィス作業用の生産的な 3D ユーザー環境 (IBM RealPlaces) を作成する点で、革新的な仕事を行ってきました。Dick がユーザー・インターフェース設計の分野において米国で取得した特許は、45 に上ります。彼は、IBM Academy of Technology の選出されたメンバーであり、IBM の Ease of Use Web サイトの著述家でもあります。



2000年 10月 01日

時々、デベロッパーから、アプリケーションまたは Web サイトの全体的な使い勝手を最も大きく左右するのは、ルック・アンド・フィールのどの要素かと質問されることがあります。「ルック・アンド・フィール」の要素は大した影響を与えないと答えると、彼らは決まって驚きます。長年に渡ってルック・アンド・フィールは主要な論議の的となってきました。そして、あるデベロッパーたちは、あるルック・アンド・フィールを別のルック・アンド・フィールと容易に交換できるような、さまざまな体系を提案してきました。彼らはおそらく、自分たちのユーザーに関する理解の不足を補うために、こうした考えに至ったのでしょう。1990 年ごろ、わたしは、ユーザー・インターフェース管理システム (UIMS) などのパラダイム (枠組み) を標榜する、ルック・アンド・フィールの交換を可能にした設計アーキテクチャーが評判になったことを憂慮していました。わたしも、わたしの同僚の多くも、ルック・アンド・フィールは氷山の一角を表すに過ぎないと感じていました。わたしたちは、実際には、製品を使うためにユーザーが学んだり理解したりしなければならない概念のセットこそ、最も重要な要素にほかならないと感じました。わたしは、プレゼンテーションであれ、記事であれ、本であれ、可能なときはいつでも氷山のたとえを使うようになりました。以来、この分野の熟練した人々の多くがこれに賛成して、このたとえを再利用してきました。

この例えが、グラフィカル・ユーザー・インターフェース (GUI) の設計の分野における分析と長年の経験を通して磨きがかかってくるにつれ、伝えたい思っていた重要な概念も、負けず劣らず Web サイトの設計に適用されるようになりました。一部のインターフェース要素では重要性が異なるものの、Web ベース・アプリケーションの進化により、この見解の実用性が見直されています。

インターフェースの使い勝手の要素

使い勝手に貢献するインターフェースの要素と、ルック・アンド・フィールの役割について調べてみましょう。インターフェースの使い勝手は、3 つの要素を識別することによって分析できます。すなわち、図 1 に示した、ルックス(Visuals)、フィール(Interaction Techniques)、およびユーザー・モデル(User Model)です。ルックスには、視覚的合図、フィードバック、および美的要素が含まれます。視覚的合図は、ユーザーがアクションを実行できるということを知らせるものです。たとえば、従来型のインターフェースにおいて、プッシュボタンが 3 次元で表示されているなら、それは「このボタンを押してください」という合図です。フィードバックは、要求が処理されているということをユーザーに確認通知するものです。また、美的要素には、色の使用、線のスタイル、およびタイポグラフィーなど、ユーザーに訴える要素すべてが含まれます。フィールの要素には、キーボードのマッピング、マウス・ボタンのマッピング、メニューの構造、ショートカット、およびインターフェースのナビゲーションの規則が含まれます。これら 2 つを合わせた、インターフェースのルック・アンド・フィールは、言語の構文に類似しています。ユーザーがどのようにシステムと対話できるかを記述しますが、ユーザーがシステムに何を頼めるのかは記述しません。

図 1: インターフェースの使い勝手において、ユーザー・モデルはルック・アンド・フィールよりも重要
図 1: インターフェースの使い勝手において、ユーザー・モデルはルック・アンド・フィールよりも重要

ユーザー・モデル

ユーザー・モデルは、ユーザーが成し遂げようとする事柄、言い換えれば、ユーザーのタスクの目標に関係する要素から成り立っています。言語のたとえを続けるとすれば、これらの目標に関連した要素は意味体系を表します。これらの要素は、ユーザーとシステムの間の会話によって、意味を伝えます。ユーザー・モデルは、理解可能で結合力のある、概念の枠組みを提供します。ユーザーはこれを関連付けたり、自分のタスクを実行するために利用したりします。

ユーザー・モデルは、ユーザーの目標、それらの目標の振る舞いとプロパティー、および目標同士の相互関係の点から説明されるのが普通です。オブジェクト指向プログラミング (OOP) に通じている方は、これは OOP と同じだと思われるかもしれません。それは、ある程度まで正しいと言えます。異なるのは、OOP がインプリメンテーションに関する事象を扱うのに対して、ユーザー・モデルは学習や使用を通してユーザーが経験する事象(ユーザーが自分の仕事を行うにあたって使用するオブジェクトや物) だけを扱うという点です。

自分のタスクを実行するためにシステム、アプリケーション、または Web サイトを使用するにあたり、あらゆるユーザーが最初に越えなければならないハードルは、自分の目標を利用可能な機能にマッピングするということです。これらの機能は、ユーザーが作業できるように備えられている「物」、それらの物のすべての特性、それらのプロパティー (設定)、振る舞い (それらの物が行えること、およびユーザーがそれらの物に対して行えること)、およびそれらの関係 (お互いがどのように協力して働くか、およびユーザーはそれらをどのように組み合わせることができるか) という点から見ると、最も良く理解できます。

ユーザー・モデルは、上記の要素すべてを、結合力のある方法で (理想を言えば、ユーザーが直観的と思う方法で) 記述します。ユーザーがなじみのあるモデルから新しいモデルに橋渡しができるよう、設計においてメタフォーを利用することもあります。ユーザーは、自分が対話するシステムのいずれについても、頭の中でモデルを作り上げるものです。ユーザーの頭の中のモデルは意識下にあるものかもしれませんが、ユーザーの相互作用を方向づけたり、成功または失敗に影響したりします。ユーザーの頭の中のモデルは、ユーザーの概念モデルと呼ばれることもあります。ユーザーの頭の中のモデルが、設計担当者の作成するユーザー・モデルと一致するのが理想的です。この関係については、インターフェース設計におけるモデルの果たす役割とモデルに基づく設計の方法論に関して論じる将来のコラムの中で、より詳細に説明します。


ユーザー・モデル対ルック・アンド・フィール

ルック・アンド・フィールに対して、ユーザー・モデルはどれほど重要なのでしょうか。長年に渡り、わたしとわたしの同僚は、インターフェースのルックスによって体現される要素の貢献度は約 10%、フィールに由来する要素の貢献度は約 30% と考えるに至りました。ユーザー・モデルは大きな役割を果たし、その貢献度は使い勝手全体の約 60% に上ります。

図 2: ルック・アンド・フィールは氷山の一角を成す
図 2: ルック・アンド・フィールは氷山の一角を成す

もちろん、これは経験に基づいた概算ですし、従来型のグラフィカル・ユーザー・インターフェース (GUI) と Web インターフェースとでは大きく異なります。これは、Web のインターフェースによって重みが若干変わってくる分野です。従来型の Web インターフェースでは視覚的要素が大いに重視され、対話やユーザー・モデルの概念は比較的に軽視されてきました。これは、従来型の Web サイトでは、ユーザーに情報を伝えることに主眼を置いていたためです。時々フォームがあることを除けば、リンクをクリックすることが唯一の対話でした。Web ページは、気を引いたり目を引いたりするように、通常、(時には、けばけばしくもある) 視覚的要素を最も強調するように設計されてきました。e-commerce の出現に伴ってフォームがもっと普及するようになり、トランザクションのフローによってユーザー・モデルの概念がより複雑化するようになりました。Web が成熟し、顧客、従業員、および供給業者への適用が可能になり、約束されていた企業間取引 (B2B) のパラダイム (枠組み) が実現されるにつれ、氷山のたとえで説明した、相対的な寄与率という元の場所に戻って行くことになるでしょう。

設計担当者は、それらの要素がユーザーの学習と生産性に及ぼす影響を理解するのみならず、どのようにそれらの要素に影響を与え、それを制御できるかについて理解する必要があります。そして、できれば、どのようにユーザーの必要を満たすようにそれを設計できるかについても理解する必要があります。これらの要素に影響を及ぼすポイントについて考えてみましょう。

従来型のグラフィカル・ユーザー・インターフェースでは、ルック・アンド・フィールの要素が、アプリケーションが提供されるプラットフォームによって決まるのが普通です。通常、プラットフォームの UI ツールキットとスタイル・ガイドの組み合わせにより、ルック・アンド・フィールの大部分の要素が規定されます。同様に、Web アプリケーションの場合も、ツールキットは多かれ少なかれインプリメンテーション・プラットフォームによって規定されます。プラットフォームは、Java や ActiveX など、いろいろです。GUI アプリケーションの場合、ユーザー・モデルの大部分は、オペレーティング・システムとアプリケーション設計によって決められます。Web ベース・アプリケーションの場合、オペレーティング・システムのユーザー・モデルは関係があるとしても、より小さなものです。どちらの環境でも、ユーザー・モデルの概念の主要な源は、アプリケーション設計そのものです。

たとえば、Windows のツールキットには、入力フィールド、ラジオ・ボタン、チェック・ボックス、さまざまなメッセージ・ボックス、標準のダイアログ、ならびにそれらの上手な使用法を説明したスタイル・ガイドが備わっています。一般的なユーザー・モデルは、データとディレクトリー (デスクトップ上のファイルとフォルダーで表される)、クリップボードと切り取り / コピー / 貼り付けの各アクション、およびプログラム (ショートカットおよびデータ・タイプの関連付けで表される) から成り立っています。アプリケーションは、段落、節、テーブル、ヘッダー、フッター、スライド、スライド・ショー、スプレッドシートの行と列、数式などの概念に寄与します。

図 3: ユーザー・インターフェース・ツールキットは氷山の一角にしか対応しない
図 3: ユーザー・インターフェース・ツールキットは氷山の一角にしか対応しない

上記の分析から何が学べるでしょうか。最初に、設計のごく初期の段階から、ユーザーを表現する必要があるということです。ユーザーの実体を、そのスキルと動機、および実行するタスクの点から理解する必要があります。2 番目に、ユーザー・タスクに関する知識とソフトウェア・エンジニアリングの方法を利用して、概念とルック・アンド・フィールのモデル化を行えます。ユーザー・モデルは設計の基礎です。設計の評価と検証を行うための枠組みとなるだけでなく、開発チーム全体 (プログラマー、ビジュアル設計担当者、ライター、およびテスターを含む) の協力と指示に欠かせない文書の源となります。最後に、ユーザー・モデルは、初の成功と言える設計、ユーザーが直観的だと感じ、感心せざるを得ない設計を行える公算を大いに高めます。


Web アプリケーションにおける人とコンピューターのインターフェース

設計担当者たちは、グラフィカル・ユーザー・インターフェースの 15 年の進化を通して、多くを学んできました。完全になどなっていないのに、その進化はほとんど停止したも同然の状態です。多くの場合、Web 設計担当者は、盲目的に Web ベース・アプリケーションに GUI のアプローチを採用することにより、過去の罪を繰り返しているのです。Web は、ユーザーの必要、要求、および可能性に一致した、創造的なソリューションを可能にする、新しい機会を提供しています。設計担当者がこの機会を利用して、人とコンピューターのインターフェースを改善できるかどうかは、なお疑問です。我々は、ユーザー主導型の設計を可能にする、関係する多くの要素 (氷山のたとえによってある程度説明される) を理解することになると思います。

将来のコラムでは、GUI と Web ベースの設計の基本的な相違と、使いやすさに与える影響についてさらに説明します。続く何か月かの間、製品設計と開発のごく早い時期からユーザーの必要と期待を確実に満たす、ユーザー・モデルの明示的な設計の方法論について説明します。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Web development
ArticleID=237589
ArticleTitle=ユーザー・エクスペリエンス
publish-date=10012000