読者です 読者をやめる 読者になる 読者になる

アラタナエンジニアブログ

aratana Engineer's Blog

ユーザーテストは仮説ではなく事実に基づいたデザインのロジック

f:id:s-iiboshi:20150303150852j:plain
周りの評価を恐れ怖気づいて何もしないのは圧倒的衰退。
トム・ケリー&デイヴィッド・ケリーのクリエイティブマインドセットを読んで最早、失敗する恐怖すら失くしたデザイナーの飯干です。

さて昨年からですがプロトタイピングツールが数多く登場しています。日本製のプロトタイピングツールではGoodpatchさんのProttのみしか私が知る限りでは知らないのですが海外製のプロトタイピングツールは数多くあります。

プロトタイピングツールが表立っている理由としてリーン(LEAN)や最近ではデザインスプリント(Design Sprint)などのプロセスが取り上げられているのも理由の一つだと思っています。
プロトタイプの良いところは、いきなり完成品を作り結果を見て改善するのではなく試作品(プロトタイプ)を作成して改善するのでコストを抑えプロダクトの改善が可能になります。
また、早期にプロジェクトメンバーやクライアントと目に見える形で情報の共有が可能になります。

弊社でもEC-CUBEベースの自社パッケージ「カゴラボ」の購入フロー部分のプロトタイプを作成しユーザーテストを実施しました。今回そのユーザーテストについて一部ご紹介します。


ユーザーテストとは

ユーザーにタスクを掲示しプロトタイプや若しくはサイトがある場合はサイトを実際にユーザーに利用してもらい、お客様に提供しているサービスの課題抽出を行う手法です。


ユーザーテストを行った経緯

カゴラボの購入フローの大規模なリファクタリングに伴い、お客様からご要望の多かった一回の購入で複数のお届け先に送ることができる複数配送機能と購入者以外の別のお届け先に送る機能を中心にUIの改修に取り組みました。一見シンプルそうに見えるフロー構成ですが、会員、非会員、個人、法人、定期購入という組み合わせも含まれるので実際は複雑な構成になっています。
f:id:s-iiboshi:20150304094202g:plain

製作者の仮説でUIを改善するのではなく、仮説で作成したUIに対して実際にユーザーが仮説どおりの動きを行うのか検証して事実に基づくUIをデザインする為に今回ユーザーテストを行いました。


なぜユーザーテストを行うのか?

アクセス解析やヒートマップを利用すればサイトの改善に繋がるのでは?
と思う方もいらっしゃると思いますが、勿論アクセス解析やヒートマップでサイトのどのページやどの部分が見られているというのは確認でき目立つ場所はどこなのかといったものまで確認できると思います。

では、例えばインターネットでお歳暮用の商品を購入してくださいとタスク設定を行った場合アクセス解析やヒートマップで、そもそもそのページや特定の箇所が見られていないというのは判断できますが、ユーザーがとった行動の理由までは把握することができません。
「このボタンでそんな事ができると思わなかった。」この場合、存在には気づいていますが、どういうインタラクションがなされるか予測ができていません。これはアクセス解析やヒートマップだけでは判断ができかねる所だと思います。

「そんな事制作している時にわかるのでは?」という方もいらっしゃると思いますが私の経験上、製作者はサイトが完成するまでに何度も画面を見て操作を行うのでユーザーがどう行動するかといった感覚が次第に麻痺し主観が入ります。
だからこそユーザーはどう行動するのかユーザーテストを行い、仮説からのデザインを事実からのデザインへ変える必要があります。


どの様に行うのか?

f:id:s-iiboshi:20150303191420j:plain
ユーザーがどの様な事がきっかけでサービスを利用するに至ったかユーザーのコンテキストもまとめシナリオに落とし込みます。
このシナリオがユーザーテストの要でテストする目的から外れていると当然ながら、この後に行う作業全ての軸がずれた結果になってしまいます。

ユーザーテストで大事なのはユーザーにサービスやUIに触れてもらう事でなく、このシナリオの設計が大事です。
サービスの戦略がこれまでにないユーザーに利用してもらいたいといった場合はこれまでと同じユーザーのシナリオを設計しても戦略から外れたシナリオになります。

シナリオ作成後、ユーザーテストタスクを作成しシナリオにマッチしたテスト被験者をリクルーティングします。
被験者にシナリオとテストタスクを掲示し操作を行ってもらいます。
このテストタスクもまた、あまりに細かく設計してあるとそれどおりにしか操作しないのでテストの意味をなしません。

