開発チーム一致団結のユーザビリティテストで感情が動く体験をつくる

こんにちは！

プロダクトマネージャーのじょー（@jouykw）です。

みなさん、プロダクトづくりにおいて「ユーザビリティテスト」をどのように活用され、どんな印象を持たれていますか？

開発中の機能をユーザーにテスト環境で触ってもらい、体験上詰まるポイントがないかのネガティブチェックをする工程という印象をお持ちだったりしないでしょうか？（まさに私がそうでした）

先日、家計簿プリカB/43 (ビーヨンサン) からお金の使いすぎを防ぐ家計管理サポート機能をリリースしました。この新機能の体験において、非常に評判が良いポイントとして、下記があります。

ある日の支出が増えている際にどこで買い物をしたのかがグラフ上でパッとわかる
使いすぎ傾向や予算をオーバーした際に「お金」や「炎」の絵文字が飛んでポップに状態をお知らせしてくれる

実はこれらは、実際の支出データを使ったリアルなユーザビリティテストなしには生まれなかった、素敵な体験です。

ユーザビリティテストは、開発チーム皆を巻き込みながらうまく活用できれば、体験上の課題点を取り除くネガティブチェックだけではなく、ユーザーの感情がオッと動くような体験づくりにまで寄与できるプロセスなのではないか…？

ということで、本ブログではスマートバンクで実践しているユーザビリティテストの進め方をご紹介しつつ、より良い体験をつくるためのユーザビリティテストの活かし方について皆さんと探っていければと思います！

💡スマートバンクのユーザビリティテストの進め方については、別記事でも詳しくまとめていますので、是非そちらもご覧ください

本記事ではユーザビリティテストから得られた示唆をどうプロダクトの改善に活かすか？にフォーカスします

blog.smartbank.co.jp

smartbank.co.jp

ユーザビリティテストをなぜやるのか？
実データを使わないと本当の体験は検証できない
- 実際の支出データを準備した背景
- 実施の体制と進め方
フィードバックを体験改善にどう活かすか？
- フィードバックと対応方針の棚卸
- 今回発見された最重要課題
みんなで「フック」のある体験を目指す
おわりに
告知

ユーザビリティテストをなぜやるのか？

主題に入る前に、ユーザビリティテストとは何か？そもそもやるべきなのか？という前提から認識合わせをしたいと思います。

ユーザビリティテストとは？

ユーザビリティテストとは何か？という点については、下記のブログがよくまとまっていたので是非こちらを参照ください。

blog.nijibox.jp blog.nijibox.jp

要点だけかいつまむと、国際標準化機構の定義を引用すれば「ユーザビリティ」とは下記であり、

－ISO 9241-11

ユーザビリティ：ある製品が、指定された利用者によって、指定された利用の状況下で、指定された目標を達成するために利用される際の有効さ・効率・満足度の度合い。

したがって、ユーザビリティテストとは、新たに作られた製品・機能について、下記の３観点をチェックするようなテストのことだと言えそうです。

有効さ：ユーザーが指定された目標を達成する上での正確さと完全さ

効率：ユーザーが目標を達成する際に正確さと完全さに費やした資源

満足度：製品を使用する際、不快さのないこと、および肯定的態度

では、ユーザビリティテストはどういう時になぜ行うのでしょうか？

どんなときになぜやるべきか？

大前提、ユーザビリティテストは必ず実施すべきものではない と私は考えています。

ユーザビリティテストは社内外含めて多くの人々の時間をかける活動になるので、その工数に見合うようなリターンが見込めるケースにのみやるべきだと考えています。

ではそれはどのようなケースかというと、上記の３観点のいずれかで大きな不確実性が生じるようなケース、すなわち一言で言えば「プロダクトにとって全く新しい体験追加・変更があり、ユーザーがうまく使いこなし満足してくれるかの不確実性が大きい」場合だと考えます。

裏を返すと、小さな変更やユーザー体験がシンプルで不確実性が少ないケースでは、ユーザビリティテストは行わず、QAで済ませてしまっても良い、あるいは望ましいかと思います。

スマートバンクの場合は、直近のリリースのような、新しい体験を伴うメジャーローンチの場合は、ユーザビリティテストの実施を強く推奨するというガイドラインで進めています。

今回実施を判断した理由

