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

UCD＝利用者中心設計のプロセスとは？

　

ソシオメディア　上野 学
2005/8/9

UCDのプロセス

　UCDのプロセスは、国内外の専門家によって研究されており、さまざまなバリエーションを持つメソッドとして普及しつつあります。また「ISO 13407 インタラクティブシステムの人間中心設計プロセス」のように、汎用的な国際規格として標準化されている部分もありますが、ここでは、Webアプリケーションを構築するプロジェクトを念頭に、一般的にUCDといわれるプロセスの汎用的な作業ステップを紹介します。

　まずUCDのプロセスは、大きく4つのフェイズに分けることができます（下表参照）。

　UCDが重視しているのは、実装前の工程である「1. 分析フェイズ」と「2. 設計フェイズ」です。また、製品（Webアプリケーション）のライフサイクルを意識した場合、サービス開始後の「4. 展開フェイズ」はすなわち市場の評価を収集して常に改善作業を行っていくための継続的なフェイズととらえることができ、また、次の大きなリニューアルプロジェクトにつなげるための準備フェイズとも位置付けられます。

	段階	UCDといわれるプロセスの汎用的な作業
1	分析フェイズ	データの収集、ペルソナ作成、シナリオ作成、タスク分析、機能分析など
2	設計フェイズ	画面遷移の設計、段階的なプロトタイピングと各種ユーザビリティ評価など
3	実装フェイズ	UI標準、画面デザイン仕様書、テンプレートの作成、コンテンツやプログラムの実装など
4	展開フェイズ	サービス開始、市場の評価、ビジネス戦略の評価、バグフィックスやアップデートなど

　また、UCDプロセスを実践していくためには、できるだけ専門のチームを組織横断的に構成することが望まれます。メンバーには、UCDプロセス自体の管理をするリーダーをはじめ、マーケティング部門、デザイン部門、開発部門、クライアント部門などのスタッフと、ユーザビリティの専門家がいるとよいでしょう。必要であれば専門家を外部から招いてチームを作り、調査作業、分析作業、デザイン作業、評価作業などをそれぞれの専門的な知見を踏まえて進めていきます。

■データの収集

　データの収集とは、要求分析を行ううえで根拠となる情報を集めることです。クライアントの要望を聞くことはもちろんのこと、UCDでは、ユーザー観察やユーザーインタビューの結果を重視します。

　ユーザー観察の作業では、プロジェクトのメンバーが、当該システムが介在することになる場面に出向いて、実際にシステムのユーザーとなる人々の活動を直接観察します。例えば、イントラネットの業務システムを開発するプロジェクトであれば、社員が普段どのようにその業務を行っているのかを現場に出向いて観察します。ただし、不特定多数のユーザーをターゲットにしたWebサイトを作るような場合には観察が難しいため、知人や身内の人を観察することになります。

　次のユーザーインタビューの作業では、システムを実際に利用するユーザーに対して直接インタビューを行います。観察では得ることができなかった、ユーザーの主観的な見解や問題意識を把握します。例えば家電メーカーのサイトを作るのであれば、普段どのような家電を使っているか、どのようなトラブルがあるか、それをどう解決してきたか、といったことを聞きます。インタビューの相手は、市場調査で用いられるリストなどを使って探すとよいでしょう。

■ペルソナとシナリオ

・ペルソナ

　ペルソナとは、「想定するユーザーの姿を具体的かつ詳細に描いて作成された架空の人物」です。どのようなシステムも、はじめにターゲットとするユーザー層（ユーザーセグメント）を設定するものですが、ペルソナはその中から取り出した人物です。ペルソナ作成の作業では、ユーザー観察やインタビューから得たさまざまなユーザー像の代表者として、架空の人物（ペルソナ）を想定し、その人の名前、性別、年齢、職業、住所、家族構成といった基本的なプロフィールはもとより、性格や趣味、最近の関心事、そしてなぜそのシステムを利用するのかという背景までを設定していきます。そしてシステム利用の具体的な目的を定義します。

