ユーザーリサーチとユーザビリティテストによるデジタル製品の評価
ユーザー中心設計の重要な要素は、ターゲット層から募集した実際のユーザーを使ってデジタル製品を評価することです。プロジェクトの具体的な目標、開発段階、複雑さに応じて、さまざまな方法とアプローチがあります。
開発中の製品を評価するためにユーザビリティテストを実施することは、非常に強力なビジネスケースとなります。変更にかかるコストは小さく、設計の選択肢の数は多いため、プロトタイプのユーザー調査は開発プロセスの重要な部分を形成しています。
ユーザー調査の属性
ユーザーテストの実施方法には様々なものがありますが、いずれも以下のような基本的な属性を持っています。
- 現実の世界と同じような作業をさせる。
- ユーザーが、クライアントのターゲット層を何らかの形で代表している。
- ユーザーはできるだけ自然にプロトタイプと対話し、通常think aloudプロトコルを使用してフィードバックを提供します。
- 観察結果は分析され、プロトタイプを繰り返し使用するための推奨事項が示されます。
これらの核となる要素を念頭に置いて、何が異なる方法を分けるのか。
- どこ 研究が行われる
- と なんぼのもんじゃい
- とは何ですか? 研究対象
- どのようなデータ 取り込みたい
ユーザビリティ評価
研究プロセス
この種の定性調査(ユーザビリティ評価)を行うための方法論としては、以下のようなものがある。
- 採用情報です。 募集対象者 クライアントが指定したターゲットプロファイルに対して
- 準備すること。
- A テストスクリプトとディスカッションガイド 参加者とデザインとのインタラクションを促進するためにデザインされた
- A ファシリティ 研究を実施するために
- 装置 セッションを記録するためのセットアップと参加者が使用するデバイス(タブレット、スマートフォン、PCなど)
- 研究セッションの様子。
- 熟練 モデレーション 各セッションの
- 観察・記録 問題点
- 分析・レポート
参加人数とセッションの長さ
デザインテストの段階では、スマートフォン、タブレット、PCのすべてのプラットフォームでユーザビリティ評価を実施するのが普通です。しかし、私たちの経験では、各プラットフォームで5回実施する必要はありません。なぜなら、前回の実施で重大な問題を洗い出しているからです。
ほとんどの場合、私たちは 2日間で10回(約60分)の研究会を搭載しています。 スプリット・プラットフォーム:
- スマートフォン=4名
- PC=4名
- タブレット=4名
一般的に、タブレット端末はスマートフォンやPCの調査結果によって情報を得ることができますが、私たちは、ブレークポイントや重要な情報を下に表示することで、明らかな問題を見落とさないように、2つのセッションを実行したいと考えています。
研究施設と視聴
研究施設では 屏風鑑賞 デザインチームやステークホルダーが、参加者がどのようにデザインに取り組んでいるかを直接見ることができるようにするためです。モデレーターと同じ場所で見ることができるため、参加者同士の交流も深まります。 セッションの間に観察したことを話し合い、アップデートや変更を計画し始める機会。.
また、研究施設の視聴室は防音であることが多いため、設計チームや関係者が協力して、見ているものを議論する機会にもなります。
しかし、研究設備にはコストがかかり または、ほぼすべての場所で研究を行うことができます。 会議室、参加者の自宅、クライアントのオフィスなどで。インターネットを通じてセッションを配信することができますので ライブビューイングリモート が可能です。
しかし、そこには 制約 というものです。
- 端末の画面だけが見え、参加者の表情は見えない
- インターネットでの長時間の動画視聴は、動画の帯域が重いため、少し不安定になることがあります
- 画面解像度により、細かい部分が見づらい場合があります
また、高解像度のセッションビデオを録画し、Dropboxの共有フォルダーにアップロードすることもできます。帯域が許す限り、私たちはこれらをアップロードし、すぐにリンクを共有することで、約1時間の経過時間で見ることができます。
試験装置
ユーザー調査セッションを実施するために必要な技術はすべて提供します。
これには
- があります。 テストラップトップ ピクチャー・イン・ピクチャーを記録するための専門ソフトを搭載している。
- ハイビジョン映像 参加者が使用している画面と表情の両方を表示します。
- があります。 ソフトウェア スマートフォンやタブレット端末を接続し、画面を録画できるようにするために必要です。
モバイル収録に使用するセットアップは、スマートフォンに電源ケーブルを接続するだけのハードウェアとソフトウェア構成を採用しています。参加者は、オーバーヘッドカメラやクレードルなどのアタッチメントや、デバイスを机の上に固定することなく、自然にスマートフォンを手に取り、操作することができます。
iOSやAndroidのスマートフォン、タブレット、Microsoft PCなど、テスト用に用意したさまざまなデバイスがあります。必要であれば、お客様のデバイスを使用することもできますし、通常、簡単に接続することができます。
テストスクリプト、モデレーション、分析、レポート作成
すべてのプロジェクトは、独立した評価と賞を受けた経験豊富なUXコンサルタントのチームによって運営されています。 認定プラクティショナー のステータスがあります。当社のコンサルタントは全員、最低5年の経験、必要な資格、そしてこの種のデザイン・リサーチを実行する能力を備えています。
テストスクリプト
クライアントと話し合いながら、UXコンサルタントが テストスクリプトを作成する。テストスクリプトには、参加者の相互作用を導くタスクとシナリオが含まれている。という質問と、リサーチで解決してほしいことがあれば教えてください。
の中で文書化しています。 研究計画には、調査に関するその他のすべての詳細が含まれ、反復とサインオフのためにあなたと共有されます。典型的なセッションの構成は、次のようなものです。
- 開始前
- 使用状況、現在の行動、研究対象への態度についてのディスカッション。
- タスク
- 評価対象となる主要なジャーニー、インタラクション、フィーチャー、機能などを網羅したタスクを作成します。
- 司会者が確実に答えなければならないタスクに関連する質問。
- クロージングインタビュー
- 体験談を交えたディスカッション
中庸
当社のコンサルタントは、この種の調査を実施した長年の経験を有しており、特に要望がない限り、この種の調査を実施します。 当社のモデレーションに対する考え方 は以下の通りです。
- 参加者に口頭で課題を伝え、形式的にならないようにすること
- ユーザーが自由にプロトタイプと対話できるようにし、誘導しないこと
- ユーザーが躊躇していたり、混乱しているときに、タスクの勢いを失ったり、ユーザーの行動から学習できる可能性がない場合にのみ、中断する。
- 必要であれば、タスクやサブタスクの後に質問すること
また、他のお客様から、より正式なモデレーションアプローチの運用を求められることもあり、必要に応じてスタイルを変更することもあります。
ユーザーテストセッションの間、モデレーターはセッションを観察し、後で分析に使用するためのメモを作成します。これらは、後で参照したり、セッションのビデオを見直したりできるように、タイムスタンプ付きのメモにすることもあります。
分析・レポート
調査後、分析を行い、報告書が必要な場合は作成に取り掛かります。レポート作成が必要な場合は、ユーザーエクスペリエンスのベストプラクティスであるレポート作成基準に従います。
を活用しています。 トラフィックライト報告スキーム まで オブザベーションを分類し、重大性のレートを割り当てる を以下のように設定しました。
トラフィック・ライト・レポーティング・スキーム
CASE STUDY
あるホテルチェーンのジェネレーティブ・スタディでは、リデザインに先立ち、既存のアプリをレビューしました。ビジネスユーザー、コンシューマーユーザー、グループ、個人など、あらゆるユーザー層から参加者を募りました。閲覧や検索だけでなく、決済やアカウント管理、メールメッセージ、ロイヤリティスキームも厳密にテストされました。また、競合アプリの閲覧も行い、ユーザーが好む部分を特定し、再設計の参考としました。
今回の調査は、クライアントが直接フィードバックを聞きたいということで、研究施設で実施されましたが、この段階の調査は、デザイン変更前の保険比較会社のように、ユーザーの自宅で行われることも珍しくありませんし、クライアントのオフィスや会議室でも行われます。一般的には、コスト、数日間の外出が可能かどうか、ユーザーの所在地などを考慮して決定されることが多いようです。セッションのビデオは常に提供されます(弊社から無料で提供)ので、参加できなくても何が起こったかを確認することができます。
プロセス設計試験
研究のための準備
プロセステストのアプローチは、ユーザビリティテストのアプローチと非常に似ており、核となる要素が存在します。
- テスト資産
- 参加者の様子
- 調査場所
- 準備、モデレーション、分析、報告。
最大の 相違点 プロセステストでは、テスト資産を作成する必要があり、その報告は通常、プロセス設計の修正という形で行われます。
プロセスデザインは、ユーザージャーニーマップ、ユースケースワークフロー、プロセスフロー図などとして納品することができます。これらのアセットは、プロセスがどのように機能するか、可能なインタラクション、エラーパス、代替フロー、成功基準などを説明します。しかし、このままではユーザーを混乱させるだけなので、このような形でユーザーの目の前に置くことはできません。
プロセスカード。
私たちは、プロセスにおけるさまざまな属性を表す色分けされたプロセスカードを開発するというアプローチを取っています。
最近のプロジェクトでは、次のようなカードの種類がありました。
この段階だけでも、ユーザーテストを実施する前に修正できる問題やプロセスの抜けが投げかけられることがよくあります。そのため、この段階では、プロジェクトに追加の時間を設け、数回の の繰り返しです。
テストの実施
研究施設の視聴室からユーザビリティテストを観察したことがある人なら、プロセステストで何が起こるか、すでにかなり理解していることでしょう。参加者は、ターゲットユーザーのプロファイル(ペルソナ)に照らして募集され、シニアUXコンサルタントが司会を務める45~60分のセッションに各自で参加します。参加者が着席し、冒頭の質問でリラックスした雰囲気になったところで、プロセステストを開始します。
プロセスカードの各セットは、ユーザーの旅またはサブジャーニーを表し、セットの最初のカードは、ユーザーストーリーです。参加者は、ユーザーストーリーのカードを手渡され、それを読むように指示されます。カードには次のようなことが書かれています。
- オンラインバンクの口座にログインしたい
- 自分の口座を見るためにbank.co.ukを検索し、クリックしてログイン画面を表示するのです。
- ログオン情報を覚えていないため、Webサイトからサポートに問い合わせるよう案内された場合
どのように進めていくのですか?
ユーザーはカード上にいくつかの選択肢を提示され、それらは関連するカードを経由して異なる経路でプロセスを進めることになります。
私たちの研究のゴールは、そのプロセスがユーザーの望む自然なインタラクションをサポートしているかどうかを理解することです.彼らの行動を観察し、彼らの言語化された思考プロセスやフィードバックを聞くことで、我々はプロセスを改善し、最適化することができます。
調査結果の共有
プロセステストから得られた知見を共有するための最良の方法は 修正されたプロセスマップまたはフロー を主な成果物としています。A ほうこく は、プロセスがなぜそのように変化したのか、変更されたのかを説明するものです。各プロセスの各ステップを取り上げ、何がうまくいき、何がうまくいかなかったのか、どのように変更または適応する必要があるのかを明らかにします。
これらの成果物は、ユーザーの旅とプロセスをサポートするために、ワイヤーフレームやプロトタイプをどのようにデザインすべきかを決定します。
比較ユーザビリティテスト
カウンターバランシング
複数のプロトタイプの評価が偏らないようにするために、カウンターバランシングと呼ばれる方法を用いています。各ユーザーが同じ順番でプロトタイプと対話するのではなく、プロトタイプa、プロトタイプb、プロトタイプcというように順番を入れ替え、すべてのプロトタイプが同じ回数、同じ順番で対話するようにします。
以下は、あるプロジェクトで実際に行われたテストプロトコルです。 プロトタイプ3種 (2つはスマートフォンのみ)と3つのプラットフォームで展開しています。
日/参加者 | デスクトップ | タブレット | スマートフォン | |||||
1日目 | 対1 | 対2 | 対3 | 対1 | 対2 | 対3 | 対1 | 対2 |
1 | 第1回 | 第2回 | 3位 | 6日 | 5位 | 第4 | ||
2 | 第2回 | 3位 | 第1回 | 第4 | 6日 | 5位 | ||
3 | 3位 | 第1回 | 第2回 | 5位 | 第4 | 6日 | ||
4 | 第1回 | 第2回 | 3位 | 5位 | 第4 | |||
5 | 第2回 | 3位 | 第1回 | 5位 | 第4 | |||
6 | 3位 | 第1回 | 第2回 | 第4 | 5位 | |||
2日目 | 対1 | 対2 | 対3 | 対1 | 対2 | 対3 | 対1 | 対2 |
1 | 5位 | 第4 | 3位 | 第1回 | 第2回 | |||
2 | 3位 | 5位 | 第4 | 第2回 | 第1回 | |||
3 | 第4 | 3位 | 5位 | 第1回 | 第2回 | |||
4 | 第1回 | 第2回 | 3位 | 5位 | 第4 | 3位 | ||
5 | 第1回 | 第2回 | 3位 | 5位 | 第4 | |||
6 | 5位 | 第4 | 3位 | 第1回 | 第2回 |
テストプロトコル例
この種のテストは、モデレーターがよく整理され、よいメモをとっていることに依存します。モデレーターに加えて、バージョンと順序を追跡するためのメモ係を置くことは非常に有用です。
ベンチマーキング評価
評価の実施
があります。 テストセットアップ は、プロトタイプと本番で使用するタスクとシナリオが同じであるため、非常にシンプルです。また、偏りをなくすためにカウンターバランス方式を採用し、本番とプロトタイプを同じ回数ずつ見ていきます。
参加者は、それぞれと対話しながら、次々と同じタスクを試み、提供します。 バーバルフィードバック+観察行動.
比較の基準はよく考え、それに基づいてタスクとテストプロトコルを計画する必要があります。参加者は常にプロトタイプから本番への移行を行うことができないため、彼らのフィードバックが不当な判断に基づく可能性があります。
しっかり準備していれば、そんなことは無視して、次のような重要な部分に集中することができるのです。
- 相互作用
- ユーザージャーニー
- 機能の特徴
これらをもとに ベンチマークと採点・報告フォーマット ということで合意しました。
CASE STUDY
あるホテルのクライアントが新しいアプリを開発しており、開発中のプロトタイプアプリと既存のライブアプリのベンチマーク評価を依頼されました。6人の参加者が1対2の割合でプロトタイプとライブアプリを操作するように、カウンターバランス方式を採用しました。成果物として、実機とプロトタイプの長所と短所を比較した詳細なベンチマークが提出されました。
プロジェクトがおありですか?