今回の「お金の使いすぎを防ぐ家計管理サポート機能」については、B/43 におけるメインタブの一つの体験を大きく変える新機能であり、かつ「月中に未然に使いすぎをうまく防げず、翌月使いすぎていることを後悔する」という未解決のユーザー課題をうまく解くために、従来あまり見かけない新しい体験・UI を作ろうとしたため、ユーザーがどのような反応をするか実物を触ってもらわないことには読みきれず、不確実性が高いと判断してユーザビリティテストを実施しました。

（※もちろん仕様確定・実装前にモックアップを使ったコンセプトテストなどは行い、事前に不確実性は可能な限り潰そうとしています）

実データを使わないと本当の体験は検証できない

実際の支出データを準備した背景

今回のユーザビリティテストでは、被験者の実アカウントでログインできるように手配し、自身の実際の支出データをもとにリアルに使い勝手を体験できるような形で検証を行いました。

というのも、Figma で作ったモックアップでユーザーの方にコンセプトテストを行っている段階で、どう頑張っても自分のリアルな支出データでないと実際の行動イメージが湧かず課題ポイントの発見が難しそうという印象を受けていたからです。

今回の新機能では、自身の前月の支出傾向に対して、今月の支出が使いすぎの傾向になっているかどうか？をリアルタイムに判断できるような体験をつくろうとしていました。

ところが、自分の実際の支出データではないモックアップでこれを見た場合に、今が使いすぎであると言われてもそれが自身の実際の支出行動に紐づいていなかったり、使いすぎの目安となる前月の支出に対して身に覚えがない形になります。そのため、実際に自分だったらその状況でどのような思考や行動をするか？をリアルに再現できないという困った事象が起きていました。

このような反応を踏まえ、リサーチに協力いただく方の実際の B/43 での支出データをもとにユーザビリティテストができるようにチームで準備を進めました。

実施の体制と進め方

大まかな実施メンバー構成、実施手順は下記の流れで行いました。

<メンバー構成>

<実施手順>

Step1：サーバーサイド側でユーザビリティテストを実施したい機能周りを実装しデプロイ
Step2：モバイルアプリ側ではその機能を実装したバージョンの本番環境アプリを下記の公式のテストツールを利用してクローズドに配布可能に
- iOS：TestFlight
- Android：Firebase App Distribution
Step3：社内でユーザビリティテストに協力してくれる人を募る
Step4：ユーザビリティテストの種別毎に実際の支出データで新機能を触れる状態のアプリを準備
- 対面観察：テスト端末に新機能ありバージョンのアプリを準備し、各ユーザー毎にログイン頂く
- 簡易日記調査：各ユーザーの端末から新機能ありバージョンのアプリをダウンロード頂く
Step5：ユーザビリティテストの実査！
- 対面観察：オフィスにて実際にアプリを触っているところを対面で観察 & インタビュー
- 簡易日記調査：2週間ほど日常の中でアプリを使ってもらい気づいたことを起票

これにより、ユーザビリティテストに参加してくださる方がご自身の実際の支出データをもとに、リアルな利用行動をしてくれるようになりました！

実査では、PMやリサーチャーがメインでモデレーターを進めつつ、開発に関わるチーム全員が実査の状況を任意参加で閲覧できるようになっており、実際に作ったものをユーザーがどのように利用するのか？どんな反応を示してくれるのか？をチームみんなで目の当たりにしながら、ユーザビリティ観点での課題を明らかにしていきます。

フィードバックを体験改善にどう活かすか？

フィードバックと対応方針の棚卸

ユーザビリティテストを通じて集められた体験上の課題やフィードバックは、下記のように１つの Notion DB に集約していき、今回のリリーススコープにおける対応要否や対応方針を棚卸していきました。

対応要否：本リリーススコープで修正対応するか？（Must / Want / Don’t）
対応優先度：どの程度ユーザー体験上でクリティカルな課題か？（High / Middle / Low）
対応内容：そのユーザー課題 / フィードバック内容を受けどのような改善をすべきか？

このタイミングでの対応要否や対応方針は、開発に携わるPM・デザイナー・エンジニアが一体となって議論し決めるのがミソだと感じています。というのも、このユーザビリティテストを実施するのは開発も終盤でリリースターゲットが近づいてきている時期である為、対応するかしないか？また対応方針も松竹梅どれでいくべきか？を、プロジェクトマネジメントにおける QCDS のトレードオフを意識しながらスピーディに決定する必要があるからです。

一度集まった課題やフィードバックを眺めながら、PMの方で対応要否や対応優先度の原案を記載し、チーム全員を集めて、ガッとその原案に対してのレビューやブラッシュアップ案を議論して方針を決めていきます。

今回発見された最重要課題

当初実装したアプリをユーザーに使ってもらっている中で、

