社内でユーザービリティテストを実施してみた

私が関わったこれまでのプロジェクトでは「デザイン・UI」は、要求された仕様通りの機能を実装する際に 「レイアウト・ボタン・メッセージ等に不備に不足はないか、不具合は起きないか」という視点しか持っていませんでした。 本来必要とされる以下のようなことを、判断軸として持っておらず、しっかりと検証することができていませんでした。

• 直感でわかる使い易さ
• 不快感のない操作性
• やりたいことを最短で行える

ユーザービリティというキーワードに対しても 「ユーザビリティ = デザイン設計の一部」 のイメージを持っており 、Webデザインの担当者に任せっきりにしてしまっていました。

PLAN-BではプロダクトマネージャーとしてCast Me!に携わることになり、新機能のリリース前などのタイミングで、本来のユーザビリティを確認するために、何度かユーザービリティテストを実施してみました。
その結果得たことや改善ポイント、反省点・失敗だと感じたことについて、書籍・ブログなどから改めてインプットした知識をもとにふりかえりました。

そもそもユーザビリティって？

私の持っていた「ユーザビリティ」というキーワードに対してのイメージは

• ユーザーが使いやすい
• レイアウトやボタンのデザインがわかりやすくデザインされたUI

というレベルでしたが 、実は国際規格のISO9241-11に定義がありました。

特定の利用状況において、特定のユーザによって、ある製品が、指定された目標を達成するために用いられる際の 有効さ、効率、ユーザの満足度の度合い

これらを満たし、ユーザーが満足できている状態が「ユーザービリティが高い（ユーザブル）」 と言えるようです。

個人的には以下のように解釈しました。 

• 提供する商品やサービスにおいて、利用を想定しているユーザーがやりたいこと（目的）を達成する上で
• サービスが用意したUIによって、視覚的・直感的にサービスを利用する事ができ、その過程において
• ユーザーは、迷わず・ストレスフリーな状態で目的を達成することができる

「誰に向けたサービス」「どんな状況・目的で利用されるのか」サービスを作るメンバーの認識が揃っていることがとても重要です。ユーザビリティの定義を満たせている(ユーザブル)かどうか、サービス関係者を交えてしっかり検証していく必要がありそうです。

ユーザービリティの定義はなんとなくわかりました。では実際ユーザーが満足できているか、ユーザービリティの評価・判断はどうするのか？となるのですが、評価の方法として有名なものは以下のような手法があります。

• ヒューリスティック評価
  • 評価対象のプロダクトが犯している「ルール違反」を探索する（ヒューリスティック評価の専門家による）
• 認知的ウォークスルー
  • ユーザビリティ専門家が、ターゲットユーザーになったつもりで評価対象のサイトを閲覧/操作してみることによって、様々な問題点を指摘する（ユーザビリティ専門家による評価）
• ユーザービリティテスト
  • ユーザー（WebサービスならWebサイト利用者）に、実際に評価対象のWebサイト（またはプロトタイプ）を使ってもらい、その様子を観察することで、様々な問題点を発見する

それぞれ一長一短があり、環境や状況に応じて選択する必要があります。

今回まずはユーザビリティの検証を始めてみるというフェーズなので、「ヒューリスティック評価」「認知的ウォークスルー」などの専門家が必要な手法よりも、まずはユーザービリティテストから試してみる判断をしました。

社内でユーザビリティテストを実施

Cast Me! では、新機能をリリースする前に「致命的な使いにくさがないか」「ゴール（目的）を達成できないような構造になっていないか」などを確認するために、以下の流れでユーザービリティテストを実施しました。 (Cast Me! は企業向けとインフルエンサー向けのコンテンツや機能があるサービスです)