f:id:s-iiboshi:20150303191954j:plain
テストタスクを作成後、いよいよ被験者にテストシナリオに沿って操作を行っていきます。この時、被験者には思ったことを発言してもらうように思考発話法を用いて操作していただきます。例えばマウスの操作が止まった時など理由がなくて手が止まる事はありません。何らかの理由があるから手が止まるのですが、この時被験者に思った事を発話してもらう事により手を止めた理由を知ることができます。この理由に課題改善の多くのヒントが含まれます。
テスト後、被験者に疑問に思ったことを質問して終わります。


旧購入フローの課題点

現在のカゴラボの購入フローの課題点は下記のものでした。
  1. 1ページに住所や支払方法、配送時間の指定など纏まっていて、それぞれの境界が曖昧
  2. 別のお届け先に送る導線、複数のお届け先に送る導線がわかりにくい
  3. 不要な入力項目がある
  4. エラーの箇所がわかりづらい
  5. スマートフォンコンポーネントが小さくタッチしづらい
f:id:s-iiboshi:20150303164529j:plain
これらの課題点を踏まえ、ワイヤーフレームベースで改善案を作成。
作成後はチームレビューを行い Prototyper を使用してプロトタイプを作成しました。ProttはスマートフォンのUI部分の最終的な大きさなどの確認に用いました。
Prototyperでもできなくはないのですがサクッと確認ができるので。
アニメーションやイベントトリガーなどを含んだ詳細なインタラクションが必要なものには Prototyper、ペーパープロトタイプや大きさなど簡易的な確認にはProttという風に自分は使い分けをしています。


今回のユーザーテストで使用したもの

Prototyperについてはこちらの記事をどうぞ


ユーザーテストの被験者の行動

f:id:s-iiboshi:20150303184058j:plain
実際に操作してもらうと、チーム内で事前にデザインレビューはしていましたが問題点が出てきました。


テスト後、改善し更にテスト

ユーザーテスト後、スマートフォンで「新しい届け先」を追加するUIを以下の様に修正しもう一度テスト。
  • お届け先選択のボタンのラベルを変更
  • シンプルな構成とユーザーに選択肢を迷わせないように購入フローでのお届け先の編集・削除機能を削除
  • お届け先追加後のアコーディオンで展開された状態を変更
f:id:s-iiboshi:20150303181641j:plain



f:id:s-iiboshi:20150303181657j:plain



f:id:s-iiboshi:20150303181709j:plain


改善後テストした結果

特に操作に引っかかることなくテストタスクを完了。
PCは下記の様に改善しました。
画面が小さく確認しづらく申し訳ないです。。大きくするとかなり縦長になるので。ご了承ください。

f:id:s-iiboshi:20150304110307g:plain


f:id:s-iiboshi:20150304103103g:plain


f:id:s-iiboshi:20150304112605g:plain

※画面は現在開発中ですのでリリース時に変更がある可能性があります。


まとめ

チーム内でユーザーテスト前にUIレビューを行っていましたが、結果としてラベルの判断に迷う、どこから届け先を追加するのか迷ったなど課題が出てまいりました。勿論レビューをやっていたからこそユーザーテスト時に主観ではない精度の高いものができました。

「パソコンの操作にあまり詳しくない方でも見やすく分かりやすいデザインにしました」「この位置がクリックされる傾向にあります」などビジュアルデザイン作成後によく添えてある言葉ですが、これらはあくまで経験と仮説です。本当にユーザーが期待通りの操作を行うかはわかりません。

ユーザーテストを行う事で、やってみてどうだったかという仮説が事実になります。つまりユーザーテストは仮説ではなく事実に基づいたデザインのロジックになります。
デザインはどう見えるかという"お化粧"的な事でよく使われますが、どう機能するかが先立たないとサービスが成立しません。

デザインの基本は「観察(オブザベーション)」です。
深澤直人さんの著書『デザインの輪郭』にあるのですが「ゼリーを食べる」ワークショップで観察したところ、スプーンを持って容器の蓋を開け、ゼリーをすくい、口に運ぶという至って単純なプロセスだったが「中身を飛び散らない様に蓋をゆっくりはがす」「はがした蓋をテーブルに上向きに置く」「食べ終わったらごみを容器に詰め込む」といった行動が見られたとあります。この行動結果にデザインのヒントが隠れています。

webも同じでユーザーが、サービスをどう利用するか観察(ユーザーテスト)してデザインすることで優れたエクスペリエンスを作る事に繋がると思います。