支出額が跳ねた日に何でそれが生じたのか？が知りたいがそれを見つけにくい
使いすぎ傾向になった際に、単にアラートされるだけだと少し暗い気持ちになっちゃうかも？

といった事象やフィードバックが複数人から得られ、再現性を持って生じそうなことがわかりました。

これらは今回解決したいユーザー課題に対するコアな体験価値の部分であった為、リリースまでにブラッシュアップをかけたいねとチームで話し合いました。

みんなで「フック」のある体験を目指す

感情を動かす「フック」のある体験

スマートバンクでは、プロダクトづくりをする上で大事にしたいデザイン原則をいくつか整理しており、その中の一つに「フックを作る」という原則があります。

「フックを作る」

スマートバンクでは、フックとなる仕掛けを作り出すことを大切にします。情報が溢れる現代においては、より印象的で伝わりやすいメッセージを発信することが求められます。そのために目的と情報と表現が合致しており、なおかつ感情を動かすエモーショナルなデザインやシェアしたくなるような仕掛けを考えましょう。

したがって、ユーザビリティテストで発見された課題の解決策を考えるのと並行して、このタイミングであらためてコア体験をより「フック」のある、感情を動かすような体験にするためにブラッシュアップできる点がないか？ということを、チームの皆さんを巻き込み下記のように問いかけ、解決策の方向性を議論しました。

なにか物足りないところはないだろうか？
本質的な Aha! モーメントはどこだろうか？
感動して人に話すとしたらどこの体験をどう伝えるか？
体験をもっとエモくするとしたら何ができるか？

みんなでアイデアを考える

ユーザビリティテストで発見された課題や、「フック」のある体験にするための改善策を考えるこのフェイズでは、デザイナーやエンジニアの皆さんを巻き込み一緒にアイデアを考えるというのが大切だと考えています。

その理由は、実際の打ち手を考えるところはデザイナーやエンジニアの皆さんのクリエイティビティ、既存のプロダクト設計やエンジニアリングの知識を最大限活かした方が良いものができると信じているからです。

私が好きなブログに、PMは「クイズ番組の司会者」であるべきという下記のブログがあります。こちらに記載の内容が、プロダクトづくりにおいてPMが担うべき役割についての私のスタンスに近い考えを述べてくれています。

PMは課題を発見し、関係者間で認識を揃え、解くべき優先度を決めるところにメインで責任を持ちつつ、実際の解決策を考えるところは皆さんと一緒に取り組む方が良いものに辿り着けるというのがその主張です。(もちろんPMも解決策のアイデアは考えます。それを最初から伝え不要なバイアスにしすぎないように配慮するという意図です)

note.com

文中から引用：

PdMは司会者として、課題と徹底的に向き合うことをやるべきなので、まずは良い課題を探してきて優先度の高い順番でプロダクトチームに提供するということに集中すべきだと思っています。

そして、PdMがクイズの司会者に集中し、エンジニア、デザイナーが回答者に集中できている環境が、プロダクトチームが最もパフォーマンスを発揮できる状態だと思ってます。

今回の新機能においても、オフィスでデザイナーやエンジニアの皆さんを巻き込んで、どうやったら先述のようなユーザビリティ上の課題を上手く解き、さらには「フック」のある体験を作り上げられるか？を幾つかの Option を出しながら、様々な制約を加味しつつどの方針が最も良い打ち手の落とし所になりそうかを議論していきました。

一致団結で出した実際のアイデア

こんな感じになったらいいんじゃないか？をホワイトボードで書いてイメージを擦り合わせながら、PM・デザイナー・エンジニアの複数の観点からインタラクティブに議論をすることで、元々は見えていなかったより良い体験をつくりあげていく作業はとても盛り上がり、かつ結果としても良いものに仕上がったように思います。

結果として、

各日次で支払ったお店の名前が支出ペースグラフを触っている際に表示されれば、ユーザーが何が理由で支出が増えたかを直感的に把握し納得できるのではないか？
使いすぎ傾向になったり予算オーバーしてしまったタイミングで、お金や炎が舞ってしまうような楽しいマイクロインタラクションがあると、ネガティブな気持ちになりすぎずにかつ「フック」のある体験になるのではないか？

という素敵なアイデアが出てきました。

以上のように、開発チーム全員を巻き込んでのユーザビリティテストや改善を経てリリースされた今回の新機能に対する反応は、今のところ非常にポジティブなもので、チーム一同最後の最後まで粘って頑張った甲斐がありました、、、、！やったね！