目的
  • 使いやすさの根拠と拡張をサポートするユーザー インターフェイスのモデルを構築する。
手順

これらのステップは論理的な順序で示してあります。ただし、ステップを入れ替えたり、いくつかのステップを並行して実行しなければならない場合もあります。また、ステップの中には検討中の特定ユーザー インターフェイスの複雑さによって、オプションとなるものもあります。

入力とする成果物: 結果となる成果物:
頻度:

実際には、ユーザー インターフェイスの設計は、たいていユーザー インターフェイスのプロトタイプ化と共に行われます (「作業: ユーザー インターフェイスのプロトタイプ化」を参照)。ユーザー インターフェイスを設計する際、継続的に設計をプロトタイプ化し、プロジェクト固有のすべてのガイドラインを考慮して、プロトタイプを公開しなければなりません。ところで、「完全」なユーザー インターフェイス設計は通常、その設計のプロトタイプ化の前には成り立ちません。多くの場合、ユーザー インターフェイス プロトタイプの数度の反復の構築とレビューが終わるまで、詳細なユーザー インターフェイス設計を据え置くのが適切です。

役割: ユーザー インターフェイス設計者
ツール メンター:
詳細情報:

設計の作成を完全にカバーし、特に使いやすさに焦点をあてている [CON99] を参照してください。

ワークフローの詳細:

ユーザー インターフェイスを設計する際、要求の顕在化時に作成した絵コンテ、プロジェクト固有のガイドライン中のユーザー インターフェイス ガイドライン、既存のユーザー インターフェイス プロトタイプを念頭に置きます。この作業の結果、絵コンテの詳細化が必要と判断される場合、こうした更新はシステム分析者により実行されます (「作業: 利害関係者の要望の顕在化」を参照)。

関連するユーザーの特性の記述 ページの先頭へ

現在の反復中で考慮される要求を実行するためにシステムと相互作用する (人間の) ユーザーの特性を記述します。主要なユーザーの記述に重点を置きます。なぜなら、相互作用の主な部分はこれらのユーザーを含むからです。この情報は次のステップにおいて重要です。

システム分析者と協力し合い、特性の記述を反映するために、アクターの記述に関する変更が必要かどうかを識別します。詳しくは「ガイドライン: アクターの特性」を参照してください。

主要なユーザー インターフェイス要素の識別 ページの先頭へ

現在の反復中で考慮される要求 (特にユース ケースおよび絵コンテ) を確認し、システムのユーザー インターフェイスのプライマリ ウィンドウを識別します。「プライマリ」ウィンドウとは、ユーザーがもっともよく相互作用するウィンドウを意味します (ユーザーにとってシステムのメンタル モデルの中心となるユーザー インターフェイス要素)。プライマリ ウィンドウはメニューを含み、サブ ウィンドウまたはフォームを含むことがあります。プライマリ ウィンドウはユーザーが行き来するウィンドウです。非プライマリ ウィンドウはプライマリ ウィンドウの一部になる場合があります。

メインとなるプライマリ ウィンドウは、ユーザーがアプリケーションを立ち上げるときに開くウィンドウであるべきです。このウィンドウはアプリケーションが動作しているときは常にオープン状態にあり、ユーザーは「使用時間」中の多くの時間をここで過ごします。ここは常にオープンしていて、ユーザーが最初にシステムと接触する場所でもあるため、ユーザーにシステム モデルを印象づける最初の手段となります。メインのプライマリ ウィンドウを一般に「ホーム ページ」といいます。

共に表示する必要がある、または他のユーザー インターフェイス要素と空間的な関連のあるユーザー インターフェイス要素を同じプライマリ ウィンドウにグループ化するように試みます。ただし、画面領域の制限で常に可能とは限りません。場合によっては一度に表示する必要があるオブジェクトの数がわかるため、平均的なオブジェクトの数がこのステップへの重要な入力であることに注意してください。オブジェクトの数が多すぎると、同じウィンドウにすべて表示できないことになります。その代わりに、プライマリ ウィンドウはオブジェクトのコンパクトな表現を含み、各オブジェクト (オブジェクトのセット) について別個のプライマリ ウィンドウを定義することができます。

