顧客が高度な機能を使用するかどうかを測定する方法
私は、ある会計ソフトウェアでの銀行照合の新しい設計に取り組んでいます。以前のラウンドの顧客インタビューから、ユーザーの既存のワークフローと現在のデザインの問題を特定しました。
私たちのチームから、過去に見た他のユーザーのニーズに基づいて、銀行調整に関するいくつかの追加機能提案が出されました。例としては、銀行の和解にメモとファイルを添付する機能があります。ユーザーが実際にこれらの機能をどの程度使用するかはわかりません（これらは以前のインタビューで見つけた中心的なニーズではありませんでした）。ユーザーにとってそれらの価値は高くありません。
これを研究するために Verify などのリモート調査ツールを使用する予定です。私は頭の上のいくつかの方法で質問をすることができました：
- [機能]を1〜10のスケールで使用する可能性はどれくらいですか。
- 1〜10のスケールで[機能]を同僚にすすめたいと思いますか。
- 通常のプロセスで[機能]を使用しますか（はいまたはいいえ）？
これらのボーナス機能がどれだけ広く使用されるかを正確に評価するために、質問して結果を解釈する最良の方法は何ですか？回答者が同意できるという結果にバイアスをかけたくありません。
これは、主に機能の同等性が内部の利害関係者から高く評価されることが多いため、実際、私自身の実践では多くのことを浮き彫りにします。インタビューからワークフローを既に定義していて、これが表示されない場合は、おそらく2つのことを行う必要があります。1）機能が必要である/必要でないことを確認し、2）機能の呼び出しを抑制します。
この機能が必要かどうかを確認するには、忠実度が高いかどうかに関係なく、デザインをテストしてください。 （これは多くの人である必要はありません。7〜10人で行う必要があります。）主な目標は、既に定義した目標とタスクをテストし、設計が最初に適切に対処することを確認することです。次に、次のような質問をして、新機能についてユーザーを調査します。
- ここでは何ができないのですか？
- これはあなたの仕事をどのように難しくしますか？
- これには何が欠けていますか？
否定的な反応を引き出すために、このタイプの質問（自由回答）を提案します。ユーザーが知らないうちに、だれが「誰が使用するのか」や「あなたがお勧めするのか...」などの自己申告の質問に答えるとき、知らないうちにだまされてしまうためです（クローズド質問）。以下は、未解決の質問と終了した質問の簡単な要約です。
自由回答形式の質問では、照会者から追加情報を求められます。
長所：信頼を築き、脅威が少ないと見なされ、抑制されない応答または自由な応答を許可することは、明確なユーザーにとってより有用になる場合があります。
短所：時間がかかる可能性があり、不要な情報が発生する可能性があり、ユーザー側でより多くの努力が必要になる場合があります。
クローズドエンドの質問は、「はい」または「いいえ」のいずれかで有限に回答できる質問です。 [またはいくつかの有限のオプションセットから]
長所：迅速で、ほとんど時間をかけずに回答できます。
短所：不完全な応答、明確なユーザーとのより多くの時間を必要とする、リードする可能性があるため、ユーザーを苛立たせたり脅したりする可能性があり、誤解を招く仮定/結論につながる可能性がありますユーザーの情報が必要であり、開示を阻止します。
http://polaris.gseis.ucla.edu/jrichardson/dis220/openclosed.htm
うまくいけば、この機能の必要性（または必要性の欠如）は、この種の質問中に明らかにされます。
機能を求める声を上げるのは難しいかもしれませんが、いくつかの場所から始めることができます。
- この機能が表示されなかったことを調査で再確認してください。
- 以前のバージョンの分析を調べて、機能を使用したユーザーの割合を確認してください。
- mvpを再確認します（おそらく、この機能が本当に必要な場合は、後の反復で実行できます）。
あなたの仮定をテストするために、調査ではなくプロトタイプMVP（実行可能な最低限の製品）を検討します。
たとえば、銀行調整の添付ファイル機能全体を実装する代わりに、「メモまたはファイルを添付する」というリンクまたはボタンを使用できます。次に、リンクがクリックされた回数を測定できます。これは、これが人々が使用する機能かどうかを判断するのに役立ちます。
プロトタイプMVPの問題は、ユーザーが満たされていないニーズを抱えていることです。ユーザーがリンクをクリックした後、次のリリースでこの機能に投票したことをユーザーに説明する必要があります。さらにフィードバックがある場合はメールで通知できます。
プロトタイプMVPを作成する前に、想定を文書化します。その機能が存在する必要があると思う理由とそれを裏付ける研究について説明する必要があります。
@Andrewの回答に沿って、ある種のプロトタイプを作成し、それを使用して想定をテストします。
必ずしもメインの製品に含まれている必要はありません。紙のプロトタイプまたは他のモックアップで、機能が実際の顧客のニーズを満たしていることをある程度確認できます。
私が付け加えておきたいのは、あなたが提案した質問のスタイルは...
[機能]を1〜10のスケールで使用する可能性はどれくらいですか。
1〜10のスケールで[機能]を同僚にすすめたいと思いますか。
通常のプロセスで[機能]を使用しますか（はいまたはいいえ）？
...私の経験では本当に効果がない。
まず、実際の機能とワークフローのコンテキストがない場合、お客様は実際のコンテキストを想像する必要があります。第2に、機能について話し合い、説明することで、主要な質問をすでに提供しました。これらの両方を組み合わせると、機能の実際の使用方法とはほとんど関係のない回答が生成される傾向があります。
プロトタイピング-および実際の状況でのインタビュー-ははるかに効果的です
カップルと会話して、最初にアンケートを行います。どちらの方法でも、メモとファイル（添付ファイル）の処理方法を確認します。
- 紙ファイル
- ローカルおよび/またはネットワークハードドライブ
- サムドライブ
- DropboxやEvernoteなどのサードパーティサービス
アプリケーションの情報を「一致」させるために複雑なフォルダー構造を作成する負担はありますか？
一部のサードパーティアプリの柔軟性と共有機能を好みますか。また、アプリと連携することを好みますか？
他のサービスとのメッシュは、あなたの製品を宣伝する方法にもなるかもしれません。ユーザーと会話します。新機能に「はい」と答えるのに費用はかかりません。また、アプリがすべてのニーズにどのように適合するかについて、これ以上理解することはないと思います。結局のところ、あなたは彼らに「本当に何が本当に役立つのか知っていますか？」
これらの機能は「私たちのチームは過去に見た他のユーザーのニーズに基づいている」と言っています。これは理にかなっており、誰かが想像する問題の解決策ではなく、誰かが経験した問題の解決策を考え出すことです。または、さらに悪いことに、クールに見える機能。
私の場合は、ユーザーが調整タスクを実行するときにユーザーを観察して、これらの問題が存在することを確認します。しかし、彼らはそれをします-あなたのツールで、競争相手のツールで、ペンと紙を使って...彼らは彼らが働いているときにメモを追加しますか？あなたが観察しているように、あなたは彼らが起こっているときに彼らが何をしているかの詳細を尋ねることができ、そしてすぐに質問をすることができます。 「その中で一番大変だったのはどこ？」 「そのステップを簡単にする方法はありますか？」
調査やインタビューよりも観察を信頼しているからです。