前回説明した通り,実際にシステムを利用するユーザーを対象にグループ・インタビューを実施すれば,ユーザーの潜在ニーズを明確にすることができます。しかし,ユーザーの潜在ニーズを明確にしても,それだけでは十分ではありません。
そのままシステムを構築しても,ユーザーテストで「使いにくい」という評価をもらう可能性がまだ残っています。ユーザーの潜在ニーズに基づいて考えた仕様が本当にユーザーのニーズに合っているのかを,確認する必要があるのです。
確認作業をテストフェーズで実施するのでは,遅すぎます。作り直すのに多くの時間と費用が必要となるからです。作り直しても影響が少ないシステム開発の初期フェーズで,ユーザーに仕様を確認するようにしましょう。要件定義から基本設計のフェーズで,ペーパー・プロトタイプを用いたユーザビリティ・テスティングを実施するのが効果的です。
ペーパー・プロトタイプとは
ペーパー・プロトタイプとは,文字通り,紙を使ったプロトタイプのことです。画面を設計するときに,レイアウトや配色,項目を仕様書にまとめ,画面イメージを作成すると思います。その画面イメージが,ペーパー・プロトタイプに相当します。
写真1は,あるシステムの画面イメージを使って,ユーザビリティ・テスティングを実施している場面です。特別なものを用意する必要はなく,システム開発作業で作成している画面イメージを流用すればよいでしょう。手書きの画面でも構いません。ここでは見た目の確認だけでなく,操作上の問題点も確認するようにしましょう。
ここから,ペーパー・プロトタイプを利用したユーザビリティ・テスティングの実施方法を解説していきます。
事前準備
テスティングで確認する内容を検討してシナリオを作成する
初めに,確認したい内容を検討します。すべての画面について確認することができればよいのですが,画面数が多いと時間がかかってしまいます。そこで,システムの代表的な機能に絞り,検証対象の画面を絞り込みます。例えば,商品を注文するようなシステムであれば,在庫管理,発注,注文訂正などの主要な機能を選び,検証対象の画面を決定します。
検証対象の画面を決定したら,次にタスクを作成します。タスクとは,ユーザーに実施してもらう作業内容のことです。1個のタスクは20分程度で完了する内容とし,1回のユーザビリティ・テスティングでは,3~4個のタスクを実施してもらうようにします。タスクは,具体的な状況を想定し,検証対象のシステムを使ってユーザーに作業を実施してもらいます。次にタスクの例を示します。
あなたは,□□株式会社の調達部門に所属しており,商品の発注業務を担当しています。本日より,5月に稼働した新システムを利用して業務を行うことになりました。
【タスク1】
新システムを利用して,○○という商品の在庫数を確認してください。
【タスク2】
在庫数が少ないことが分かったので,新システムを利用して,○○を200個発注してください。
タスクの文章には,ヒントとなる言葉を入れないように注意します。例えば,「検索ボタンを押して…」などと具体的な操作指示となる文章は避けます。
作成したタスクをシナリオとしてまとめます。シナリオには,タスクのほかに,事前にユーザーに説明しておく内容や,事後インタビューについても記載します。
ユーザビリティ・テスティングは「事前説明」「事前インタビュー」「シナリオとタスクの説明」「タスク実施」「事後インタビュー」で構成します。これらを2時間以内で終了するようにします。表1に時間配分の目安を示します。
No | 項目 | 概要 | 時間配分 |
---|---|---|---|
1 | 事前説明 | 実施中の注意点などを解説 | 5分 |
2 | 事前インタビュー | 業務経歴やITリテラシを確認 | 10分 |
3 | シナリオとタスクの説明 | 実施してもらうタスクの概要を解説 | 5分 |
4 | タスク実施 | タスクを一つずつ実施(計3~4タスク) | 60~80分 |
5 | 事後インタビュー | 率直な感想などを確認 | 10分 |
ペーパー・プロトタイプの枚数は,すべてのタスクを実施するのに必要な画面の数だけ必要になります。例えば,検証する対象の在庫管理機能の画面が4画面,発注機能の画面が3画面,注文訂正機能の画面が3画面の場合,合計の10画面を印刷しておきます。
さらに,ユーザーごとの操作や記述内容を残しておきたい場合には,ユーザーの人数分用意します。例えば,ユーザーが5人の場合は,10画面×5人分のペーパー・プロトタイプを印刷しておきます。ペーパー・プロトタイプは,モノクロでも構いませんが,色合いも確認したいのであれば,カラーで印刷することを推奨します。