以下は、プライマリ ウィンドウに関する推奨事項です。

  • ユーザーにとってシステムのメンタル モデルの中心となるウィンドウ。
  • ユーザーがほとんどの時間を過ごすウィンドウ。
  • ユース ケースの初期画面となるウィンドウ。

目標はプライマリ ウィンドウの数とそれらの間のナビゲーション パスの数を最小化することである点に注意してください。

ナビゲーション マップの定義 ページの先頭へ

識別されたプライマリ ウィンドウのセットと絵コンテに基づき、システムのナビゲーション マップを定義します。

ナビゲーション マップは、プライマリ ユーザー インターフェイス要素とそれらのナビゲーション パスを含まなければなりません。ユーザー インターフェイス要素間で有効なすべてのパスを含む必要はなく、主なパスだけでかまいません。目標は、ナビゲーション マップがシステムのユーザー インターフェイスのロード マップとして機能することです。

ナビゲーション マップ中の「最上位」のユーザー インターフェイス要素として最も明白な候補は、メインとなるプライマリ ウィンドウ (ユーザーが使用時間の大部分を費やすウィンドウ) です。

ナビゲーション マップは、特定の画面または機能に到達するために、ユーザーが「何回クリック」する必要があるかを明確にしなければなりません。一般に、アプリケーションの最も重要な領域は、プライマリ ウィンドウから「1 度だけクリック」して移動可能にするとよいでしょう。ウィンドウ間のナビゲーション パスが長すぎると、不必要な対話のオーバーヘッドが加わるばかりでなく、ユーザーがシステム内で「迷子」になってしまうかもしれません。理想的には、全ウィンドウが 1 つのメインとなるプライマリ ウィンドウから開くことができ、ウィンドウ間のナビゲーション パスの最大長が 2 となることです。ナビゲーション パスが 4 以上にすることは避けるようにします。

プロジェクト固有のガイドラインに説明されているように、ナビゲーション マップは、システムのユーザ インターフェイスに対する使用法メタファを準拠および反映する必要もあります。

ナビゲーション マップにはさまざまな表現を用いることができます。以下に例を示します。

  • 階層的な「ツリー」図。ダイアグラムの各レベルは特定のユーザー インターフェイス要素に至るまでに必要なクリックの数を表します。
  • カスタム アイコンを含むフリー形式のグラフィック。
  • UML クラス図。クラスはユーザー インターフェイス要素を、関連はナビゲーション パスに対応します。

どの表現を用いるかについての選択はプロジェクト固有のガイドラインに指定されます。

ユーザー インターフェイス要素設計の詳細化 ページの先頭へ

この時点で、以下のような高レベルのユーザー インターフェイス設計が完了しています。

  • プライマリ ウィンドウが識別されました。
  • ユーザー インターフェイス要素とそれらのナビゲーション パスが定義されました (ナビゲーション マップ)。

次に、ユーザー インターフェイス要素の詳細な設計が実行できます。ユーザー インターフェイス要素の設計作業には次のような側面があります。これらについてそれぞれを以下で説明します。

プライマリ ウィンドウの視覚化の設計

プライマリ ウィンドウ、特にメイン ウィンドウの視覚化は、システムの使いやすさに重大な影響を及ぼします。この視覚化の設計にあたっては、内包するユーザー インターフェイス要素のどの部分 (特性) を視覚化するべきかを検討する必要があります。絵コンテのイベント フローを利用すると、表示する特性に優先順位を付ける際に役立ちます。ユーザーが、ユーザー インターフェイス要素の多数の異なる特性を見る必要がある場合、プライマリ ウィンドウの複数のビュー、つまり異なる特性のセットを視覚化するビューを実装してもかまいません。この視覚化の設計には、視覚的なすべての次元を使って、内包ユーザー インターフェイス要素 (特性) がどのように視覚化されるべきかを検討する必要があるという意味もあります。詳しくは、「ガイドライン: ユーザー インターフェイス (一般) 」の「視覚的次元」を参照してください。

