Money Forward Xでデザイナーをしている齋藤です。
2021年4月に入社し、「デジタル通帳・かんたん通帳」というプロダクトのUX改善を担当しています。
「デジタル通帳・かんたん通帳」は、金融機関とその利用者をターゲットに、利用者の金融体験向上と金融機関の課題解決を目指すスマートフォンアプリです。
アプリ上で口座の入出金履歴や残高情報を紙の通帳のように閲覧することができるため、いつでもどこからでも簡単に口座を管理することが可能になります。
私が入社した時点で、アプリがリリースされて数年経過しており、「現ユーザーが使いやすいアプリになっているか」「（プロダクトメンバーは日常的に画面を見ているため）ユーザーとして初見で操作したときに感じる違和感がわからない」という課題感がプロダクトメンバーの中にありました。そこで、UXデザイナーとして参画した私が施策を検討することになりました。
とはいえ、機能を新たに追加するといった大掛かりなプロジェクトではなかったため、予算や工数をかけない、ミニマムな形で改善を行いました。結果、とても簡易かつスピーディーな形でユーザビリティテストを実施できたため、今回はその内容についてお話したいと思います。
ユーザビリティテストと聞くと、とても工数のかかる大きな取り組みをイメージされる方も多いと思いますが、工夫すれば誰でも小さく簡単に始められるということを、実際のプロセスとともにお伝えしたいです。
まず最初に、デジタル通帳・かんたん通帳のプロダクトオーナー（以下「PO」）と、具体的にどの画面をテストするかを話し合いました。
ユーザー体験の入り口である「ユーザー登録・口座登録」画面、コアアクションである「通帳明細を確認する」画面を改善の対象にすることに。
ユーザー調査専門の企業に依頼してテスターをリクルーティングするという方法も選択肢にはあったのですが、大がかりにやるにしては優先度が高くはなく、費用もかけられないため却下と判断しました。
いろいろな実施方法を検討したところ、社内でユーザビリティテストを行うという選択肢が浮上しました。デジタル通帳・かんたん通帳はtoCサービスなので、ユーザーに属性が近い人も多くいますし、社外の人を巻き込まないので、予算をかけずにテストを実施することができます。
社内でユーザービリティテストを行うことを意思決定し、設計に着手しました。テストの人数や時間、テストの方法をドキュメントにまとめ、POと壁打ちをしながら設計を進めていきました。
まずはテスト参加者の選定。社内のメンバーの中から、「初めてデジタル通帳・かんたん通帳に触れる人」を選定するために、以下の条件で絞りました。
まず一つ目の「Money Forward Xに最近新卒・転職で入社した人」。これを条件に加えた理由は、テストに参加するインセンティブを示しやすいためです。どうせ協力してもらうなら、相手にもメリットがある形で実施したほうがリクルーティングに困りません。新しく入社した人に「オンボーディングの一貫でMoney Forward Xのサービスを触ってみませんか？」と声をかけ、比較的簡単にテスト参加者を募ることができました。
「Money Forward Xが提供するデジタル通帳・かんたん通帳アプリを利用したことがない人」という条件は、「初めてアプリを使う」という属性を絞るうえでは欠かせないものでした。また、他の銀行系のアプリとの差分も知りたかったため、「類似アプリを1つでも利用したことがある人」という条件も加えました。
次に、テストの方法。工数をそこまでかけずに行いたかったので、「こういう順番でアプリを触ってほしい」という指示書だけ送って、感想をアンケートで回収するというやり方が最初に候補として上がりました。ただし、このやり方だとアンケート回答の内容の背景がわからず、どうしても情報量が薄くなってしまう恐れがあります。
リアルタイムで参加者がアプリを触っているシーンを生で観察したほうがプロダクトチームの学習量が増えると思い、多少工数はかかりますが、対面かつリアルタイムでテストを行うことに。
また、私がテスト結果を後で開発チームに共有する形で最初は考えていたのですが、これも直接メンバーに見てもらったほうが結果としてチームの学習になりやすいと思い、対面でのテストをZoomで実況中継するという方法に落ち着きました。
次に、テスト人数と時間。テスト人数を増やす、1回のテストをボリューミーにするなど、工数をかければその分学習量は増えます。ただし、そこまで大掛かりなものにはしたくない。考えた結論として、1人20分で6人、半日×2日で行うことにしました。
性別や年齢など、テスト参加者のタイプを分散すれば十分な学習ができると判断し、この人数に。テストをシミュレーションしたところ、20分もあれば十分だったので、この時間にしました。
テストの方法や人数、期間や時間を考える際、かかる工数と学習量のトレードオフに悩みました。ただ社内テストなので、その分他でやるより工数は低い、なので学習量を重視してやり方を意思決定しました。
準備段階の最後は、テストの内容の設計です。方法として、対面で行うことが決まっていたので、テストの際に参加者に行ってもらうタスクをスライドにまとめる形をとりました。
タスクは、実際のアプリのユーザー行動を細かく区切り、簡易なアクションに落とすことで分けました。
また、リアルに近い声を回収するために、実際のユーザーの利用シーンの認識を揃えるスライドを最初に入れました。
1回のテストで十分な学習量を得られなければ、もう1回もう1回とテストの回数を増やす結果になり、最終的にかかる工数は高くなってしまいます。1回20分で確実に学習を進めることを意識して、テスト内容を洗練させていきました。
準備を綿密に行ったことで、計6人のテストはスムーズに行うことができました。
ユーザーが使うスマートフォンを私のPCに接続し、Quicktimeでリアルタイムで放映することで、参加する開発メンバーも挙動を細かく把握できたようで、「なるほど、こうなるんだ」「こんなことも聞いてみたい」など、チャットがだいぶ盛り上がりました。
チャットの質問をインタビュアーが拾って、参加者に聞くなど、オンライン参加メンバーも一体となってテストを実行できたように思います。
またリアルタイムのテストでの抜け漏れを防ぐために、テスト後にアンケートを行いました。
今回のユーザビリティテストの結果として、改善の優先度をつけることができ、優先度が高そうな改善の具体的なポイントまで学習できました。
常に改善タスクは動いているなかではあったので、このテストで学習したからこう改善した、という明確な繋がりはないですが、この簡易な社内テストで得た声は、結果としてアプリの新規ユーザー登録導線の短縮化、ホーム画面に表示するポップアップのタイミングの変更や画面数を減らすことに繋がりました。
大きな体験の検証となると、それなりに工数や人数をかけて行う必要があります。ただ一方で、プロダクトづくりでは「小さな改善の繰り返し」も重要です。
今回このように簡易さとスピードを意識して、しっかり改善のための学習を得られたのは大変よかったです。入社したての私の小さな成功体験になりました。
また、チームメンバーがユーザビリティテストを観察したことで、ユーザーの客観的な視点でアプリを見ることができたのはチームにとって良い体験になったと思います。ユーザー視点の新たな課題が発見できたり、メンバー全員がユーザー視点で物事を考えられるようになりました。
この取り組みは今回が初めてではありましたが、今後も継続的にやっていき、使い心地のいいプロダクトを作っていきたいと思います。