第 4 章: Hilo ユーザー エクスペリエンスの設計

Hilo Browser アプリケーションは、魅力的なタッチ対応のユーザー エクスペリエンス (Ux) を提供する設計となっています。高速で応答性の高い、直観的な Windows 7 ベース アプリケーションです。この記事では、Hilo Browser アプリケーションのユーザー エクスペリエンスがどのように設計されたのか、また全体的な設計プロセス、設計に携わった人々、採用された設計上の重要な判断について説明します。

設計目標

設計プロセスの最初のステップは、Hilo の全体的な設計目標を定義することでした。目標は完璧に確定されたものではありませんでしたが、設計プロセスの各段階におけるさまざまな意思決定の際に役立ちました。プロセス全体の要所要所で設計チームが目標を確認していたため、設計プロセスを常に正しい方向に進めることができました。目標は意図的にハイレベルかつ幅を持たせて設定していたので、設計チームはある程度柔軟に対応することができました。

Hilo の目的は、ユーザーが写真を参照、編集、共有できるようにすることです。タッチ対応スクリーンを搭載したコンピューターのタッチ インターフェイスを使用することで、ユーザーは自然なジェスチャで写真を閲覧したり、コメント付けや編集を行ったり、インターネット上の写真共有サービスを通じて写真を共有することができます。

Hilo の全般的な設計目標は、Native C++ とネイティブの Windows 7 ライブラリを使って、シームレスに連携するいくつかの小さなアプリケーションを開発することでした。オペレーティング システムには、最新の魅力的な統合型ユーザー エクスペリエンスを提供する機能を豊富に持つ Windows 7 を選択しました。また言語には、最高のスピードと効率性を提供し、Windows の機能をダイレクトに利用できるネイティブ C++ を選択しました。大きな単一のアプリケーションではなく、効率性の高い小さな複数のアプリケーションを連携させてシームレスなユーザー エクスペリエンスを開発することによって、効率性という目標をさらに具体化することができました。

設計チームの結成

設計チームは、Ux デザイナー、Ux マネージャー、開発者、そして開発プロジェクト マネージャーといった各専門分野の担当者によって結成されました。チームにはさまざまな経験を持つ担当者がいたため、発展性のあるアイデアが次々と出され、さらに、実装に使用するテクノロジや開発チームのスキルやリソースといった観点から、そうしたアイデアの実行可能性を検証することもできました。

設計の改良や問題点の洗い出しのためにたびたびブレーンストーミングを繰り返すという、反復的な設計プロセスでした。チームはこのプロセスの要所要所で、設計を目標に照らし合わせて検証し、当初の目標から逸脱していないかどうかを確認していました。

最初のブレーンストーミング

初期のセッションの目的は、チームがユーザーの立場になってタスク指向の観点からアプリケーションを検討することでした。チームはこの作業の中でさまざまな設計案を評価し、選んだ設計をさらに改良して、ユーザーが実行する可能性のあるさまざまなタスクやワークフローに耐えうるものであることを確認しました。

最初のブレーンストーミング セッションでは、4 つの汎用的なモジュール (関連性のある機能の集合) の大枠が決まりました。このモジュールとは、｢整理」、「共有」、「編集」、「取得」です。重要なタスクの相互接続性や重要度を明らかにするため、これらのモジュールを出発点とするバブル ダイアグラムが作成されました。図 1 が初期のバブル ダイアグラムです。この 4 つのモジュールはワークフローを表す矢印で結び付けられ、これらの矢印にはタスク名とそのタスクの影響を受けるアイテム数がコメントとして記入されました。

図 1 初期のバブル ダイアグラム

以上が設計プロセスの第 1 段階であり、これによって設計者がアプリケーションの主要な機能に注力できるようになりました。ユーザーのタスクとワークフローに注目することで、実際のアプリケーション機能が少しずつ見えてきました。こうした機能の設計は、それぞれ単独ではなく、ユーザー タスクというコンテキストの中で行われました。ユーザー タスクはユーザー エクスペリエンス全体に対して、大きくはありませんが重要な影響を及ぼす可能性があります。