可能ならば、プライマリ ウィンドウ中に表示される要素間の「共通項」を識別します。ある種の次元をベースとして共通項を視覚化すると、ユーザーは要素を互いに関連付けることができ、パターンが見えてきます。これによりユーザー インターフェイスの「帯域幅」は大幅に増大します。

次のような側面を表示したい顧客サービス システムがあるとします。

  • 顧客のこれまでの不満や質問
  • これまでに顧客が購入した製品
  • これまでに顧客に請求した金額

ここでの共通項は「時間」です。このように同一水平時間軸上に不満または質問、購入と請求書送付を並べて示すと、これらの項目の関連パターン (もし存在すれば) を見て取れます。

プライマリ ウィンドウのユーザー操作の設計

ここでは、プライマリ ウィンドウに対して呼び出し可能なユーザー操作の「実装」方法を決定します。プライマリ ウィンドウのユーザー操作は、メニュー バーのメニュー項目として提供するのが普通です。また、ショートカット メニューやツールバーを使う代替起動法や補完手段も提供します。

各プライマリ ウィンドウについて、メニューとメニュー オプションを定義します。たとえば、文書エディタでは [切り取り] や [コピー] などの関連のある操作をまとめた [編集] メニューがあります。

ユーザーに複雑な対話を必要とする操作の場合は独自に 2 次ウィンドウを持つことが許されます。たとえば、文書エディタでは、文書の [印刷] 操作がありますが、複雑な対話があるため、独立したダイアログ ウィンドウを持つことが許されています。

1 つのウィンドウ中で多数のオブジェクトを視覚化する場合、こうしたオブジェクトを含むユーザー操作を設計する必要があるかもしれません。そうしたユーザー操作の例を以下に示します。

  • 複数のオブジェクト間の検索。
  • 複数のオブジェクトの並べ替え。
  • 複数のオブジェクトの階層の表示。
  • 複数のオブジェクトの選択。

詳しくは、「ガイドライン: ユーザー インターフェイス (一般)」を参照してください。

その他の機能の設計

ユーザー インターフェイスに必要な動的振る舞いを追加します。選択操作パラダイムのように、ダブル クリックでオープンし、マウスの右ボタンでポップアップ メニューを出す等、動きのほとんどはターゲット プラットホームによって得られますが、次のことは自分で決定する必要があります。

  • ウィンドウ管理のサポート方法。
  • カーソルの入力位置、スクロールバーの位置、開いているウィンドウ、ウィンドウの大きさ、相対的なウィンドウの位置等のセッション情報のうち、セッション間で格納しておくべきものは何か。
  • プライマリ ウィンドウは SDI (Single Document Interface) と MDI (Multiple Document Interfaces) のどちらをサポートするべきか。

次のように使い勝手を向上させる共通の機能も評価します。

  • 「ウィザード」がある「オンライン ヘルプ」を提供するべきか。
  • システム中を安全に動き回れるようにするため [元に戻す] 操作は提供するべきか。
  • ユーザー側のイベントを監視したり、ユーザーに積極的にアクションを勧めるために 「エージェント」を提供するべきか。
  • 関係を視覚化するため、「動的ハイライト」を提供するべきか。
  • ユーザー定義の「マクロ」をサポートするべきか。
  • ユーザーにより構成可能とするべき特定の分野が存在しているかどうか。

詳しくは、「ガイドライン: ユーザー インターフェイス (一般)」を参照してください。



Rational Unified Process   2003.06.15