eureka techblog

UI改善における仮説検証の3つのポイント

2015.12.25

Design

by Sakawa Hinako

ツイート

この記事は “UI Design Advent Calendar 2015” へ寄稿した記事です。
（http://www.adventar.org/calendars/987）

はじめまして、pairs事業部デザイナーの酒匂（さかわ）と申します。
本日はUI改善時の仮説検証を行ううえでのポイントを、pairsのチュートリアル改善を例にご紹介したいと思います。

チーム全員で仮説出しを行い強い仮説を作り上げる

週に1度行うチームのミーティングでは、課題に対する仮説出しをチーム全員で行っています。
チーム全員で議論し強い仮説を作ることによって、ディレクターやデザイナーだけではなく
エンジニアなどのチーム全員がマーケティング意識を持つことができます。

例えば、pairsのチュートリアルのうちの1つの画面ではこのように仮説を出し合いました。

仮説を出しあった後は、どの順番で検証を進めていくか優先度を決めます。
数字的なインパクトが見込めそうなものを優先することがほとんどですが、デザインや実装の工数が少ないものを優先する場合もあります。

仮説を共有する

さらに、ミーティングで出た仮説は課題ごとにコンフルエンスというナレッジスペースにまとめています。
どの仮説を検証したのか？次に検証する仮説は何か？をまとめることで、他チームに進捗状況を共有したり、他の施策の参考にすることができます。

短時間で結果を出すために2種類の検証方法を使い分ける

複数の要素をもったUIを改善する場合、一つの要素ごとにABテストを実施すると

有意差が出にくく検証に時間がかかる

一つの要素に固執してABテストをし続けてしまう

ということが起こってしまいます。

例えば、pairsのチュートリアルの場合
3つの要素に対しそれぞれの仮説を検証しようとすると、最低でも3回のABテストが必要になります。

そこで、複数の要素を一度に変更した多変量テストを実施します。

多変量テストを行うことで

有意差が出やすく検証が短時間で済む

有意差が出なかった場合、UI改善を行うべき画面や仮説が間違っている

ということがわかります。

おすすめの検証方法

複数の要素を一度に変更した多変量テストを実施
まずは数字が動くかどうかを検証します。

1で数字が動いたら一つの要素ごとにABテストを実施
どの要素が良かった・悪かったのかを明確にします。

2種類の検証方法を使い分けることによってより短時間で最適化できるようにします。

1つの数字だけを追わない、必ず２つの数字を追う

検証する数字を一つのみにしてしまうと
○○○の数字は上がったけど✕✕✕の数字が下がったというようにトレードオフをしてしまう危険性があります。

例えば、pairsのチュートリアルでは離脱率と定着率がトレードオフしてしまう関係性があります。そのためこの2つの数字を検証し、結果定着率を下げすに離脱率を10%下げることができました。

この他にも、バナーの検証ではCTRとCVR、LPの検証ではファーストビュー離脱率とCVRなどがトレードオフしてしまう関係性があります。

そのため、

○○○を下げずにXXXを上げるという指標にする

○○○よりもXXXが良い方を効果が良いとする

のように2つの連動する数字を検証することを予め定めておくとトレードオフになりにくいです。

定量だけでなく定性も忘れない

効果検証については上記のような数字（定量）だけでなく定性調査も大切です。

例えばpairsでは

お客様の行動履歴

ユーザーインタビュー

アプリのレビュー

カスタマーサポートに寄せられるお客様の声

を定性調査としています。

最後に

仮説検証にはチームワークとスピード感が求められます。
チームワーク力が高く検証サイクルが速まれば速まるほど、より多くを学ぶことができますしより早く成功に近づくことができます。
今後もより良いチームワークを築きながら、スピード感をもってpairsの改善に努めたいと思います。

eureka Advent Calender 実施中です。Go言語関連を始めとして、大規模サービス特有の事例、Tipsを共有しています！

ツイート