こんにちは、ホワイトプラスでアプリ開発をしている土門です。
最近、ホワイトプラスのアプリ開発では、「ABテストを前提に改善を進める」という考え方がかなり強くなってきました。
以前は、
- このUIの方が使いやすそう
- この導線の方が自然そう
- この訴求の方が伝わりそう
といった、“良さそう” をベースに改善を進めることも少なくありませんでした。
もちろん、それ自体が悪いわけではありません。
実際、プロダクト開発では経験や感覚もとても重要です。
ただ、改善を続けていく中で、
- 本当に改善されたのか？
- ユーザーにとって価値があったのか？
を、感覚だけで判断する難しさも感じるようになりました。
そこで現在は、できるだけ
「施策を作る」のではなく、「仮説を検証する」
という考え方で改善を進めるようになっています。
今回は、ホワイトプラスでアプリ改善を進める中で、ABテストを前提にしたことで何が変わったのかを書いてみます。
以前は「改善したつもり」になりやすかった
以前の改善では、リリース後に
- ユーザーから大きな問い合わせが来ていない
- チーム内の反応は悪くない
- 見た目は良くなった
といった定性的な判断で終わることもありました。
もちろん、ユーザー体験において定性的な視点はとても重要です。
ただ、それだけだと、
- 実際に利用率は上がったのか
- 注文導線として機能したのか
- ユーザー行動に変化があったのか
が分からないままになってしまいます。
また、改善施策によっては、
- 「良くなった気がしていたけど差が出なかった」
- 「想定していたポイントとは別の場所に影響が出た」
- 「ユーザーによって反応がかなり違った」
ということもありました。
こうした経験から、
「改善したかどうか」を感覚だけで判断するのは難しい
という認識がチーム内でも強くなっていきました。
「施策」ではなく「仮説」を考えるようになった
ABテストを前提に改善を進めるようになって、一番大きく変わったのはここかもしれません。
以前は、
- Homeを改善したい
- ボタンを変更したい
- 訴求を変えたい
のように、「何を作るか」から話が始まることが多くありました。
現在は、まず
- どこに課題があるのか
- 何を改善したいのか
- ユーザーのどんな行動を変えたいのか
を先に考えるようになっています。
例えば、
- リピーターが次の注文導線に気づきにくいのではないか
- 初回ユーザーはどこで迷っているのか
- Homeの情報量が多すぎて判断しづらいのではないか
といった形で、まず仮説を整理します。
その上で、
「では、どういう改善を試してみるか」
を考える流れに変わっていきました。
KPIを先に考えるようになった
ABテストを前提に改善を進めるようになってから、KPIへの向き合い方もかなり変わりました。
もちろん以前から、KPIを意識していなかったわけではありません。
ただ以前は、
- 改善施策を作る
- リリースする
- 反応を見る
という流れの中で、「何をもって成功とするか」が少し曖昧なまま進むこともありました。
一方で、ABテストを実施する前提になると、
「この施策で、どの数字を見たいのか」
を事前に決める必要があります。
例えば、
- 注文導線なら遷移率なのかCVRなのか
- Pushなら開封率なのかCVRなのか
- Home改善なら回遊率なのかタップ率なのか
のように、施策ごとに「計測可能なKPI」を整理するようになりました。
これは単純に数字を見るためだけではなく、
- 何を改善したいのか
- ユーザーのどんな行動を変えたいのか
を、チーム内で揃える意味でもかなり重要だったと思います。
また、ABテストを実施すると、自然と振り返りの場も発生します。
- 差が出たのか
- 想定通りだったのか
- どこに影響があったのか
を確認する中で、設定したKPIに対して必ずフィードバックが返ってきます。
これは個人的にもかなり大きな変化でした。
以前よりも、
- 「なぜこの結果になったのか」
- 「次は何を試すべきか」
- 「仮説のどこがズレていたのか」
といった議論が増え、改善が一回の施策で終わらず、次につながりやすくなったと感じています。
「まず小さく試す」がやりやすくなった
ABテストを前提にすると、「最初から完璧を目指さない」という考え方もしやすくなりました。
以前は、
- リリースするなら完成度を高くしたい
- 一度出したら簡単には変えづらい
- 大きく設計してから進めたい
という意識が強かったように思います。
また、「どの案が正しいのか」を事前に決め切ろうとして、議論や検討に時間をかけることもありました。
ただ、実際にはユーザーの反応を見てみないと分からないこともかなり多いです。
ABテストを前提にすると、
「まず試してみて、結果を見ながら判断する」
という進め方がしやすくなります。
そのため現在は、
- まず小さく試す
- 数字を見る
- 差分を確認する
- 必要なら改善を続ける
という進め方が増えました。
「最初から1つの正解を決め切らなくてもよい」という感覚は、個人的にもかなり大きな変化でした。
実際、ABテストで検証できる前提があることで、
- まず出してみる
- 実際の反応を見る
- 必要なら方向修正する
という動きがしやすくなり、改善速度も以前より上がったように感じています。
これは開発側だけではなく、PdMとの会話でもかなり変化を感じています。
PdMとの会話も変わった
以前は、
「このUIにしたい」 「この導線を追加したい」
のように、“作るもの” の話から始まることも多かったのですが、
最近は、
- 何を改善したいのか
- どの数字を見たいのか
- どんな行動変化を期待しているのか
を最初に整理することが増えています。
また、
- 優先度MTG
- スプリント計画
- 振り返り
などでも、
「この施策は本当に改善につながったのか？」
を一緒に確認する流れが自然と増えてきました。
以前よりも、
「依頼を受けて作る」
ではなく、
「一緒に改善を考える」
感覚に近づいてきている気がします。
「差が出なかった」ことにも価値がある
ABテストをやっていて面白いのは、
「思ったほど差が出なかった」
という結果も、ちゃんと価値になることです。
改善施策を考えていると、
「これは絶対良くなる気がする」
と思うことは結構あります。
ただ、実際には、
- ほとんど差が出なかった
- 想定したユーザー層には刺さらなかった
- 逆に別の導線に影響していた
ということも少なくありません。
以前だったら、
「リリースしたからOK」
で終わっていたかもしれない施策でも、
ABテストを前提にすると、
- 次に何を試すべきか
- どの仮説がズレていたのか
- ユーザーは何を見ているのか
を考える材料になります。
これはかなり大きな変化でした。
最後に
ABテストを前提に改善を進めるようになってから、
「施策を作ること」そのものよりも、
「ユーザーにとって本当に価値がある改善なのか」
を以前より強く考えるようになりました。
もちろん、数字だけですべてを判断できるわけではありません。
ユーザー体験には定性的な視点も必要ですし、短期的な数値だけでは測れない改善もあります。
ただ、
- 仮説を立てる
- KPIを決める
- 小さく試す
- 振り返る
- 次につなげる
というサイクルを回しやすくなったことで、以前よりも「改善を積み上げる」感覚が強くなったように感じています。
これからも、ユーザー体験をより良くするために、感覚だけではなく、数字とも向き合いながら改善を続けていきたいと思います。
