ユーザー問い合わせから見えたユーザーの行動パターン

こんにちは。マネーフォワードで自動貯金サービス『しらたま』のプロダクトオーナー/デザイナーをしているohsです。

今日は、不具合の問い合わせ調査のため、SQLを叩いてみて何が原因なのか探っていったら、ユーザーの行動パターンが見えてきた話を紹介します。

💡今日のトピックス💡
ユーザーの声を聞くだけではなく、ユーザーの行動を見よう。
ユーザーがよくする行動で、プロダクトの課題が見えてくるよ。

しらたまってどんなサービス？

しらたまは、「しらずに、たまる」人生を楽しむ貯金アプリです。つい先日（2018年9月19日）でしらたまは1歳になりました🎉

貯金の方法は、おつりや値引き額を払ったつもりで貯めていくおつり貯金 / 値引き貯金 と毎日コツコツ貯めるつみたて貯金 があります。

ある日、こんな問い合わせがきました。

「初期設定は済ませたはずなのに、貯金されない」

貯金の方法を「おつり貯金」に設定し、クレジットカードを連携ました。しかし、カードを使用したのに貯金されません。

そこで、SQLを叩いて、今このユーザーはどんな状態になっているのか調べてみる事に。

そうすると下記の事が分かりました。

■貯金されないという問い合わせに対してチェックするポイントは3つ

 ⑴貯め先が、バーチャル口座※でお試し状態になっていないか？
※バーチャル口座とは、銀行口座がなくても、貯金を試せる機能
→銀行口座に貯める設定になっていて問題なし👍

⑵ユーザーが使っているカードの連携が正常に動いているか？
→連携しているカードの利用履歴も取得できてるので問題なし👍

⑶銀行口座の残高が不足していないか？
→貯金履歴がありません。履歴がないということは、お金が動いてないという可能性が高い。銀行口座の残高が足りなくてお金を動かせないのかも？！ここが怪しいぞ🤔

銀行口座の残高が足りないため、自動的に貯金がされていないのではないかという仮説を立てました。

この問合せ内容から見えた2つの事

1. 「おつり貯金のしくみ」の分かりづらさ

本来の貯金のしくみは、銀行口座間の振替で貯金が行われます。しかし、ユーザーは「クレジットカードからお金が移動して、貯金される」と勘違いしていたのではないか。
ということが、問い合わせ内容とデータベースのログから読み取る事ができました。

開発中から、なんとなく上記の課題感を持っていましたが、チームとして課題を共通認識をするまでには至っていませんでした。
しかし、問い合わせ件数やデータベースから読み取ることによって、ぼんやりとしていた課題感が、明確になりました。

このように、チームとして課題に対する温度感が揃うと、コミュニケーションを取りやすく次の開発方針も決めやすくなると感じました。

2. ユーザーの行動パターンの解明

今回の問い合わせに対する調査の副産物として、ユーザーの行動パターンが分かってきました。

■ユーザーの行動
1. バーチャル口座※でおつり貯金を開始
※バーチャル口座とは、銀行口座を連携しなくても、貯金を試せる機能
↓
2. おつり貯金が数回されたら、バーチャル口座から銀行口座に変更して貯金を再開

心の声：（ ＾ω＾）おっ、このパターンどっかで見た事あるぞ！

実は、過去の問い合わせからも、「バーチャル口座でお試し→銀行口座で貯金を始める」というパターンがあったのです。
開発メンバーの中でも、「バーチャル口座で試してから銀行口座で始めるユーザー多いよね」という認識がありました。

■これらの事からの立てた仮説
「ユーザーはまずどんなサービスか試してみて、サービスの使い方を体験してから、実際の銀行口座で貯金を始めている」

自分のお金がどのように動いているのか不安があるのでは？

お金が関わるサービスでは、損をしないか、お金をすぐに手元に戻せるかなど不安要素が大きい部分があります。そのため、サービス利用前に疑似体験をしてもらうことが大事です。

問い合わせ調査を通じて、データベースに貯まっている履歴を見てみると、ユーザー行動のパターンの傾向が把握できると感じました。

ユーザーの問い合わせ調査から、学んだこと

私自身、SQLの知識はないためエンジニアさんが用意してくれていたテンプレとDatabase memoで探り探り調査をしました。
貯まっていったデータは、サービス作りをしていく上で大きな資産ですしユーザーが実際にどのように行動しているかという事実があります。

実際にSQLを叩いて調査をする所までやらなくても、ユーザーの声を聞いているカスタマーサポートと連携して問い合わせ傾向と調査結果を定期的に見るだけでも、定量的にどんな傾向があり今のサービスにおける課題がなにか把握できるかと思います。

システム的な不具合以外の問い合わせを、どう開発への落とし込むかというと、定めたKPIに対してその問い合わせに対する解決策がKPIに直結するか×開発コスト×どのくらい効果がありそうかで判断をしています。

問い合わせ件数や上記のような仮説を持っていけば、デザイナー発信でもコミュニケーションデザイン面においての改善策を提案したり、提案が通りやすくなったりするのではと感じています。

今日のまとめ

・ユーザーはなぜこのような問い合わせをしたか？考えてみよう。
・問い合わせ傾向から、ユーザビリティーやアクセシビリティーなどの課題を考えてみよう。
・ユーザーの行動から仮説を立て検証していこう

エスノグラフィー調査やフィールドワーク、インタビューを元に、ユーザーの本質的欲求や課題を見つけていくという方法もありますが、今回のように、ユーザー行動におけるデータを調査することで真にユーザーが求めていることや、困っている課題を発見するという方法もあると思います。

なにかの気付きにつながれば幸いです。

おわり。