プロダクト検証カードの書き方：予約リマインダーの例

プロダクトの検証カードは、「試してみよう」という案を、結果から判断できるテストに変えるためのものです。検証したい仮説、確かめる方法、集める情報、その結果を基に決めたいことを記載します。難しいのは、項目を一枚に収めることではありません。そのテストで、本当に仮説を確かめられるかどうかです。

仮説と判断したいことは、企画をチームで整理できるオンラインホワイトボードに並べておきましょう。ここでは、利用者が自分で予約を変更できるリンクを、リマインダーに追加する例を取り上げます。チームが知りたいのは、広く導入する前に、予定が変わった利用者がそのリンクを使えるかどうかです。

テストで確かめられる仮説を一つ選ぶ

利用者が日時を予約し、事前にリマインダーを受け取るサービスを考えてみます。現在、日時を変えたい利用者は、担当者に連絡しなければなりません。新しいリマインダーでは、利用者が自分で予約を変更できるようにする予定です。

「リマインダーを改善すれば、予約した日時に来ない人が減る」という仮説は、最初のプロトタイプテストで確かめるには広すぎます。来られない理由は、予約を忘れた、移動手段がなくなった、日時の都合が悪くなった、変更を伝えられなかったなど、さまざまです。クリックできるプロトタイプだけでは、これらの状況をすべて再現できません。

まずは、予約を変更したい利用者が、リマインダーの変更用リンクに気づき、担当者に連絡せずに都合のよい日時を選べるという仮説に絞ります。ここで確かめるのは、案内の理解と操作の完了です。予約した日時に来ない人が減るかどうかは、その後の実運用で別に検証します。

どの不確実性を優先すべきか決まっていない場合は、先に前提条件マッピングのワークショップを行いましょう。このカードは、確かめる対象を選んだ後に使います。どの課題に取り組むべきかを決める作業の代わりにはなりません。

予約リマインダーの検証カードを記入する

StrategyzerのTest Cardでは、仮説、検証方法、測定するもの、成功と判断する基準を明確にします。プロダクトの操作を調べる場合は、別の調査担当者にも、参加者が何を見て何をするのか、結果をどう使うのかが分かるように補足します。

この判断基準は、どの調査にも使える数値目標ではありません。参加者を募集する前に、何を重大な誤解とみなすか、どの利用状況を調べる必要があるか、次の判断に十分な情報とは何かを決めておきます。少人数の定性調査の結果から、利用者全体の正確な成功率を算出することはできません。

操作の答えを教えずに課題を伝える

「予約変更のリンクをクリックして、別の日時を選んでください」と伝えると、進む場所を教えることになります。これでは、指示された操作ができるかは分かっても、リマインダーから変更方法を読み取れるかは分かりません。「この日時には行けなくなりました。次にどうするか、見せてください」と伝える方が、確かめたい行動を観察できます。

参加者間の違いを解釈できるよう、開始地点の条件をそろえます。予約ページから始める人は、受信箱から始める人が直面する「変更方法を見つける」という課題をすでに通過しています。実際の開始地点、端末、メッセージを見た状況、進行役が助言した内容を記録しましょう。

参加者が迷ったときは、すぐに助けず、その様子を観察します。支援が必要になった場合は、支援の前後に何が起きたかを残します。「下のリンクを試してください」と言われて完了した場合と、自力で導線を見つけた場合は、異なる観察結果です。どちらも設計の参考になりますが、同じ完了件数にまとめると問題が見えなくなります。

プロトタイプには、実際の利用を想定できる完了画面も必要です。予約枠を選ぶところでテストを終えると、元の予約が変更されたことを利用者が理解しているか分かりません。変更後の確認画面まで用意し、今どの日時の予約が入っていると思うかを尋ねます。

起きたことと、その理由の解釈を分ける

観察した事実を、結論に置き換えずに残します。その横に解釈を並べると、どの情報を基に考えたのかが分かります。次の表は、起きたことによって次の対応がどう変わるかを示しています。

「便利そうですね」という好意的な感想と、自発的な操作では、答えている問いが違います。同様に、課題を完了できなかったという事実だけでは原因まで分かりません。行動の順序を残すことで、文言の問題、予約枠の不足、プロトタイプの不具合を区別できます。

Boardmixで検証内容と観察結果を整理する

Boardmixのボードでは、検証カードの上に判断したいことを書き、右側にリマインダーと変更手順を置きます。下側には、観察した事実、解釈、次の判断をそれぞれ分けて配置します。色だけでなく文字でも区別すれば、スクリーンショットにした場合や、別の人の画面でも意味が伝わります。

この例では、「変更方法が分かる」という項目をリマインダーに、「どの予約が残るか分かる」という項目を確認画面につなぎます。どの画面で何を確かめるのかを示すためです。予約した日時に来る人が増えるかという問いは、今回の結果を記す場所から分けておきます。そうしないと、プロトタイプを使えたという結果が、いつの間にか事業上の効果を示す主張に変わってしまいます。

Boardmixでボードを開き、チームが次に決めたいことを中心にカードを作ってみましょう。共有ボードには匿名化した抜粋や架空の課題情報を使い、閲覧を制限する必要がある調査記録は、適切にアクセス管理された保存先へのリンクで参照します。

結果を基に、次に何ができるか判断する

StrategyzerのLearning Cardは、検証した仮説、観察結果、解釈、そこから取る行動を分けて整理します。今回の例なら、リマインダーの修正、確認画面の変更、実運用での試行、あるいは調べていない重要な状況を補う追加調査が次の選択肢になります。

変更手順は理解されていても、都合のよい予約枠が見つからないとします。この場合、リンクの文言をまた書き直しても、原因には対処できません。次に調べるべきなのは、空き状況やサービスの運用です。プロトタイプで手順を使えると分かったら、実運用での小規模な試行によって、実際の予約を変更するときの行動を調べられます。その検証には、別途、評価する項目や利用者を守るための対策が必要です。最初のカードで答えられたのは、それより範囲の狭い、次の判断に役立つ問いです。