非同期デザインレビューの進め方：会議なしで役立つ意見を集める

非同期のデザインレビューには、確認する特定の版、絞り込んだ質問、明確な回答期限、意見をどう反映するか決める担当者が必要です。それらをまとめて共有します。レビュアーには、デザインのどの部分かを示し、そこにどのような利用者の問題があるか説明してもらいます。締め切り後には、決定事項を共有します。

リンクだけを送り、「何か意見はありますか」と尋ねるより、判断に役立つ意見を集めやすくなります。ビジュアルで共同作業できる共有ホワイトボードなら、レビューの説明、フロー、質問、コメントを1か所に置けます。参加者はチャットの履歴から背景を探し直さずに、それぞれの時間で確認できます。

個別に答えを考えられる問いに使う

資料だけで内容が理解でき、回答前に確認する時間が取れる場合は、非同期レビューに向いています。フローに抜けた状態がないか、文言が利用者の目的に合っているか、チームが見落とした依存関係がないか、といった確認に役立ちます。

何が問題かについて合意できないとき、判断が急を要するとき、文章のやり取りで誤解が増えるときは、短い対話の場を設けます。目的は役立つレビューであり、会議をすべてなくすことではありません。

改善のための意見を求めているのか、正式な承認を求めているのかを明確にします。コメントが集まったことは承認ではなく、沈黙も承認の意思表示ではありません。決定者と、必ず確認してもらう人を先に決めます。フィードバックの基本的な考え方は、英語のデザイン批評ガイドでも確認できます。

リンクを送る前にレビューの説明を書く

ここでは、サブスクリプションの解約フローを確認するチームを例にします。デザイナーが知りたいのは、利用者に次の状態が伝わるか、解約要求の送信に失敗したときに対応できるかです。対象は操作と文言であり、このレビューで会社の解約規定を決めるわけではありません。

この説明があると、各担当者が別々の問題を評価することを防げます。開発は失敗時の状態、サポートはよく起きる誤解、規定の担当者は承認済みのルールとの整合性を確認できます。

Erin Casaliは、自身の経験をもとにした非同期のデザイン批評の記事で、具体的な問いと明確な議論の確認時点を重視しています。上の説明例では、その考え方を限定した1つのレビューに適用しています。変化し続ける製品全体への感想を求めるものではありません。

確認対象の版を固定する

コメントが届く途中でフローを変えると、ある人は消えた画面の問題を指摘し、別の人は置き換え後の画面について答えるかもしれません。版の違いが、意見の対立のように見えてしまいます。

資料にR2と記し、合意した期間はそのまま残します。書き出した画面一式でも、対象部分を明示したコピーでも構いません。元のデザインへのリンクは近くに置きつつ、コメントする版を指定します。コピーを分けるのはチームの運用上の判断であり、ラベルを付けただけでソフトウェア上のロックがかかるわけではありません。

待てない修正がある場合は、変更箇所を示し、引き続き意見が必要かを伝えます。資料を黙って差し替え、すべてのコメントが新しい版を指すと考えてはいけません。レビュー後は、修正版をR3とし、変えた内容を説明します。

判断につながる観察を求める

役立つコメントには、場所、懸念、それが重要な理由があります。解決案も歓迎しますが、解こうとしている問題とは区別できる形にします。

場所：C3の確認見出し。
観察：見出しは解約済みと伝えているのに、下の文章では要求を処理中と書かれている。
利用者への影響：変更が完了したと思って、そのまま画面を閉じるかもしれない。
提案：システムが完了を確認できるまでは、処理中を示す見出しにする。

「確認画面がしっくりこない」より、状態の不一致が具体的に分かるコメントです。ただし、その時点でシステムが何を把握しているかは開発へ、文言の妥当性は権限を持つ担当者へ確認する必要があります。

見つかった矛盾、仮定、個人の好みは分けて書いてもらいます。「短い見出しのほうが好き」という意見も話し合えますが、抜けているエラー状態と同じ重みでは扱えません。チームの意見は、何を検証すべきかを見つける材料であり、製品を使う人から得られる根拠の代わりではありません。

同じ問いに照らして、対立する意見を整理する

コメントを票として数えないでください。別々の問題を解こうとしているために、正反対の変更が提案されていることがあります。対応を決める前に、共通の問いを確認します。

最初の2つは、どちらかを勝ちとする必要はありません。3つ目は今回のレビューの権限を超えています。4つ目は提案した操作を進められない理由になる可能性があります。すべてを画面修正の依頼として扱うと、その違いが失われます。

Boardmixにレビューの作業場所を作る

ボードの開始位置にレビューの説明を置きます。その下に、既存のデザイン資料、または図形とコネクターによる簡単な流れを配置します。各状態にC1、C2などの見えるラベルを付け、正確に参照できるようにします。

2つの確認質問を、フローの該当部分の横に置きます。それぞれのそばに意見を書く場所を残し、資料に結び付く補足にはコメントを使います。別の場所で話し合う場合でも、「C3・処理待ちの状態」のような参照を付けられます。

「変更する」「調べる」「理由を示して維持する」という見出しで、決定用エリアを分けます。担当者は意見を読んだ後、そこに移すか要約します。Boardmixが提供するのは共有キャンバスとコメントです。確認期間を決め、リマインダーを送り、判断するのはチームです。

招待を送る前に、1人の確認者にボードへのアクセス、説明の読みやすさ、想定どおりに意見を追加できることを確認してもらいます。正確な締め切り時刻を、ボードと招待文の両方に書きます。必須の確認者が参加できなければ、欠席を承認と見なさず、別の進め方を合意します。

次の版と一緒に結果を共有する

回答期間が終わったら、変更点と未解決の問いをまとめます。今回の例なら、次のような結果が考えられます。

• C3では、処理待ちの要求と完了した解約を区別する。
• 次の手順の説明は、主な状態表示の下に残す。
• C2の再試行の挙動は、開発からの回答待ちとする。
• 契約上の規定を変える提案は担当者へ回し、今回のデザイン承認には含めない。

修正版をR3として示し、重要な変更を、それが答える問いと結び付けます。新たな回答が必要な部分だけ再確認を依頼し、変わっていない画面を全員に読み直させないようにします。期限後でも重大な誤りを示すコメントには対応すべきですが、新しい好みの提案は次の適切なレビューまで待てます。

まずはBoardmixを開き、明確にラベルを付けた資料について、確認したい問いを1つ用意します。自分が同席しなくても答えられるだけの背景を、確認者に渡しましょう。