プレビューのリンクは、次のリリースの前に、プロダクトが利用者にとってどう動くかを確かめる機会です。役に立つフィードバックとは、何をしようとしたのか、何が起きたのか、なぜそれが問題なのかを説明したものです。コードの原因を突き止めたり、解決策を考えたりする必要はありません。
私は確認のやり取りを文章で行っています。わかりやすい指摘があれば、決めたことを共有の記録として残せますし、私も正しい修正をして、それをどう確認したかをお見せできます。
今回の確認の目的から始める
まずプレビューに添えたメモを読んでください。確認できる状態のもの、まだ作業中のもの、判断をいただきたい点が書かれているはずです。レイアウトの確認と、完成した購入の流れの確認とでは、必要なフィードバックが違います。
合意した範囲を基準にしてください。プレビューに足りないものがあれば、それが今回の段階に含まれるのか、後の段階なのかを確認しましょう。メモがわかりにくいときは、その点を指摘していただければ、結論を出す前に解消します。
実際の利用者になったつもりでタスクを一通り試す
現実的なタスクを一つ選び、最初から試してください。予約サービスなら、サービスを探し、時間を選び、内容を確認して、テスト用の予約を完了させます。必要なのに見つからない情報、迷う選択肢、それまでの入力が失われてしまう箇所に注目してください。
次に、ご自身の役割に関わる部分を確認します。スタッフであれば、予約を探してキャンセルに対応する必要があるかもしれません。代表的な利用者に協力してもらえるなら、タスクを渡して、すぐに画面の説明はせずに、どこでつまずくかを観察してください。GOV.UK のユーザビリティテストに関するガイダンスで、この方法がより詳しく説明されています。
気づいたことと、その影響を伝える
「ここをもっとわかりやすく」は方向性を示してくれますが、何が問題なのかははっきりしません。より役に立つのは、たとえば「予約の確認画面で、どのタイムゾーンが適用されるのかがわからない。うちのお客様はさまざまな国から予約するので、支払う前に知っておく必要がある」といった指摘です。
動作の問題なら、手順、期待していた結果、実際に起きたことを書いてください。関係があれば、デバイスとブラウザも添えてください。スクリーンショットや短い録画は場所を示すのに役立ちますが、共有する前にお客様の個人情報は取り除いてください。
ページまたはプレビューのリンク：…
やろうとしていたタスク：…
問題が起きるまでの手順：…
期待していた結果：…
実際に起きたこと、またはわかりにくかった点：…
影響を受ける人と、それが重要な理由：…
デバイス／ブラウザと、必要ならスクリーンショット：…
気づいた問題と、提案する解決策を分ける
提案は大歓迎です。その理由も添えていただければ、変更が根本の問題を解決するかどうかを判断できます。「赤いボタンを追加する」は解決策の一つです。「スタッフが期限切れの注文を見落としてばかりいる」と書けば、何が必要かがわかり、解決の選択肢も広がります。
見た目についてのフィードバックでは、対象の要素を示し、目的を説明してください。目で追いやすくしたい、ブランドと統一したい、次の操作をもっと目立たせたい、などです。好みの問題も利用者の問題も話し合う価値がありますが、どちらのことなのかがわかると判断しやすくなります。
フィードバックをまとめ、決定事項を見えるようにする
関連する指摘は、一つの文章のスレッドか、合意した確認用の場所にまとめてください。複数の人が確認する場合は、相反する要望を調整し、最終的な方向を決める人を決めておきましょう。そうすれば、ある人の提案を実装した後で、別の人が違うことを求めていたとわかる、という事態を避けられます。
合意したタスクやリリースを妨げている問題。
確認中の動作や見せ方の改善。
次の段階で検討する新しいアイデア。
新しい要件は、範囲とスケジュールに影響することがあります。今の作業に加える前に、その影響について話し合い、次のステップを決めるべきです。後で検討するアイデアのリストを作っておけば、確認中のリリースを見失うことなく、よい提案を書き留めておけます。
変更後に結果を確認する
更新したプレビューをお送りしたら、問題が見つかったタスクをもう一度試してください。結果が合意した内容を満たしているかを確かめ、まだわかりにくい点があれば教えてください。確認の中で別の問題が見つかったら、別の項目として記録していただければ、両方をはっきり追いかけられます。
承認の際は、確認したプレビューまたは段階と、受け入れた制約や残っている作業を明記してください。たとえば、「合意したスマートフォンとデスクトップの表示で予約の流れを確認しました。支払いの前にタイムゾーンが表示されるようになっています。カレンダーへの書き出しは次の段階で対応します」といった形です。
こうしておけば、確認が全員の役に立ちます。あなたはフィードバックがプロダクトをどう変えたかを確認でき、私は合意した内容をはっきり記録に残せます。これからプロジェクトを始める場合も、同じ習慣は必要な成果を説明したブリーフから始まります。