見出し画像

ユーザーリサーチ推進室の実績大公開!Vol1.ユーザビリティテスト Sensei実施編

この記事は SmartHR AdventCalendar2022 の18日目です。

こんにちは、SmartHRプロダクトデザイングループの@oremegaです。
前回の記事を書いてから1年経っていたことに気づいて驚愕していました。

これまでもユーザーリサーチ推進室(以下、「推進室」)の活動を紹介してきましたが、活動の手段の話にフォーカスすることが多かったです。

ユーザーリサーチ推進室では、「ユーザーリサーチを当たり前とする文化の醸成」を目的にユーザビリティテスト(以下、「テスト」)を定期的に実施する仕組みを構築してきました。
今回は、そのなかでもSmartHRを契約しているお客さまの中から開発に協力してくれるユーザーのテストの実績を紹介します。

テストの被験者として、社内ユーザーだけでなくSenseiユーザーにご協力いただくことができた

2021年の年末にSenseiユーザーを被験者として迎えたテストを初めて実施しました。Senseiユーザーとは、SmartHRの開発に期待を込めユーザーフィードバックやヒアリング等のユーザーリサーチに協力をする意思表明をいただいているお客さまのことです。(下記参考記事)

これまでは社内ユーザーにテストをお願いしてきましたが、Senseiユーザーが被験者になることでSmartHRを契約しているお客さまのプロダクトを操作する様子を観察できるようになりました。Senseiユーザーがプロダクトのどこでどのように反応し、なにを知覚をしているのか知ることは大変参考になります。

事例:通勤検索機能

通勤検索機能のユーザビリティテストの事例を紹介します

これまでのSmartHRでは、従業員から申請で提出された通勤経路を労務の担当者が別のツールを使って計算し、金額の正誤を確認する手間がありました。
通勤経路検索機能は、通勤経路を入力するだけで金額を自動で計算し、正しい計算結果が登録されるのでこれまでの手間が省けるようになりました。
通勤経路検索機能がリリース目前となり、ユーザーが本当に迷いなく操作できるのかを検証するためにテストを実施します。

検証内容

検証内容は主に2つになります。

  • 通勤経路の設定画面

    • 通勤経路の種別に応じて設定項目が変わることを、理解した上で設定できるか

    • 文言を理解して自力で通勤経路を設定できるか

  • 通勤経路の入力画面

    • 通勤経路の検索をして、正しく通勤経路を入力できるか

対象ユーザー

対象ユーザーは、以下の条件に当てはまるSenseiユーザーをPMMに協力してもらいスクリーニングしました。

  • 通勤経路の業務を行っている担当者

  • 規定で自動車通勤が許可されている

  • 申請を業務で使っている方

  • 通勤経路に興味を持っている方

テストで目的を果たすために被験者が条件に合致するかは大事ですが、Senseiユーザーにとってメリットのある機能なのか?という観点も大事です。使える機能であれば契約してもらうこともあるので期待値を高める役割もあります。

Seneseiユーザーへのテストの案内

ユーザーに対して実施していたテストと同じ方法では、セキュリティ面やテスト説明の資料の配布方法など新たに考慮する必要がある点について、この機会に整備しました。

Senseiユーザーに資料の共有
社内ユーザーにテストする際は既存の社内ツールを使って資料を共有できましたが、社外ユーザーに対しては、セキュリティの観点からより安全に資料を共有できる方法を考える必要がありました。最終的に、外部の方に資料を共有するときは基本的にBox(クラウドストレージサービス)を使い、テストに必要な資料はすべてアップロードするようにしました。

テストの説明を事前に共有
テストに慣れている人は珍しいので、事前にテストについての共有をして安心して取り組んでもらえるように資料を作成しました。

  • テストされるのは「プロダクト」です。

  • 思考発話にご協力ください。

  • 予習は必要ありません。

  • できる限り気兼ねなく声を出せる環境から参加してください。

  • デスクトップの画面共有をお願いします。

当初はこれらの内容をPDFにしていましたが、管理上の手間や共有のしやすさの為に現在は、デザインシステムに掲載しているユーザビリティテストの被験者になったらのURLを送るだけになっています。

ステージング環境 / 開発環境へのアクセス方法
被験者ごとにユニークなアカウントとパスワードを発行して、セキュリティの観点から使い回さないようにしています。

計画

対象画面が2つあり、実際に業務で操作者が管理者と従業員と異なるので、それぞれの状況に合わせてシナリオを分けてタスクを作っています。タスクは被験者の能動的な操作を観察するために、できるだけSenseiユーザーにリアリティのある設定になるように配慮しています。

実際のシナリオとタスク

シナリオ1
あなたは人事担当者です。社内の申請フローを管理しています。
今まで交通費申請の確認には、従業員から届いた申請から、定期代が正しいか、
経路を別途チェックしていました。

今回SmartHR上で、通勤経路の検索・申請ができるようになったので、試してみます。