バブル ダイアグラムに示されているように、このアプリケーションは、カメラや USB メモリ、または DVD やハードディスクなどのローカル ドライブといった、さまざまな種類のデバイスからアイテムを取得できる必要があります。また、ユーザーがインターネットからアイテムを取得することも可能でなければなりません。バブル ダイアグラムで示されるように、ユーザーは取得したアイテムをコレクション別に整理し、コレクションにメタデータを追加し、コレクションをアプリケーション アイテム ライブラリに追加することができます。ライブラリに追加されたすべてのアイテムは、オンライン写真共有サイトに投稿したり、ローカルでのスライドショーを表示することによって、他のユーザーと共有することができます。バブル ダイアグラムの最後のモジュールのとおり、ユーザーは個々のアイテムを編集してメタデータを追加した後、編集済みのファイルを保存、共有したり、変更を取り消すことも可能です。

このバブル ダイアグラムは第 1 段階に過ぎず、これから見ていくように、設計プロセスが進むにつれて機能セットが変更されていきます。

ストーリーボードの作成

最初のバブル ダイアグラムでは、潜在的な機能の全体像、他の機能との関連性、そしてデータのワークフローが明らかになりました。次のステップは、この情報に基づいてストーリーボードを作成することでした。ストーリーボードは、主なレイアウトや遷移を非常に大まかにスケッチしたものであり、初期の設計に含まれる潜在的な問題点を明らかにする役割を果たします。映画産業で使われてきた技法ですが、現在ではユーザー インターフェイス設計において広く使われるようになっています。

ストーリーボードにすべてを描き出す目的の 1 つは、すべての機能とユーザー インターフェイス項目が確実に見えるようにすることです。設計プロセスを何度も繰り返していくうちに、それぞれの機能がより緊密に全体設計に統合されるようになり、新しい関係性や相互依存性が浮上してきます。

図 2 は、新しいアイテム コレクションを作成する操作を示したストーリーボードです。このストーリーボードでは、まずアイテムをソース (カメラやハードディスクなど) から取得し、ウィンドウの上半分に表示しています。この後、ユーザーはコンピューター画面のタッチ インターフェイスを使って複数のアイテムをウィンドウの下半分にあるコレクション トレイにドラッグしています。コレクションを作成した後は、アイテムをソートしたり、手動で移動して、コレクションを整理します。このストーリーボードを見ると、設計者はストーリーの各段階で 1 つずつオプションを考案し、ストーリーボードに各オプションについてのコメントを書き加えていることがわかります。

図 2 新しいアイテム コレクションの作成を示したストーリーボード

図 3 は、アイテムを編集する操作を示した別のストーリーボードの例です。この図が示すとおり、ユーザーはタッチ インターフェイスを使ってアイテムをトリミングしたり、コレクションやアイテムにコメントを付けたり、ウィンドウ内外にアイテムをドラッグしてコレクションをフォルダー別に整理することができます。

図 3 アイテムを編集する操作を示したストーリーボード

モックアップの作成

設計チームはストーリーボードを作成することによって、ユーザーとアプリケーションの対話を詳細に把握することができました。設計チームは次に、Microsoft Expression Blend 3 を使用して Silverlight プロトタイプを作成することにしました。Expression Blend は、設計者がアイデアを繰り返し確認しながら、すばやく形にするための優れた設計者向けツールです。Expression Blend を使用することで、設計者はアプリケーションに対する構想をデモし、実際にコードを書くことなくアプリケーションを動作させ、対話機能、アニメーション、遷移を加えることができます。

チームはモックアップを利用して、実際の環境でユーザー インターフェイス設計をテストし、全体的なエクスペリエンスを評価しました。Expression Blend のような迅速なプロトタイプ化が可能な環境を活用するメリットは、開発コストをほとんどかけることなく、ユーザーが実際に見たり触れたりできるものを作り出せる点にあります。つまり、これによって、設計チームがユーザビリティをテストした人からのフィードバックを即座に得ることができるのです。

アプリケーション内の各モジュール間での対話をテストするために、チームはユーザー インターフェイスの Silverlight モックアップを作成しました。ここでの主な目標は、アプリケーションがどれほどダイナミックに動作するかといった、アプリケーションにおける視覚的な反応を確認することでした。この目標を達成するのは、紙のスケッチでは不可能です。図 4 は、このプロトタイプのスクリーンショットです。モックアップに含まれるのはユーザー インターフェイスだけで、各コントロールの後ろにはコードは存在していません。

図 4 Silverlight プロトタイプ

図 4 のモックアップはタブ付きのレイアウトになっており、メイン モジュールへのアクセスが用意されています。また、 RibbonUI コントロールによって、選択されたモジュール機能へのアクセスも用意されています。ウィンドウの大半にアイテムとアイテム コレクションが含まれています。このモックアップもやはり第 1 段階に過ぎず、設計プロセスの中で新機能の開発とテストを行うたびに、モックアップがいくつも作成されることになります。

