こんにちは、デザイナーのすーみんです。

前回のブログでユーザー視点に立ったWebデザインの構築フローについてご紹介しましたが、デザインを作るときにいくら仮説立ててロジック詰めて作っても、ユーザーが実際使った時ちゃんと機能してるかどうか、ユーザーの利用事実に是非を問うことってとても重要ですよね。そこで今回は、前回からの続きでデザインの検証の一つの手法である「ユーザーテスト(ユーザビリティテスト)」についてやる意味や必要なもの、進行フロー、弊社でのトライアンドエラーの結果などを共有できたらなと思います。

ちなみに、先日近隣のある企業さんとデザイナー同士で勉強会を行いまして、その時のLTの内容を更に文章で細かく補足したのがこのブログとなります。スライドにもまとめてあるので、もし良ければそちらもご覧ください:)

ユーザーテストとは

ユーザーテストとは、モックや実際のサイトをターゲットユーザーの属性に近い人に実際に触ってもらい、そこからユーザーニーズや課題を抽出するテストのことです。ユーザーテストとは一体何か、文章で分かりやすく紹介しているサイトがありましたので、もし良ければ以下のリンク先サイトもご参照ください。

ユーザビリティテスト(U-site) 
第9回 ユーザビリティテスト:ソフトウェアテスト基本テクニック|gihyo.jp … 技術評論社
【実践編】ユーザー心理とサイト課題を明らかに。ユーザーテストの進め方と観察のポイント | UIDEAL

何故ユーザーテストなのか

恐らく今この記事を読んでいる皆様にとって、Google Analyticsなどのアクセス解析ツールを使って定量的にサイト利用データを解析することって「当たり前」のことなのではないかなと思います。

弊社が運営するApplivでももちろんアクセス解析ツールを使い、社長を始め事業責任者、エンジニア、デザイナーそれぞれが各指標を常に参照できる状態です。また、グロースハッカー的役割の社員主導で週次でアクセス解析から取得する数値を元にサイト改善計画を立てて実行しています。

定量的データだけじゃ分からないユーザー行動の事実をあぶり出すのがユーザーテスト

例えばApplivでも、あるページの直帰率が高いという課題点はアクセス解析からとれたが、一体その原因はなんだろう?といったことが多々あります。そんな時に登場するのがユーザーテストです。以下のようなときにユーザーテストを計画、実行しています。

  • アクセス解析から発見した課題点の原因を探る
  • まだリリースしていないサイトのデザインが、ターゲットユーザーの行動から大きく外れていないか確かめる

デザインを検証する手段は、アクセス解析、A/Bテストを始め様々ありますが、恐らくほぼ全ての方が取り入れている定量的手段であるアクセス解析での検証と、定性的手段であるユーザーテストを組み合わせると大きな力を発揮します。

では具体的にユーザーテストが何か、どのように進めるかを見て行きましょう!

デザインフローとユーザーテストの取り入れ方

当社ではユーザーテストを目的に併せて2つの分類に分けています。

1.サイトコンセプト、ユーザーシナリオの妥当性を確かめるためのユーザーテスト(以下、コンセプト検証と呼びます)
2.パーツ、遷移、レイアウト、ワーディングといったUIを検証するためのユーザーテスト(以下、UI検証と呼びます)

コンセプト検証でユーザーのニーズやそもそもの方向性が大きくターゲットユーザーからずれていないかを確かめる場合と、UI検証で実際のサイトや画面プロトタイプを使ってもらってUIに不備がないかを確かめる場合とでは、必要な準備からテスト実施時の質問の投げかけ方まで変わってきます。

新規にサイトを作る場合:コンセプト検証

新規サイト作成

▲サイトコンセプト策定→ユーザーシナリオ策定→ワイヤーフレーム作成→コンセプト検証のためのユーザーテスト実施→課題点抽出→ビジュアルデザイン、マークアップ、実装へ

コンセプト検証のためのユーザーテストは、サイトを作る上でのゴールやターゲットユーザーを定めたサイトコンセプト、ターゲットユーザーがどのようなステップを踏んでサイト内で目的達成するかの道順であるユーザーシナリオ、この2つが仮説として妥当かどうかを確かめるために行います。またそれと同時に制作側が気づいていないユーザーのニーズやインサイトを抽出するためにも有効です。

コンセプト検証のためのユーザーテストで用意するもの

弊社でコンセプト検証のためのユーザーテストを行う場合は、実装前に果たしてこれで方向性として正しいかということを検証するため、実際のサイトを実装するより遥かに簡単にテスト用モックアップを作ることを重視しています。そのため使用するものは、実際のサイトではなく以下のようなものであることがほとんどです。

・ペーパープロトタイプ
・ワイヤーフレームを実寸大に印刷したもの(Cacooで作ったものを使用することが多いです。)
・ワイヤーフレームをFlintoやProttといったツールで配置し作成したプロトタイプ

paperprot

▲ペーパープロトタイプではラフを元にその方向性で本当に正しいかを確かめます。この写真では結構ちゃんと作ってありますが、もっと手書きとかでもいいくらい。

