デザインレビューの運営

8人のプロダクトリーダーからのフレームワークを活用して、ユーザーが効果的なデザインレビューと批評を実施できるように支援します。

サポート方法

ユーザーがデザインレビューの支援を求めるとき:

1. レビューのコンテキストを理解する - デザインがどの段階にあり、どのような種類のフィードバックが必要かを質問する
2. フィードバックの優先順位を確立する - 価値、次に使いやすさ、次に喜び(Delight)の順で優先順位付けを支援する
3. 批評を構造化する - フィードバックを建設的にフレーミングする方法をガイドする
4. 品質基準を設定する - 「出荷に十分」とは何かを定義するのを支援する

コアの原則

フィードバックの階層に従う：価値、次に使いやすさ、次に喜び

Julie Zhuo: 「最初に重要なのは、これは実際に価値があるのか、問題を解決しているのかということです。それが確認できたら、次のレイヤーに焦点を当てます。それは使いやすさだと考えています。そして最後に...喜びです。」コアとなる価値提案が検証されるまで、美学に関するフィードバックは無視します。

主要プロジェクトのためにスポンサーを指定する

Karri Saarinen: 「基本的に、私たちがプロジェクトのスポンサーです。したがって、我々は仕事をレビューする責任があります。つまり、ただ会議を開いて、進め方を確認するかもしれません...」 すべての主要プロジェクトにファウンダーまたはシニアリーダーをスポンサーとして指定し、静的なスライドデッキではなくライブデモを通じて品質を監督します。

出荷されるすべての画面をレビューする

Dmitry Zlokazov: 「会社のファウンダーは、出荷されるすべての画面の100%をレビューし、アプリで見るすべてのものはこのレビューを通過します。」 シニアリーダーが出荷前にすべてのユーザー向け画面をレビューすることで高い品質基準を維持します。

特定のフィードバック要求を中心にレビューを構造化する

Geoff Charles: 「ロードマップ上のすべての大きな項目はプロダクトレビュープロセスに持ち込む必要があります...ただし、どのタイプのフィードバックが必要かを具体的に質問する方法で構造化される必要があります。」 リスクの高い決定のみを正式なレビューに持ち込み、プレゼンター者が必要なフィードバックを正確に指定することを要求します。

細部の前に大局を考える

Jessica Hische: 「常に細部の前に大局を考えてください。なぜなら、時々人々は...細部についてたくさんのことを言ってくるのですが、それは彼らが本当に何が気になっているのか知らないからです。」 「全体的に私を悩ませているのは何ですか?」を特定の要素についてコメントする前に聞きます。

ぼかしたビジョンを使ってまとまりを見る

Jessica Hische: 「『ぼかした目』を使ってブランドの全体的なまとまりを見てください。個々のピクセルに焦点を当てるのではなく。」 詳細から一歩引いて、全体的なデザインがまとまっているかどうかを評価します。

ユーザーをサポートする質問

• 「このレビューで具体的にどのようなタイプのフィードバックが必要ですか?」
• 「コアとなる価値提案は明確ですか? これは正しい問題を解決していますか?」
• 「詳細について議論する前に - これを初めて見たときの全体的な感覚はどうですか?」
• 「このデザインで最もリスクが高い要素で、最も精査が必要なものは何ですか?」
• 「これを出荷不可にするのは何ですか? その線に近いですか?」
• 「ユーザーがこれを3秒間見た場合、彼らは何を理解するでしょうか?」

指摘すべき一般的な間違い

• 階層のないフィードバック - 美学的な意見をコア価値の懸念と混ぜる
• 静的レビュー - インタラクティブデモではなくスライドデッキをレビューする
• 非構造化フィードバック要求 - 必要なフィードバックのタイプを指定しない
• 詳細へのスキップ - コンセプトを検証する前にピクセルを批評する
• 品質基準がない - シニアレビューや明確な基準なしで出荷する

Deep Dive

8人のゲストからのすべての10のインサイトについては、references/guest-insights.mdを参照してください。

関連スキル

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