　ターゲットとなるユーザーが複数のグループに分類できる場合には、それぞれから1人ずつペルソナを作ります。ペルソナの人物像は、履歴書のようなフォーマットに記述し、プロジェクトメンバーで共有します。これにより、システムのゴールイメージを共有できるようになります。

　ペルソナ作りには、正確さよりも厳密さが重要です。あるペルソナが正確に「典型的なユーザー」であるよりも、厳密に「本当に存在しそうな人物」であるようにします。詳細に想定されたペルソナを満足させる仕組みを考えることによって、システムの設計は適切な厳密さを増していくのです。

・シナリオ

　シナリオとは、ユーザーがそのサイトで何をしようとするのか、それはどうやって行われるのか、といったことを物語風に記述したものです。シナリオはそのシステムと利害関係を持つ人々の行動や結果を定義するため、必然的に、システムのあるべき姿を導き出します。プロジェクトにかかわるメンバーがシナリオを共有することで、最終的なゴールのイメージを共有することができます。限りある時間の中で作業の優先項目を判断し、さまざまなトレードオフへの適切な対処を可能にするのです。

　ペルソナを作成してある場合、ペルソナそれぞれについてシナリオを作成します。初めは、システムを利用するフローの概要を書き、おおよそのタスクの進行をイメージできるようにします。そして徐々に詳細な描写を加え、タスクを実現するためにどういった機能が必要かを抽出していきます。シナリオでは基本的に、ペルソナがスムーズに目的を達成する様子を記述していきますが、そのシナリオの現実味やストーリーの妥当性は、プロジェクトメンバーによって随時検証され、問題点が指摘されなければいけません。（参考記事：＠IT勉強会レポート］ユーザビリティ研究会）

■タスクと機能の分析

　タスク分析の作業では、まずペルソナのシナリオから目的達成に必要な作業を「タスク」という最小単位で切り出したタスクリストを作成します。例えば、オンラインでパソコンを購入するという目的に対しては、「商品を検索する」「商品を比較する」「商品を選択する」「購入手続きをする」といったタスクが考えられます。

　次に、各タスクに対して優先度を付けます。ペルソナが目的を達成するために不可欠なタスクや、複数の目的達成のために共通して行われるタスクを重要視します。重要度の低いタスクは、システムをシンプルにするために、実現を見送ることも検討します。またそれぞれのタスクについて、全ユーザーの何割ぐらいの人がどれぐらいの頻度で行うのかという視点でも分類してみます。

　最後に、各タスクを実現する機能をリストにしていきます。例えば「商品を検索する」というタスクを実現する機能としては、「カテゴリ分類で階層的に商品を見せる」「あいうえお順で商品一覧を見せる」「自由入力の商品検索機能」といったものが考えられます。

■画面遷移の設計

　優先度付けされたタスクと、それぞれにひも付けられた機能の対応表ができたら、それらを実際の画面遷移にどうやって組み込んでいくかを考えます。まず、ここまでに行った、ユーザー観察、インタビュー、ペルソナ、シナリオなどの分析内容を再度確認しながら、各タスクを進行するうえでの基本的な手続きの流れを図にしてみます。重要なタスクが非常に複雑な手続きを必要とするといったことがないように、全体のバランスを調整します。

　次にこの図を詳細化し、画面の種類ごとに細分化します。その際、各タスクに対応付けられた機能の利用頻度や利用者割合を根拠にして、どのような順序で機能が提示され、タスク同士が画面遷移としてどのように関係し合うのかを整理します。具体的には、多くのユーザーに頻繁に使われる機能は、できるだけ目立たせて少ない操作でアクセスできるようにします。逆に、一部のユーザーにときどきしか使われない機能は、下位階層に置きます。このようにユーザーのニーズに合わせてメリハリを付けることで、ほとんどのユーザーをほとんどの状況で満足させるデザインが実現できます。

