1. ホーム
  2. UI
  3. 【UI/UX】ユーザーテストの基礎知識2

【UI/UX】ユーザーテストの基礎知識2

目次

  1. はじめに
  2. 前回の復習
  3. タスクデザイン
  4. タスクデザインを作るときの問題
  5. まとめ

はじめに

今回はWebサイトやWebアプリ、スマホアプリなどを作るときや改善するときによく使うユーザーテストという手法の基礎知識の第2弾をご紹介します。

今回の記事では、ユーザーテストを行うときのタスクデザイン方法とその過程で出てくる問題などをご紹介します。

ちなみに、前回の【UI・UX】ユーザーテストの基礎知識1はこちらで読むことができるので、見逃した方はこちらからどうぞ。

【UI/UX】ユーザーテストの基礎知識1

前回の復習

前回のユーザーテストの基礎知識1では、下記ポイントを説明しました。

  • ユーザーテストはUX調査に置ける手法の1つである
  • 具体的には、サービス/アプリ/Webサイトの代表的なユーザーグループを集め、そのユーザーグループにサービスを使ったタスク(課題)を与え、どのように反応するのかを見るもの
  • ユーザーテストは「サービスのことを知り過ぎている」、または」サービスのニーズについて知らないことが多い」デザイナーにプロダクトを改善するための課題を洗い出すために使えるもの
  • ユーザーテストには大きく要約型と形成型がある
  • テストユーザーを選ぶ際は選択基準を設け、なるべくターゲット層に近づける
  • 選択基準は「専門知識」、「属性」、「行動」、「態度」の4つカテゴリに分かれる

今回は選択基準をもうけ、テストユーザーを選んだ上でどのようなテストを行なっていくのか、タスクデザインについての基礎知識をご紹介します。

タスクデザイン

タスクデザインを行う際は、そもそもこのユーザーテストの目的はなんなのか立ち直って考えます。

まずは、簡単にどういった目的があるのか、どの目的を検証するためのタスクのアイデアをどんどん書き出していきます。

その上で、アイディアの中でユーザーが行うであろう代表的なタスクをいくつか選び、自分でそのいくつかのタスクを行なってみてください。
こちらのいくつかのタスク全部で30−45分くらいかかるとベストです。

この時にユーザータスクを現実的に、そして検証できる形にするのが大事です

また、こういったタスクには正解があるタスクと正解がないタスクがあります。

正解があるタスク

利点
– 検証ができる
– 時間が測れる
– 正解できたのかできていないのか計測できる


2000円以下の子供の本をカートに入れ、いつ郵送されてくるかを調べてください。

正解がないタスク

利点
– ユーザーが自由になった時にどのような制限が出てきたり、好みが出てくるのか、またどのようにサイトをナビゲートして行くのかがみれる


このサイトを自由に使ってみてください

ほとんどの場合、正解のあるタスクを行なった方が具体的な改善点が見つけ出しやすいです

タスクデザインで注意すべき点

タスクデザインを行うときは、以下ポイントに注意すると良いでしょう。

  • タスクが現実的であるか
  • タスクが検証できるか
  • タスクの中にユーザーを誘導する文言はないか
    • (例) 「ショッピングカート」「通常配達」などサイト/システムで使用しているキーワードはユーザーにヒントを与えてしまう
    • タスクの文言はなるべくユーザーにヒントを与えないように中立の言葉をチョイスする
  • タスクセットを作るときは、簡単なタスクからだんだんと難しいタスクになるようにする
    • タスクセットをお願いする場合は、正解があるタスクと正解がないタスクを混ぜて入れても良い
  • タスクを行う時には、必ずユーザーに「Think Aloud」してもらう

Think Aloud

「Think Aloud」とはユーザーがテスト中に何を考えているか話してもらうことです。

実際にユーザーがどういう思考で行動を取っているのか、何がわかりづらいと感じでいるのか、どういったところ迷っているのかなど課題を見つけるためには非常に重要なことなので、ユーザーさんには考えることを話してもらうように最初の説明で伝えましょう。

また、タスクに没頭して、話すことを忘れてしまうユーザーさんには軽くリマインダーなどもしてあげましょう。

タスクデザインの問題点

タスクデザインの際は以下点に注意してください。

システムの変動性

ほどんどのシステムには下記の点で変動する可能性があります

  • データの変動
  • アカウントの変動
  • 設定の変動
  • 状態の(履歴などに応じた)変動

また、その他にも訪問済みのリンクや履歴からのオートコンプリートなどユーザーごとに変動性が出てしまう可能性があるので、タスクデザインを行うときはユーザー環境に気をつけましょう。

理想としては、全てのユーザーに同じデータで同じような経験をしてもらう必要があるので、何回かパイロットテストを行い、履歴やキャッシュを削除するだけで問題ないのか、もしくはエンジニアの協力が必要なのかなど事前に確認しておきましょう。

パイロットテストとは、本番のユーザーテストの前に行われるチェックテストのことです。

パイロットテストは何回か行うことで次のユーザーにも同じようなデータや環境でテストが行われているのか確認できるのはもちろん、どういった調査結果を得ることができるのか、どのようにテストを進めていくべきなのかを最終確認するために使われます。

購入手続き

購入手続きをユーザーに行なってもらう際も、支払いをどうするのか、またカードの情報が漏れないかユーザーに不安を与えないために対策が必要です。

例えば、情報が外部に漏れないよう、サンドボックスシステムを作り上げる。

もしくは、支払い時に困らないようユーザーに支払い方法を事前に伝える。

逆に支払い方法を用意しない場合は、テストの後にオーダーをキャンセルできるようにするなど対策が必要ですのでユーザーテストの前にどのように購入手続きのプロセスを行うのか決めておきましょう。

まとめ

以上、今回はユーザーテストの基礎知識の第2弾についてご紹介しました。
前回の復習を含め、タスクのデザインの仕方、押さえるべきポイント、タスクデザインを行う際の注意点などを主にご紹介しました。

次回はユーザーテストの前や後に行うインタビューやアンケートの作り方についてご紹介します。

投稿者プロフィール

sasakki
アメリカの大学を卒業後、日本、シンガポールでデザイナーとして活動。