ユーザビリティ テストの実行

ここまでの段階で、ユーザー インターフェイスの実質的な部分の設計が完了したので、設計チームは一般ユーザーにとって自然で使いやすい設計になっているかどうかを確認するために、ユーザビリティ テストを実施しました。ユーザビリティ パネルには、年代や経験の異なる人々の代表を選出しました。パネルには、アプリケーションを使用して一連のタスクを実行することが依頼されました。ユーザビリティ テスト チームは、パネルの各メンバーがタスクを実行する様子をビデオで撮影し、アンケート調査への回答も促しました。また、アプリケーションを使用した感想や、さらに直観的で使いやすくするための提案を求めました。

モデルの改良

ユーザビリティ テストの結果とストーリーボードは、ユーザー タスクとワークフローの観点から設計を合理化するために役立つものでした。次の段階では、これらで生じた変更を念頭に置きつつ、モデルを再設計しました。設計チームは 4 つのモジュールを均一に扱うよりも、むしろタスクを整理する作業に注力することにしました。それによってワークフローの改良が進みました。図 5 は、この段階で作成したストーリーボードです。ツール バーの一種である一番上の階層リンク バーのほか、"重複アイテム"、"削除アイテム"、"新しいフォルダー" を表すアイコンが使われています。

図 5 階層リンク バーを追加したストーリーボード

この 2 つ目のモデルでは、ワークフローが今までよりずっと精査されています。その一方で、ボタンやツールの冗長性に関連した問題がいくつか浮上しました。出てきた問題を検討した結果、リボン ベースのユーザー インターフェイス (UI) のバリエーションが考案されました。

問題点の洗い出し

次の段階として、設計チームはプロジェクト全体について客観的な見直しを行いました。ストーリーボードを見る限り、この設計は非常に複雑なアプリケーションになっており、機能があまりに多すぎるため、アプリケーションの運用開始が大幅に遅れる可能性があることがわかりました。こういった複雑性は当初の設計目標から逸脱するものです。開発者が好むあまり複雑でないアプリケーションを作成するためには、ある程度設計を簡素化する必要があると設計チームは判断しました。

ここまでのストーリーボードとモックアップから得た教訓を活かして、2 回のブレーンストーミング セッションを 2 日間に分けて実施し、新しい設計を承認することになりました。最初のセッションでは、設計チームは参照エクスペリエンスに全力を投入することにしました。参照エクスペリエンスとは、編集やアップロードの対象となるアイテムを収集する操作です。1 回目のミーティングで討議するために、4 種類のブラウザー設計がスケッチされました。そのうちの 1 つが図 6 です。

図 6 改訂後のブラウザー設計

設計チームは集まると、ホワイトボードにストーリーボードを描きながら、いくつかの対話方法の案を検討しました。それぞれの設計の長所と短所について議論した結果、階層型カルーセル (図 6 の右側) が最もポテンシャルが高いと判断されました。このコンセプトについて協議を重ね、細かい点を詰めていくうちに、次回のミーティングに向けて有益な提案が次々と出されました。たとえば、スタック形式のカルーセルを軌道ディスプレイ モデルに切り替えるといった案です。1 日目のミーティングの後、翌日のミーティングで提示するモックアップが数多く作成されました。

設計チームは 2 日目のミーティングでこの設計のバリエーションをさらにいくつか検討し、最終的に選ばれたのが、二重軌道デザインの下に結果ペインを付けるという案でした。ブラウザーで選択されたアイテムがコレクションに保存され、後で他の Hilo アプリケーションからアクセスできるようになります。次のステップは、この設計をさらに改良するために、参照エクスペリエンスの例をストーリーボード化することです (図 7)。

図 7 軌道ブラウザー

この軌道ディスプレイとは、Windows エクスプローラーで表示されるようなファイル構造を表しています。内側の軌道上のフォルダーを選択すると、その軌道が展開されて外側の起動は消えます。選択されたフォルダーは外側の軌道の下中央まで回転され、そのフォルダーにサブフォルダーがあれば、中央の新しい軌道として表示されます。下部分のペインには、アクティブなディレクトリのフォルダー以外のコンテンツが表示され、位置を変更すると更新されます。このストーリーボードには、ユーザーがこのインターフェイスを使用した場合に発生するアニメーションが示されています。

さらなる改良の実施

