2018年5月9日

デザイン

【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弾についてご紹介しました。
前回の復習を含め、タスクのデザインの仕方、押さえるべきポイント、タスクデザインを行う際の注意点などを主にご紹介しました。

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

UIのお仕事に関するご相談

Bageleeの運営会社、palanではUIに関するお仕事のご相談を無料で承っております。
zoomなどのオンラインミーティング、お電話、貴社への訪問、いずれも可能です。
ぜひお気軽にご相談ください。

無料相談フォームへ

0

0

AUTHOR

sasakki デザイナー

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

アプリでもっと便利に!気になる記事をチェック!

記事のお気に入り登録やランキングが表示される昨日に対応!毎日の情報収集や調べ物にもっと身近なメディアになりました。

簡単に自分で作れるWebAR

「palanAR」はオンラインで簡単に作れるWebAR作成ツールです。WebARとはアプリを使用せずに、Webサイト上でARを体験できる新しい技術です。

palanARへ
palanar

palanはWebARの開発を
行っています

弊社では企画からサービスの公開終了まで一緒に関わらせていただきます。 企画からシステム開発、3DCG、デザインまで一貫して承ります。

webar_waterpark

palanでは一緒に働く仲間を募集しています

正社員や業務委託、アルバイトやインターンなど雇用形態にこだわらず、
ベテランの方から業界未経験の方まで様々なかたのお力をお借りしたいと考えております。

話を聞いてみたい

運営メンバー

eishis

Eishi Saito 総務

SIerやスタートアップ、フリーランスを経て2016年11月にeishis, Inc.を設立。 マーケター・ディレクター・エンジニアなど何でも屋。 COBOLからReactまで色んなことやります。

sasakki デザイナー

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

しまだ

しまだ デザイナー

WebAR/VRのデザインと3DCG制作がメインです。 肩書きは「アニメ案件に関わりたいデザイナー」。

Miu マーケター

ドイツでWEBマーケティングしています。

しんのき エンジニア

主に React Native を使ったアプリ開発と AWS や Firebase を使ったサーバーレスアーキテクチャを担当しています。元々はインフラとかPHPをやっていました。

yamakawa

やまかわたかし デザイナー

フロントエンドデザイナー。デザインからHTML / CSS、JSの実装を担当しています。最近はReact NativeやReact360をよく触っています。

furuya エンジニア

サーバーサイド、フロントエンド、Unityと色々手を出してる雑食系エンジニア。ReactNativeが最近のマイブーム。

Sayaka Osanai デザイナー

Sketchだいすきプロダクトデザイナー。シンプルだけどちょっとかわいいデザインが得意。 好きな食べものは生ハムとお寿司とカレーです。

はらた

はらた エンジニア

サーバーサイドエンジニア Ruby on Railsを使った開発を行なっています

うえまつゆい エンジニア

サーバーサイドエンジニアからフロントエンドエンジニアになりました。主にReact Nativeでのアプリ開発をしています。

kobori

こぼり ともろう エンジニア

サーバーサイドエンジニア。SIerを経て2019年7月に入社。日々学習しながらRuby on Railsを使った開発を行っています。

sasai

ささい エンジニア

フロントエンドエンジニア WebGLとReactが強みと言えるように頑張ってます。

damien

Damien

WebAR/VRを中心に企画やディレクションやエンジニアもちょっとやっています。森に住んでいます。

デザイナーゲスト

ゲスト デザイナー

CONTACT PAGE TOP