1. 企業向けコンテンツのテストは社内のインフルエンサーマーケティング事業を行っている部門に依頼
2. インフルエンサー向けテストはインフルエンサーマーケティング事業以外の社員に依頼
3. シナリオを作成し、インターネットを介して遠隔ユーザービリティテストを実施
4. 操作方法や機能説明などの事前説明をせず、サービスの一連の動きを実際に進めてもらいその様子を確認（録画も実施）
5. 作業を観察する中で、迷いがあったり詰まったりした箇所・その時の表情や発言を記録
6. 各ページ・場所のどこで手間取ったか、迷っていたかも合わせて記録しておく
7. テスト終了後、操作感についてフィードバックをもらう（良かった・悪かったと感じた部分も）
8. 全員のテスト終了後、関係者で各ページ・場所ごとの結果を整理
9. 結果を元にプロダクトチーム内で改善箇所について議論
10. 改善が必要だと判断した場合は改善開発を実施

実施前に考え方や方針を設計しすりあわせ

実際にユーザービリティテストを実施してみて、今後改善すべきUI、機能などのサービスとしての使い勝手だけでなく、ユーザビリティテスト自体についても、改善すべき多くの課題に気づくことができました。

例えば…

• 実施タイミングの調整が難しい
  • ユーザビリティテストの実施と改善を、開発スケジュールに事前に組み込んでおく必要がある
• 明確なペルソナを立てられておらず、プロダクトチーム内で認識のずれがあったことがわかった
• 実施対象1人1人の意見に強く影響を受けすぎた（本質的な意見を見極めることが大切）
• リモートでの実施となったが、画面越しでは考えや感情を読み取りづらい
  • 実施の容易さとトレードオフではある
• 実施後の改善判断に関して、改善指標の抽出ができていなかった
  • 「応募率がxx%上がるはず」など、自分たちの仮説の確かさを後ほど検証するために、ざっくりとしたものでも仮説をたてるべきだった

知識や経験不足の中ではあったものの、実施したことでサービス自体や自分たちの進め方について、多くの課題や改善点に気づくことができました。また、見えていなかったユーザーの視点・気持ちの発見にも繋がり非常に実りある結果となりました。

今後ユーザービリティテストを実施するときに気をつけたいこと

実際にユーザビリティテストをやった後、書籍やWebの記事で得たことを踏まえて考えると、そもそもユーザービリティテスト以前の課題に気づきました。プロダクトの立ち上げ時に、UX設計をしっかり行い、対象となるペルソナの設定、何のためにどのタイミングでユーザビリティテストを実施するかの計画作りなど、プロダクトマネジメント全体を再考するきっかけになりました。

ユーザビリティテストを実施する前に、まずは以下の事前準備をします。

• 明確なペルソナを設定
• シナリオの準備（あるべき動線・仮説の想定）
• 進行役の事前教育・すりあわせ（ユーザビリティテストが誘導的にならないようになど）
• 「誰に向けたサービス」「どんな状況・目的で利用されるのか」の共通認識作り
• テスターを最低5人程度は用意しておく（ヤコブ・ニールセン提唱の理論に基づく）
• ユーザビリティテスト以前に、明らかに課題になる箇所は潰しておく（予測できない課題を発見する為のものなので）
• 中長期的な開発計画に合わせたユーザーテスト実施の工数も計画（スケジューリング）しておく

上記を踏まえて、「新規機能の企画・設計段階」「画面（ワイヤーフレームやモック）作成後」「大枠の実装完了時」 などにユーザービリティテストを実施することで、サービスの品質を向上させることができると考えています。

おわりに

知識がない状態でユーザービリティテストを実施してみましたが、知識だけでなく経験として色々な課題や改善点など、プロダクトを改善するための多くの発見がありました。
まずは雑であったとしても、一度実施してみることに重要な意味があると感じました。

今後は更に理論や作法に沿ってテストの準備・実施をすることで 、より効果的に明確な結果を伴う検証ができると思います。 Cast Me!では引き続きユーザービリティ向上に継続的に取り組み、サービスの品質の向上を目指していきます。

エンジニアからプロダクトマネージャーになった時の記事もよければご覧ください。

元エンジニアがプロダクトマネージャー(PM)にチャレンジしている話

これまで15年〜　SE・プログラマーとして、受託開発・自社サービスの開発など システムの折衝・設計・開発等に従事してきました。 今回プロダクトマネージャー (以下PM)としての機会をいただきました。現在は自社プロダクト「…