この段階で、主な設計機能が出揃いました。設計チームはいくつかのモックアップを作成し、アイコンのレイアウト、タッチ操作のヒット ゾーンやスキャン ゾーンなど、重要な UI 要素を決定しました。図 8 は軌道モデルの設計例、図 9 はタッチ ゾーンを表すオーバーレイを示しています。

図 8 軌道モデルのモックアップ

図 9 タッチ ゾーンを表すオーバーレイ付きのモックアップ

図 9 に示されているタッチ ゾーンとスキャン ゾーンを見れば明らかなとおり、ユーザーは指またはマウスのジェスチャによって軌道を回転させ、別のフォルダーを前面に配置し、そのフォルダーをタッチして選択することができます。このバージョンのモデルでは、左上にホーム フォルダーと以前選択されたフォルダーのアイコンがあります。下のペインに表示可能な数よりも多くのアイテムが選択中のフォルダーに含まれる場合、ユーザーは指でドラッグするジェスチャによって、表示されていなかったその他のアイテムを表示することができます。

これらのモックアップを検討しているうちに、チームのユーザー リサーチ担当者から、縦横比や使用頻度の高い機能を使うためのスペースをできるだけ広げるにはどうすればよいかという問題が提起されました。この点を反映した改訂版の設計を詳しく精査するために、新しいストーリーボードとさらなる数のモックアップが作成されました。

図 10 は、改訂後の軌道モデルです。このモデルでは、改定前のモデルと同じように 2 つの軌道 (現在のフォルダーに対応する軌道と、現在のフォルダーのサブフォルダーに対応する軌道) が示されています。このモデルの改良点は、現在のフォルダーを左上に固定し、その軌道の上部分だけをそのまま見えるようにしたことです。その結果、現在のフォルダーが軌道上に存在するという印象を残しながら、余分な軌道の下部分を省略することで、内側の軌道のスペースを広げることができました。改訂前より大きなアイコンを使えるようになり、サムネイル ペインのスペースも広く取れるようになっています。また、数回にわたるプロトタイプ化とテストの結果、前のディレクトリにすばやく移動するための矢印を追加することになりました。実際の使用シナリオをモニターしたところ、この矢印は履歴スタックよりも使用頻度が高いことが判明しました。

図 10 改良された軌道モデル

ユーザーがフォルダー構造をドリルダウンしていくと、各フォルダーの階層リンクの軌跡が積み重ねられ、左上に固定されて表示されます。ユーザーはこのスタックをクリックして階層リンクの軌跡を展開することができ (図 11)、これにより各フォルダーが軌道上に存在する状態で表示されます。ユーザーは階層リンクの軌跡にある任意のフォルダーを選択して、そのフォルダーに移動することができます。

図 11 階層リンクの軌跡を展開

ユーザーがサブフォルダーのないフォルダーにドリルダウンした場合には、表示される軌道は選択中のフォルダーだけとなります。図 12 はその様子を示しています。この場合、画面上のスペースが余るので、画面の下半分にあるサムネイル表示パネルが上に向かって広がり、使用可能なスペースをすべて使い切れるようになります。

図 12 サブフォルダーの軌道が存在しない場合、階層リンクの軌跡が縮小

これで、設計作業の大部分が終了しました。

最終設計の作成

図 13 が最終設計です。この完成済みの設計では、ユーザーが UI と対話できる場所や、その対話による作用が明確になっています。これはつまり、C++ 開発チームに設計を引き渡す準備が整ったことを意味しています。

この設計では、フォルダーの階層構造が従来の Windows エクスプローラーよりもはるかに見やすく表示されます。設計者はユーザーが最も注目するもの、つまり現在選択されているフォルダーの内容に集中しながら、階層リンクの軌跡を展開することで、他のフォルダーにもアクセスできるようにしています。

図 13 最終的な軌道モデル

ブレーンストーミング、ストーリーボード、モックアップを利用した反復的な設計プロセスを通じて、設計チームはさまざまなシナリオをテストし、画面スペースの有効利用と、Windows 7 のタッチ インターフェイスで提供されるマウスと指の自然なジェスチャの活用によって、ユーザー エクスペリエンスを最適化することに成功しました。

まとめ

この記事では、Hilo Browser アプリケーションのユーザー エクスペリエンスの設計プロセスについて説明しました。Hilo Browser のユーザー インターフェイスは、ブレーンストーミング、ストーリーボード、モックアップ、ユーザビリティ調査、そして段階的な改良作業を含む反復的なプロセスを通じて進化しました。次の記事では、Hilo アプリケーション開発の基盤として使用された Hilo Common Library の設計と実装について説明します。

前へ | 次へ | ホーム