MSDN : Designing UX for apps (3)

今回も引き続き、MSDNの "Planning Metro style apps" (日本語版)を取り上げていきたいと思います。本日お話しするメインのトピックはいよいよアプリの機能の話になります。

前回までの流れの中で、該当するアプリにおいてどのようなシナリオをユーザーがたどることができるかを検討していました。今度はそれをアプリの機能としてマッピングしていくことになります。

MSDNでは、ステップとして「3. アプリに含める機能を決める」「5. アプリの UI を設計する」とステップを分割し、その間に収益化のプランを作ることを書いていますが、Metroスタイルアプリであることを前提に考えた場合、ある程度UIを頭の中で意識しながら機能の検討をしていくことが現実的ではないかと思います。

まず、Metroスタイルアプリの大きなスクリーンフローとしてどのようなものがあるのかを確認しておきましょう。現在ストアに存在するほとんどのアプリケーションは、多くのコンテンツを左右の流れの中で見せていく「階層システム」と呼ばれるナビゲーションパターンを利用しています。IEなど、単一のドキュメントを取り扱う(複数取り扱うにしても、一度にたくさんを見せることがない場合)アプリについては「フラットシステム」というナビゲーションパターンを利用します。これらについては「Metro スタイル アプリのナビゲーション デザイン」として情報がまとまっていますので、こちらもあわせて参照ください。

navigation system

選択のポイントになるのは、「どのようなコンテンツ=データを取り扱うか」ということになります。検討したシナリオの中で、連続したデータを一覧させる必要があるようであれば階層システムがフィットするでしょうし、そうではなく単一のデータの閲覧や編集に集中するようなシナリオの場合にはフラットシステムがよいでしょう。

Metroスタイルアプリにおいては、できるだけ「コンテンツを直接操作する」ようにとガイドラインが設けられていますので、大枠のナビゲーションシステムが決まった段階でコンテンツの(操作の末の)見せ方をある程度決めて、そのコンテンツをどのように操作できるかについて検討します。直接操舵ができない場合には、選択後にアプリバーのコマンドで操作する、ショートカットメニューで操作することなどを検討することになります。

この過程において、できるだけたくさんのラフスケッチを描かれることをお勧めします。その際、タッチファーストを身上とするMetroスタイルアプリにおいては、早い段階でタッチ操作がスムーズにできそうかどうかを確認しておくことも重要になります。このようなケースで、以前から公開しております「Metro Style UI設計用スケッチノート」も是非ご活用ください。A4で印刷していただき、厚めの段ボールにでも張っていただいて、余白部分を切り取っていただければ「タブレットプロトタイプ」の完成です。また、スレート端末をお持ちの方は実際に端末に紙を載せて試してみると、重さなども含めて確認することができ、より実際の感覚がわかりやすいかと思います。

metro paper

次回は、大枠が決まった流れの中で、コンテンツに到達するまでにどのような流れを作るか、コマンドをどのように配置するかについて続けていきます。次回もよろしくお願いいたします!

MSDN : Designing UX for apps (2)

前回同様、MSDNの "Planning Metro style apps"日本語版)を取り上げていきたいと思います。本日お話しするメインのトピックはユーザーシナリオです。前回のおさらいとなりますが、 “Planning Metro style apps” の章立ては以下のとおりです。

  1. ユーザー エクスペリエンスの目標を決定する( Decide what your app is great at )
  2. アプリでユーザーが行う操作 (フロー) を決定する( Decide what user activities to support )
  3. フローに使うアプリの機能と Windows の機能を決定する( Decide what features to include )
  4. アプリで収益を得る方法を決定する( Decide how to monetize your app )
  5. アプリのレイアウトを計画する( Design the UI for your app )
  6. 第一印象を良くする( Make a good first impression )
  7. プロトタイプを作り、ガイドライン、ユーザーの印象、要件に基づいて設計を検証する( Prototype and validate your design )

この中でも2番目の「アプリでユーザーが行う操作(フロー)を決定する」の部分を掘り下げていきましょう。

まずはユーザーを特定することから始めていきます。対象ユーザーの基本的なプロフィールを書き出すところから始めましょう。名前/年齢/性別/家族構成/趣味/職場や学校などの環境など、箇条書きで書き出してみます。典型的なユーザーが実在し、話ができる場合には、直接話しながら整理していくと効果的です。このような作業を「ペルソナの作成」と呼び、本格的に掘り下げる方法も存在していますが、時間がないような場合でも、

  • 簡潔なプロフィール
  • 対象となるサービス/環境/機器に対するリテラシーのレベル
  • アプリに対する代替手段を使った具体的な行動
  • アプリを通じたサービスの利用で得ようとしている価値

といった観点に絞り、できれば少し違うパターンのユーザーを想定し、名前を付ける程度までは行っておくとよいでしょう。これらをはっきりさせたうえで、前回整理したような、そのユーザーが持つ「潜在的なニーズや抱えている問題」に着目します。アプリはその提供するコンテンツや機能を通じて、ユーザーの課題を解決しなければなりません。今後機能を考えるうえで、想定ユーザーがゴールを達成するうえで必要のない機能であれば、なぜ存在するのかを明確にする必要があるでしょう。特にMetroスタイルアプリの場合には、シンプルな機能を実現する単機能のアプリが多く、OSを含むユーザーインターフェイスの構造も多機能な状態を想定していないため、機能の絞り込みは設計時点で重要になってきます。

次に、「潜在的なニーズや抱えている問題」を「既存の代替手段」でどのように実現していて、そこにどのような課題があるのかを浮き彫りにするために、ユーザーシナリオを描いていきます。あまり難しく考えずに、一人称の口語の表現で、感じたことをそのまま書いていくようにしてみてください。嬉しい/がっかり/腹が立つ、などのユーザーの感情の動きも重要な情報です。ポジティブなものもネガティブなものもできるだけ記述してみましょう。たとえば、旅行用のアプリケーションを作っている場合であれば、代替手段は既存のガイドブックなどかもしれません。その場合:

「旅行計画をするために、本屋に行ってガイドブックを買って来よう。今回は初めて行く場所なので、現地の通貨のことやホテル周辺のことなどもWebも併用して調べておく必要がありそうだ。ガイドブックはかなり分厚いけど、今回の大きな目的であるサッカー観戦のことについてはあまり書いていないようだな。(大枠の情報は得られても詳細の情報はガイドブックでは難しいらしい。残念だ。)」

という感じで、どんどん書いてみてください。この作業から「既存代替手段を使ったフローが持つ問題」を探り、それを解決するようなアプリの機能を検討する、という流れになります。ある程度アプリの機能をこの後の作業を通じてイメージできれば、アプリを使った場合のシナリオを描いてみて、実際に改善がありそうかどうかを想定してみるとよいでしょう。

次回は、これらの検討をベースに、いよいよ具体的な機能の想定に入っていきます。Windows8の特性なども考えながら検討を進めていきたいと思いますので、次週もよろしくお願いいたします!


今回ご紹介した進め方は、弊社の展開しているUXワークショップでもお伝えしている内容になります。今回、本来二日間で行っているこのワークショップを一日に凝縮し、IT-Pro様主催で「ユーザーインターフェイス改善セミナー」と題して7月末に講座をやらせていただくことになりました。こちらでも、実際に開発を始める前にやるべきことについて押さえていきますので、参加をご検討いただければと思います。