こちらはFablic Advent Calendar 2015の12/17の記事です。
はじめまして。こんにちは。 デザイナーのyuki930です。
先日COOKPADさんと共同開催したイベント「Think User First #2」で、「機能改善における仮説と検証」というタイトルでお話しさせて頂きました。
機能改善における仮説と検証というテーマだったのですが、実際に先日行ったフリルの評価機能の改善を例にお話させていただきました。 今日はのときの内容について機能改善における仮説と検証 -評価機能編-としてまとめてみたいと思います。
フリルの評価機能の改善の話
フリルでは、購入／販売後にお互いを評価する、評価機能というものがあります。
今回、この部分でいくつかの問題が発生していることがわかり、それらの原因を調べて解消すべく機能の改善を行いました。
ざっくりとした全体の流れ
はじめにざっくりとした全体の流れをご紹介しますと、
大体このような流れで作業を進めています。 今回はこのプロセスにそって順にそれぞれどのようなことをやっていったのかを紹介していきたいと思います。
問題点の洗い出し
起こっている問題の原因を突き止めるため、問題点の洗い出しを行いました。
ひとつずつみていきます。 まずはじめに行ったのはカスタマーサポートへのヒアリングです。 ユーザーからどのようなお問い合わせがよせられているかなどをヒアリングしていきました。
今回、具体的にはこのような「内容的にはよいコメントが書いてあるのに評価の選択肢がわるいだった」「いままで良い評価ばかりだったのにふつうの評価がついていやになったのでフリルをやめたい」などの声がユーザーから届いていることがわかりました。
ちなみに弊社のカスタマーサポートチームはユーザーからの機能要望や使い勝手に関するご意見をこのようにスプレットシートにまとめてくれていたり、新たに発生している問題についてはつどslackで報告してくれたりしてくれていて、開発陣で目を通しながら新たな問題が発生していないかなどをチェックしています。
次に社内のユーザーに評価に関するインタビューを行いました。
弊社のカスタマーサポートはユーザーから採用を行っていることが特徴で、改善案を考えるとき、新しい機能を試すときなど頻繁にインタビューを行っています。 今回は社内ユーザーに協力してもらい、普段ヘビーに取引をしているユーザー／まだそこまで取引件数のないユーザーにそれぞれインタビューを行い、この様な意見を得ました。
また今回は過去にとったユーザーアンケートの中の評価に関するものがあったため、これらの結果も参考に情報をまとめました。
これらを元に、次は定量的なデータを集めていきます。
今回はそもそもそれぞれどれくらいの割合で評価がついているのか、ふつう／わるい評価をつけたユーザーは実際にどのような内容でふつう／わるい評価をつけたのかを調べて行きました。
こちらはそれぞれの評価件数をもとに割合を調べたグラフです。
青がよい評価／黄色がふつう評価／赤がわるい評価です。 こうしてみると、全体に対するふつう／悪い評価は非常に少ないことがわかります。
これらのデータから、そもそも通常スムーズにお取引を完了させれば大体の場合よい評価がつく、ということがわかります。 だからこそ、よい取引をしたつもりなのに、間違った悪いや普通がついてしまった時の衝撃がいかに大きいかということも感じることができました。
次にふつうやわるい評価をした人たちが実際どのように困って悪い評価をつけていたのか、実際にわるい評価をつけた人のコメントの傾向を調査しました。
ある一定期間のわるい評価を抜き出して、目視で内容をチェックしていきました。
この結果、実はわるい評価のうち約5%が文面には好意的なコメントを書いているにもかかわらず「わるい評価」を選択しているものだということがわかりました。 これにより既存のUIに問題があり、間違った評価を選択してしまっているのではないか？という気づきを得ることができました。
同様にふつう評価の内容を精査していきました。これにより内容としてはよい評価なのにふつうと評価しているユーザーが多くいること、インタビューの際にあった「ユーザーによって評価の基準に温度感がある」という事実を確認することができました。
問題の精査
これまでに得られた情報から問題を整理して、今回解決すべき問題を絞り込んでいきました。
今回はこれらの調査からこの4つの問題を抽出しました。
課題の設定
その中で、今回解決すべき課題を決定しました。
仮設の設定
次にこれらを元にこの課題を解決できる仮設をたてて、それにそって実際にデザインしていきました。
今回は「満足した取引だった場合にはよい評価をつける」というフリルの既存ユーザーに根付いている文化を新規ユーザーにもわかりやすくするためのUIと間違った評価を0にするためのミスタップのないUIを作成する必要がありました。
まず現状の取引ページでこれらの問題を引き起こしていそうな箇所を確認を行いました。 さらに新しいアイデアを加えながら課題が解決できそうな画面を組み立てていきます
実際に最初に出来上がった評価ページ案はこちらです。
UIの検証
この時点でのUIの検証の作業は機能によってはやらずに実装することもあるのですが、 今回の機能はユーザーが取引を成立させるために使用する重要な箇所のためこの時点でUIの検証を行いました。
フリルの取引ページはwebベースで構築されているため、静的なHTMLベースで取引ページのプロトタイプが用意されています。 今回はこちらに組み込み、実際に動く形でユーザーにさわってもらって使い勝手などのテストを行い、誤タップすることはないかの確認などを行いました。
この際、評価のコメントを書く欄の幅が狭く書きにくいこともわかったため、行数を増やす改良も加えました。 これらの点は改善後の定量的な数値だけではわからない点なので、この時点でテストを行って非常によかった点でした。
実装／リリース
ここまで完了したら実装になります。 実際に今回リリースしたデザインがこちらです。
- 評価を選択した際に評価の基準を明確化
- スクロール時に誤タップしないように右側はタップ領域にしない
- コメントの入力欄は一般的にフリル内で書かれている量のコメントがひと目で見られる行数に
- わるい体験をするユーザーを少しでも減らすべく、わるいを選択した際にサポートにすぐ問い合わせができる動線を設置
などを盛り込んでいます。
検証
リリース後は、問題だった点が正しく解消されているか検証を行います。 ここで今一度今回の課題のおさらいをしますと、今回は以下の2点が課題でした。
結果をみていきます。 実際に一定期間の評価データを取り出し、ふつう、わるいの評価が実際に減ったのかを確認していきました。
週の途中のリリースだったため、赤線の位置が微妙なところにあるのですが 赤線の部分が実際のリリース日になります。
ふつう／わるい評価ともに割合が減っており、評価の基準を記載した一定の効果がでていると言えるかと思います。
しかし実際の評価内容をみてみなければ適切な評価に移行したという正確なジャッジはできないため、特定の日の普通評価を抽出し、よい評価がきちんと移行しているかを確認しました。
実施前と実施後の評価ですが、ふつう評価の中から実際にとても良い体験をしたひとの評価が減少しており、評価が適切に移動していることがみてとれました これら2点をあわせ、問題点の洗い出しの際に調査した時と比べ、好意的な文言がよい評価に移行していることが確認できました。
つぎに間違ったわるいの評価についての減少を確認しました これについても正確な確認には目視での文言確認が必要になるため、文言の確認を行いました。
「ありがとうございました」などのお礼のメッセージと思われる文言を含む悪いの評価が投稿されたらslackに通知するようにし、そちらを確認することで検証しました。修正以前は日に数件あった間違った評価と思われるものが改善後はほぼ0になり、改善が確認できました。
効果が見られない場合は再び改善を繰り返す
今回の施策では一定の改善がみられましたが、改善がみられない場合は、仮説まで戻り再度別の案を作成して修正していきます。 それでも改善が見られない場合は課題そのものがずれている場合もあるので課題の設定からやりなおす場合もあります。
気をつけているポイントについて
ここで改善プロセスを回す上で気をつけている3つのポイントをご紹介したいと思います
一つ目が、問題点の洗い出しはすばやく、でもしっかりやる、ということです。
これらの作業を行っていくと、たしかにある程度の時間は使ってしまうのですが、ここでしっかりと問題を理解しておかないと根本的にずれた解決策をつくってしまったりすることがあるなと感じています。 限られた時間の中でも、ここでしっかりと問題点を洗い出しておくことが大切だなと思っています。
2つめが、まとめは常にチームに見える化するということです。
ちいさな機能変更でもユーザーを呼んでテストしたり検証したりできればいいのですが、日々の業務の中でつど実施することは難しいですよね。 以前のテスト結果やインタビューの結果などからも参考になる意見をたくさん得ることができます。
過去のアンケートの活用やカスタマーサポートに届く機能要望など常日頃から社内で集める状態を整えておくことで、すばやく情報を集めることができます。
進捗の共有にくわえて、ことなる視点からの意見収集を収集することもできますし、前述のように次の異なる改善の際のヒントになることもあります。 Fablicではまとめはqiita:teamを使って常に共有して情報のストックを行っています。
最後は、調べまくった問題、全部解決したい！！！！というジレンマをぐっと抑える、ということです。
これをやってしまうと開発の規模が大きくなってしまい、ユーザーへの価値提供がどんどん遅くなってしまうことがあります。 まったく当たりが外れていることもありますし、 なにか小さなひとつの改善で他の問題も一気に解消したりすることもあるので、 まずはちいさくはやくためしてみることを心がけています。
ということで改善のプロセスのまとめと、意識しているポイントのご紹介でした。 まだまだ試行錯誤している段階ではありますが、これからもユーザーに価値のある物をよりスピーディーに届けられるよう、日々工夫をしながら取り組んでいきたいと思っています。
最後までお読みいただき、本当にありがとうございました。
Fablic Advent Calendar 2015、明日はnakamuuuによるFRILのAndroid Wearアプリについてのお話です。 お楽しみに！