実装が完了したサイトのUIを確かめたい場合や、既存のサイトを改修する場合:UI検証

既存サイト改修

▲(アクセス解析などで課題点発見)→サイトコンセプト確認→ユーザーシナリオ確認→(必要ならばプロトタイプ作成)→UI検証のためのユーザーテスト→課題点抽出→ビジュアルデザイン、マークアップ、実装へ

UI検証のためのユーザーテストは、ユーザーがサイト内で目的達成をするために必要な導線にきちんと気付くか、導線は正しく設計されているか、ボタンの大きさや配置は適切か、ワーディングは正しいか、などといったUI全般を検証するために行います。

UI検証のためのユーザーテストで用意するもの

UI検証でとにかく大事なのはリアルであることです。検証したいサイトを利用するシーンでPCがメインならPCで、iOSアプリの検証をしたいのであればiOSの端末サイズに最適化されたプロトタイプを用意することなど、ユーザーがリアルな環境でこのサイトを触るときを出来るだけ再現します。既存のサイトの改修や、既に実装したもののUIのブラッシュアップのために行うため、テストでは既存のサイトを利用することがほとんどです。

・既存のサイト(アプリ)
・仕上がりイメージをFlintoやProttといったツールで配置し作成したプロトタイプ

私の場合、最近はiOSアプリのデザインをメインに行なっているのですが、UIの実装にエンジニア工数がかかる場合は2つ目に挙げたように先に仕上がりイメージをプロトタイプとして使用し、UI検証のテストを行います。

flinto

▲私がプロジェクトで使っているプロトタイプツール「Flinto」の一覧画面です。この一覧画面とiPhone側のプロトタイプとの同期が一瞬で済むことが何よりも良い!今のところ不満点は見当たりません。

テストの準備から実行まで

被験者選定

サイトの種類やターゲットユーザー層にもよりますが、きちんとテストを行うときは5名程度の調査を実施します。出来るだけターゲットユーザーに当てはまる人をアンケートによって社内や関係者から選ぶか、そういったユーザーテスト被験者の派遣を行っている会社さんにお願いすることもあります。(この場合は有料)

テストの実施

試したいシナリオの数に大きく影響されるのですが、弊社では1回のテストで2〜3のシナリオを試すことが多く、時間で言うと簡易なもので20分〜30分、ガッツリやる場合で1時間程度の時間をとりテストを実施しています。またその日のテストが終わった段階でメモから課題点を抽出し改善優先度をつける時間もテスト終了直後にまとめて1時間とっています。

テスト運営側のメンバーとしては、進行役1人、メモ役1人はこれまでの経験上絶対に必要です。

実際にテストをやってみよう!

ここではUI改善のテスト全体の流れにフォーカスして書いていこうと思います。テスト全体の流れとしては、【1.ユーザーテスト説明→2.事前ヒアリング→3.タスク設定→4.振り返り】となります。

1.ユーザーテストの説明

被験者には、いくつかテストをするにあたっての注意事項の説明を行います。

・触っていて思ったことを出来る限り全て口にしてもらう(思考発話)
ex.「この文字の部分が次のページにいくリンクかな?(被験者該当箇所クリックするがそこはリンクじゃない)あれ、クリック出来ない。。」等
・UIのことで質問をしてもテスト進行上答えられないこともあると説明

また、リリース前のサービスである場合はNDAをこのタイミングで結んでいます。

2.事前ヒアリング

その後のタスク設定時に、より普段のサイト利用時のリアルな状態に近づけるため、アイスブレイクも兼ねて事前ヒアリングを10分ほど行います。(ここで緊張をほぐすコミュ力大事です。笑)

■弊社が開発運営しているアプリプラットフォームサイト「Appliv」でゲームアプリを複数比較した上でDLするための導線を検証する場合

・ゲームと言っても色々なゲームがありますが、どういったタイプのゲームが一番お好きですか?
・一番これまででハマったゲームを教えて下さい!
・最近一番よく遊ぶゲームって何ですか?
・次何かゲームやるとしたらどんなゲームやりたいですか? 等

ここで被験者が例えば「『LINE:ディズニー ツムツム』にハマりましたね〜、次もツムツムみたいな友達と競うタイプのゲームやりたいです」と答えた場合、その後のテストでのシミュレーションはライトな友達と競うゲームアプリを探す、というタスクを被験者に課すことになります。

3.条件設定とタスク設定

ユーザーテストで一番の肝のうちの1つがこの条件設定とタスク設定です。ヒアリングやユーザーシナリオを元に、被験者がサイトを触る条件を設定した後、タスクを行っていただきます。

ではここで、簡単なテストの例を元に流れを見て行きましょう。

■こちらが検証したいこと:検索流入したユーザーが、Appliv上で複数のアプリを比較の上、アプリをインストールするのに適したUIになっているか
■ターゲットユーザー:スマートフォンアプリ用のゲームで遊ぶことが多く、アプリのインストールに抵抗がない。アプリを探す際はGoogleで検索する。
■条件設定:あるゲームアプリはかなりのヘビーユーザーだが、そろそろ違うアプリでも遊びたい。特にパズルゲームを探している。