　このようなモデリング作業には、UML などの記述方法を用いることもできますが、これらはあくまで「ユーザーの目に画面遷移がどのように映るか」ということをモデル化するものであり、システムのアーキテクチャのモデルではありません。ただし、極端に実現不可能な画面展開を想定してしまわないよう、常に技術的な評価の視点を持ち合わせている必要があります。

■プロトタイピング

　プロトタイプは、ユーザビリティを検証するための試作品です。まずは比較的簡単に用意できる、ペーパープロトタイプを作成するとよいでしょう。ペーパープロトタイプは、手描きによるラフは画面のスケッチで、重要なタスクを実現する機能だけを描き込みます。これを紙芝居風にユーザーに見てもらい、全体のサービスコンセプトや基本的な画面遷移が有効かどうかを検証します。得られたフィードバックは、次により詳細なプロトタイプを作る際の参考にします。

　ペーパープロトタイプの次には、画面上に表示できる PowerPoint などでプロトタイプを作るとよいでしょう。あまり細かなグラフィック要素にこだわる必要はないので、簡単な線画で主要な画面を作ります。その際、ハイパーリンク機能を使えば、疑似的に実際のウェブサイトに近い画面遷移を見てもらうことができます。

　何度か検証を繰り返しながらプロトタイプを詳細化していく際の「理想像の作成」→「問題点の指摘」→「改善方法の発見」→「より詳細な理想像の作成」という流れの繰り返しは、まさにインタラクションデザインの作業そのものです。プログラムやグラフィックの実装作業を開始する前にインタラクションデザインを行うことによって、複雑で不確定要素の多いシステムを、きちんとユーザーの要求に合わせて、しかもできるだけ短期間で（大きな問題を早い段階で解消し、後戻りを最小限に抑えて）完成させることができるのです。

■ユーザビリティ評価

　ユーザビリティ評価は、UCDプロセスのいろいろな場面で行うべきです。特に、プロジェクト開始前の現状把握の段階や、プロトタイピングの段階、実装が始まってからの試験段階などでは重要となります。

　本格的にユーザビリティ評価を行うには、複数のビデオカメラや観察室を備えた専用のラボが必要ですが、小さな部屋とパソコン、画面の内容を録画するためのソフトやハードｓ、ユーザーの様子を記録するビデオカメラなどがあれば、最低限のテストは可能です。人材派遣などを利用してリクルートしたユーザーにシステム（のプロトタイプ）を使ってもらい、その様子を観察したり、意見を聞いたりします。ペーパープロトタイプのように動かないものをテストする場合は、スタッフがコンピュータ役になり、ユーザーの指示に従って画面を切り替えます。

　ユーザーを観察する方法以外にも、ユーザビリティの専門家が経験則にもとづいて問題を指摘する「ヒューリスティック評価」や、あらかじめ決められているガイドラインや品質評価のチェックシートを使った「ガイドラインチェック評価」などによる検証も考えられます。

システムの最終的な評価者

　今回は、利用者中心の設計として各所で実践が進められているUCDのプロセスについて、その概要を説明しました。ここで紹介した作業は、それぞれ独立したメソッドとしても深く研究されているテーマであり、構築するシステムの性質やプロジェクトの組織体制などによって取り組み方の詳細は変化するはずです。しかし重要なことは、ユーザーにとっての利用効率や利用価値を常に重視しながらユーザーインターフェイスをデザインすることです。完成したシステムを最終的に評価するのは、サービスの提供者ではなく、サービスの利用者だからです。

　

3/3

次回もお楽しみに

INDEX
Webアプリケーションのユーザーインターフェイス（3）
	Page1＜ユーザーの目的を意識する＞ システムの複雑化とジレンマ／UCD（User-Centered Design）とは？
	Page2＜ユーザビリティの定義と課題＞ デザインメソッドの必要性／デザインメソッドの必要性／従来の開発プロセスとUCDプロセスの関係／GUIの特徴
	Page3＜UCDのプロセス＞ データの収集／ペルソナとシナリオ／タスクと機能の分析／画面遷移の設計／プロトタイピング／ユーザビリティ評価／システムの最終的な評価者

関連記事

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