Original: 5 mistakes we all make with product feedback
- 全ユーザーを対象にした調査では「昨日サインアップしたユーザー」と「長期間利用してくれているユーザー」を同一視してしまう
- 新規ユーザーの利用ステップを改善したければ、最近サインアップしたユーザーだけに問いかけること
- ある機能を改善したければ、その機能を使っているユーザーだけに問いかけること
- ある機能がなぜ利用されないのかを知りたければ、その機能を使っていないユーザーだけに問いかけること
- ユーザーの感心が高い部分を知りたければ、すべての機能を利用しているアクティブなユーザーだけに問いかけること
- ニーズが発生してから調査を行うと、フィードバックを収集し終えるまでに待ち時間が発生する
- 定期的にユーザーをチェックすること
- 30日、60日、120日、365日といったタイミングでユーザーに問いかける手法が、シンプルだけど効果的
- より進んだ手法としては、ある機能に関するフィードバックをその機能の利用状況に応じてユーザーから収集する方法がある
- 例えば、カレンダーツールがあったとして、ユーザーがそれを初めて使う時と20回目・50回目に使う時とで、フィードバックを求める
- 初回には、どの点が紛らわしいかといったことについてフィードバックが得られるだろう
- 20回目には、不満に感じている部分についてフィードバックが得られるだろう
- 50回目には、機能の制約についてのフィードバックが得られるだろう
- ずっと無料で利用しているユーザーからは、無料プランに対してのフィードバックしか得られないことが多い
- 無料ユーザーから「どのようになれば有料プランにアップグレードするか」といった仮定のフィードバックを得ても意味はない
- 有料ユーザー向けの改善を行うのならば、有料ユーザーだけに問いかけること
- 無料ユーザーが有料プランにアップグレードした理由を知るには、実際にアップグレードしたユーザーだけに問いかけること
- 無料プランを改善したいのならば、無料ユーザーだけに問いかけること
- 多分、彼らは無料でもっと多くの機能を求めるだけだろうが
- ある日、5人のユーザーが「カレンダーによりシンプルなフォームが欲しい」と言ってきた場合、その意見がすべてのユーザーを代表していると思ってはならない
- 新プロジェクトを立ち上げる前に、まずはその5人がすべてのユーザーを代表しているのかを検証する必要がある
- カレンダーのユーザーに問いかけてみて、他のユーザーが何と言ってくるかを確認すること
- 収集したフィードバックはすべて仮説だと考えること、またすぐに実装しようとはせず、検証すること
- 不満の声が実際の声だと確認できても、まだ解決策の実装に入るのではなく、より深く掘り下げること
- それが最終的な目的地へと繋がる
- ユーザーからの機能のリクエストは、ユーザーの持つデザインスキルやあなたのサービスに対する知識、ユーザー自身が抱えている不満の混合物である
- ユーザーは、あなたのプロダクトのビジョンや現在実装中の機能、技術的な実現可能性などを知っているわけではない
- 要求されているものを抽象的に考えること