running-design-reviews

デザインレビューの実施

8 人のプロダクトリーダーのフレームワークを活用し、ユーザーが効果的なデザインレビューや批評を行えるよう支援します。

支援方法

ユーザーからデザインレビューの支援を求められた場合：

1. レビューの状況を把握する - デザインがどの段階にあるのか、どのようなフィードバックが必要なのかを尋ねます
2. 優先順位を決める - 価値、使いやすさ、楽しさの順にフィードバックの優先度をつけられるよう支援します
3. 批評を構成する - 建設的なフィードバックの伝え方を案内します
4. 品質基準を設定する - 「リリースできる十分な品質」の意味を定義できるよう支援します

基本原則

フィードバックの優先順位に従う：価値、使いやすさ、楽しさの順

Julie Zhuo：「最初に対処すべき最も重要なことは、まず、これは本当に価値があるのか、問題を解決しているのかということです。それができたら、次の段階、つまり使いやすさに焦点を当てましょう。そして最後に、楽しさです。」中核となる価値提案が検証されるまでは、見た目に関するフィードバックは後回しにします。

主要プロジェクトのスポンサーを任命する

Karri Saarinen：「基本的に、私たちがプロジェクトのスポンサーです。ですから、成果物をレビューする責任があります。そのため、会議を開いて、よし、という感じで内容を確認することもあります……」主要なプロジェクトごとに創業者またはシニアリーダーをスポンサーとして任命し、静的なスライドデッキではなく、ライブデモを通じて品質を監督してもらいます。

リリースする画面をすべてレビューする

Dmitry Zlokazov：「会社の創業者たちは、今でもリリースされる画面の 100 パーセントをレビューしています。そして、アプリで目にするものはすべて、このレビューを通過します。」リリース前に、ユーザーが目にするすべての画面をシニアリーダーがレビューし、高い品質基準を維持します。

具体的なフィードバック依頼に沿ってレビューを構成する

Geoff Charles：「ロードマップにある大きな案件はすべて、プロダクトレビューのプロセスに含める必要があります……ただし、どのようなフィードバックを求めているのかを具体的に尋ねる形で構成する必要があります。」正式なレビューに持ち込むのはリスクの高い判断に限り、発表者には必要なフィードバックを明確に示してもらいます。

細部よりも全体像から始める

Jessica Hische：「細部を考える前に、常に全体像を考えてください。細部に関することばかり並べる人がいますが、それは本当に気になっていることが何なのかわかっていないからです。」具体的な要素にコメントする前に、「全体として何が気になっているのか？」と尋ねます。

ぼかして見て、まとまりを確認する

Jessica Hische：「個々のピクセルに注目するのではなく、『目をぼかして』ブランド全体のまとまりを確認してください。」細部から一歩引いて、デザイン全体に一貫性があるかを評価します。

ユーザーを支援する質問

• 「このレビューでは、具体的にどのようなフィードバックを求めていますか？」
• 「中核となる価値提案は明確ですか？適切な問題を解決していますか？」
• 「細部について話す前に、これを初めて見たときの全体的な印象はどうですか？」
• 「このデザインの中で最もリスクが高く、特に注意して検討すべき要素は何ですか？」
• 「何があればリリースできないでしょうか？その境界に近づいていますか？」
• 「ユーザーがこれを 3 秒間見たら、何を理解するでしょうか？」

注意すべきよくある間違い

• 優先順位のないフィードバック - 見た目に関する意見と中核的な価値に関する懸念を混在させる
• 静的なレビュー - インタラクティブなデモではなく、スライドデッキをレビューする
• 構成されていないフィードバック依頼 - どのようなフィードバックが必要なのかを明示しない
• 細部に飛びつく - コンセプトを検証する前にピクセル単位で批評する
• 品質基準がない - シニアによるレビューや明確な基準がないままリリースする

詳細

8 人のゲストによる 10 件すべての知見については、references/guest-insights.md を参照してください。

関連スキル

• product-taste-intuition
• running-effective-meetings
• scoping-cutting