タスク1
「通勤経路検索」機能を使い、従業員が交通費申請を行えるようにしてください。

  • 「通勤経路フォームの名称」は「通勤経路」としてください。

  • 「電車・バス」と「自動車」の経路が選択できる経路を作ります。

  • 通勤定期代は会社の規定上、定期期限は従業員が選べます。

タスク1の観点

  • 経路設定は大きく分けて、公共交通機関系と地図系とがあるので、通勤経路フォームには、2つの経路(電車・バス、自動車)の設定をタスクに含む

  • 検索候補の表示順の設定をタスクに含む

  • スタートページはダッシュボードからにして通勤経路を追加してもらう

  • 本来は申請の設定まで行わないと使えないが、申請は既存機能になるのでテストの対象外とする

実際のシナリオとタスク

シナリオ2
あなたは従業員で、自宅の引っ越し直後です。
引っ越しをしたので、会社に交通費の再申請が必要です。

新しい自宅は「JR千葉駅」から車で20分の場所にあり、車と電車を使って会社に通勤する
予定です。

タスク2
会社から交通費申請の依頼が届きました。下記リンクから交通費を申請してください。

  • 自宅は「千葉県千葉市若葉区小倉町781−1」にあります。

  • 「JR千葉駅」の駅から近い駐車場に停めます。

  • 勤務先はご自身のお勤め先としてください。

タスク2の観点

  • テスト中に「自宅」を出発地とするのは個人情報の観点からリスクがあるので、任意の場所を記載しておく

  • 「出発地」と「到着地」の検索をタスクに含む

  • 到着地の指定は被験者に任せて入力する用にタスクに含む

結果/分析

結果を開発チーム全員で見て認識を合わせて改善ポイントを探っていく

タスク1
問題なくスムーズに操作できることを観察できた。ただし、設定画面の項目のチェックを入れることでどんな設定が反映されるのかが想像しづらい部分があり「プレビューがあると助かる」というコメントがあった。

改善ポイント
一旦はラベルをわかりやすい言葉にしたり、ラベルのみが表示されているので説明を追加する改善をすることになった。

タスク2
自動車の「出発地」と「到着地」の検索で迷い、手を止める様子を観察できた。

  • 電車の場合は駅名を入力すれば候補が表示されるが、自動車の場合は住所を入力しなければならないことに気づかず、駅名や場所の名前を入力していた

  • 表示されているGoogle map上にピンを置こうとしている様子があった

  • 既存機能の課題になるが、通勤経路の追加ボタンに気づかない被験者がいた

ただし、Google mapが表示されるのはとても便利というコメントがあり、タスクも自力で完了できていた。

改善ポイント

  • Google mapは経路検索の結果だけを表示しているので、拡大縮小以外の機能は無効にして操作を限定的にすることにした

  • 経路検索の「場所名」と「住所」の入力を切り替えられるようにして、ユーザーの任意で選択できるようにする

Senseiユーザーの操作を観察できて良かったところ

  • 操作で悩まれているところ、逆に問題なく操作されているところの両方をはっきり見ることができた

  • Senseiユーザーは実際の運用のことも考えての意見を発言してくださるので、気づいてなかった観点を知ることができた

  • 開発者がSenseiユーザーの一次情報を見聞きすることで、プロダクトの使い方の解像度が上がり、共通認識を取れることで今後の開発に活かせる

Senseiにもメリットになった

  • 今後リリースされる機能を先んじて操作することで実際に社内で運用できるかの具体的なイメージがつきやすいとおっしゃっていただきました。今回は「通勤費がSmartHR上で検索できるのが便利」などの声も頂いており、期待していただいているのを感じます

  • テストの機会がまたあればぜひ参加させていただきたいというコメントを頂きテスト自体に好印象を持ててもらった

  • 開発に対してアイデアを出すことで開発者と一緒に作っているような体験ができて面白いと感じてもらえた

おわりに

今年のプロダクトサイドの方針が「顧客の価値で語ろう」でした。
開発チームの誰もが常に「ユーザーを主語」として想定し、「ユーザーがプロダクトをどう使うか」を解像度高く共通認識を持てる状態にしなければなりません。

幸いにもSmartHRでは顧客ヒアリングの文化が浸透しておりプロダクトを作る前には必ずユーザーから直接的、間接的に現在の状況を把握するための事前調査を行っています。

しかし、作ったプロダクトの妥当性の評価は、事前調査に比べると半分程度にとどまります。開発からリリースまでを最短にし、ユーザーの反応を見て改善している結果ですが、「ユーザーがプロダクトをどう使うか」を解像度高く持つためには、プロダクトの操作する様子が観察できるテストが大切です。

そのためにテストを定期的に実施できる環境を整備して、PMMと連携して顧客であるSenseiユーザーの協力を得られる仕組みを構築してきました。

今回のSenseiユーザー全員からは「今後のアップデートに期待する」、「テストをまた受けたい」と言われており、期待に応えるれるように今後ともSenseiユーザーxテストの仕組みを継続していき顧客の価値で語れる開発体制にしていきたいと思います。

SmartHRのプロダクトデザイングループでは、ともに完成のないプロダクトを作る仲間を募集しております。