タスク設定1:「いつものようにSafariを開いてパズルゲームを探してみてください。」

①被験者が設定したタスクに対して、仮説と大きなズレもなく、問題なくタスク完了した場合

タスク完了後に遷移のポイントやこちらが気付いて欲しかったUIなど、それぞれのキーポイントで何に気付いたか、どのように思ったかをヒアリングしましょう。その際テスト進行者は、被験者がタスクを実行している間の思考発話を手がかりに、一体どこでつまずきそうだったか等質問していきます。

②被験者が途中で仮説として立てたユーザーシナリオから大きくずれた行動をとったり、離脱した場合

例1-1 )こちらは検索結果の上位に表示されているApplivのサイトからアプリを探してもらう前提で検証したいが、ユーザーがApplivにたどり着かなかった
例2-1 )Applivに辿り着いたがパズルゲームを比較せず最初に見た1つで決定してしまった

ユーザーシナリオから大きくずれた段階で、進行役は一旦テストをストップする必要があります。そのストップしたタイミングまでの内容に関してどう思ったか、キーとなるUIに気付いたかどうかをヒアリングしましょう。ヒアリングが済んだら、条件設定をし直します。

例えば上記2つの例であれば、

例1-2 )「それでは今回はApplivというサイトにGoogleの検索結果からランディングし、このサイト内でアプリを探すという前提でやってみましょう。」
例2-2)「先ほど見つけた○○というアプリの他にもう一つ気になるものがあったとして、この2つを比較するというていでもう一度見てみましょう」

等、条件設定をし直します。でないといつまでたってもこちらが検証したいことが出来ないです。この条件設定とタスクの振り直しが一番テスト進行の上で難しいと感じるポイントです。

4.ヒアリングのポイント

ヒアリングのポイント

テスト全体を通してヒアリングは、【行動の事実の確認→感情、理由を聞く】という順番で行います。

ヴォラーレで使っているユーザーテスト関連機器や必要物など

マストで必要なもの

  • サイト利用者の設定(サイトコンセプト)
  • ユーザー行動の仮説(ユーザーシナリオ)※弊社ではこの2つを1つのGoogle Docsで管理し、ユーザーテストの結果も同じシートにリアルタイムで記入していきます。
  • 被験者に触ってもらうためのプロトタイプか、実際のサイト

あるといいもの

  • 記録用ビデオカメラ(ただ結構メモで取りきれるので見返したことはほぼ無いですね…/後述の別の理由でビデオカメラを使っています)

一般的なユーザーテストに必要とは思わないが、使っていて重宝しているもの

  • アイトラッキングシステム
  • インカム/マイク
  • ユーザーテストルーム/モニタールーム

今後より一層UI改善に力を入れていこうと昨年決定、そこでオフィス移転のタイミングで上記のようなセットを購入/用意した背景があります。特にユーザーテストルームではアイトラッキングシステムが利用できるPCがあったり、そこで行うテストの様子はビデオカメラを通じてモニタールームとリアルタイムに共有が出来ます。(社長やクライアント企業様がテストを見るために使います)

失敗談

入社してからこれまで数えられないほどテストを行いましたが、正直に言って最初の頃は、時間をかけて準備をしているのに検証したいことがひとつも検証できずに終わることがほとんどでした…!特に大きなミスだったのは以下の2点です。逆に言うとこの2点を改善出来てからはテストで課題がきちんと抽出出来るようになったと実感しています。

1.自分が検証したいことに合わせたテスト進行を意識する

サイトコンセプトを検証したいのか、UIを検証したいのか。それによって質問の深堀り具合が全く変わってきます。

2.(UI検証のためのテストでは)どんな小さなテストでもユーザーシナリオを用意する

テストでは仮説(ユーザーシナリオ)と実際のターゲットユーザーの行動がいかにずれているかを検証します。仮説がないと何とずれているのか分からず、抽出出来たと思った課題も実際何が課題なのか曖昧になります。

終わりに

思いがけず長くなってしまいましたが…!ユーザーテストって正直やるの結構たいへんなんですよね笑、まず準備に時間がかかるし、終わった後の課題抽出なども必要です。それでも必ずサービスデザインをするデザイナーがすべきだと私が思うのは、テストってやったらやっただけユーザーの反応や仮説検証の結果が返ってくるためです。

ヴォラーレ株式会社ではユーザーテストに取り組んでみたいという意欲を持ったデザイナーや、自らのデザインを常に検証し研鑽していく姿勢をもったデザイナーを大募集しています。是非一緒に良いサービスを作りましょう!まずは話だけでも聞きたい、という方、是非こちらのランチ応募フォームからご応募ください。デザイナー(志望)の方だと、きっと私がランチご一緒することになると思います!笑
採用サイトはこちらWantedlyでのデザイナー募集ページはこちらです。

最後まで読んでいただきありがとうございました!