facilitating-design-critique

デザイン批評のファシリテーション

このスキルでは、Bitwarden の次の 2 つの信頼できる情報源に基づいて、デザイン批評の ファシリテーション を行います。 Weekly Design Critique & Etiquette Quick Guide と Product Design Review Guidelines です。 実際のセッションの準備をする際は、Confluence のページを直接確認してください。ページの取得には get_confluence_page MCP ツールを使用できます。このスキルは実践者向けのクイックリファレンスであり、これらのページに代わるものではありません。

プラグイン間の依存関係。 話し合うデザインが Figma ファイルにある場合、この スキルは bitwarden-design-tools プラグインの using-figma を組み合わせて使用します。すべての機能を利用するには、 bitwarden-designer と一緒にインストールしてください。

適切な形式を選ぶ

Bitwarden では、異なる種類の批評を 2 つ実施しています。それぞれに合わせて進めてください。

• Weekly Design Critique。 定期的に開催されるチームセッションです。発表者が作業中の成果物の背景を説明し、参加者が確認の質問をしてからフィードバックを行います。気軽に実施するピア・ツー・ピアの場で、フィードバックをどう活用するかは発表者が決めます。
• Product Design Review。 特定のデザイン案に対するステークホルダー向けのレビューです。必要に応じて、プロダクト、エンジニアリング、リサーチの担当者を招きます。スコープ、評価基準、事前説明、ウォークスルー、構造化されたフィードバックの収集など、より綿密なファシリテーションが必要です。

構成を提案する前に、ユーザーがどちらの形式を指しているか確認してください。役割、準備、必要な時間が異なります。

参加者の役割

• 発表者。 デザインの目標、制約、未解決の質問、そしてどのようなフィードバックを求めているかを説明します。フィードバックをどう活用するかは発表者が決めます。
• ファシリテーター。 セッションの進行を担います。話し合いが脱線したら軌道修正し、スコープの中心ではない問題を「ペンディング事項」として記録し、発表者が明示したフィードバックの要望を尊重します。Weekly Design Critique では通常、担当を交代します。Product Design Review では明示的に任命します。
• 参加者。 評価する前に質問します。個人の好みではなく、ユーザーやプロダクトの目標に基づいて、気づいた点、懸念、アイデアを共有します。議論を独占しないでください。

Weekly Design Critique Quick Guide では、次のように要約しています。成果物を批評し、人を支え、プロダクトを改善する。

セッションの進め方

どちらの形式も基本的な流れは同じですが、掘り下げる度合いが異なります。

1. 発表者が背景を説明します。 目標、制約、未解決の質問、求めるフィードバックを説明します。Product Design Review では、背景や「なぜ」についても取り上げます。関連ドキュメント、初期の反復案、ユーザーリサーチの結果、ビジネス目標、エンドユーザーの目標などが含まれます。
2. 確認の質問をします。 評価や提案の前に質問します。まだ理解できていない内容を批評しないようにします。
3. ウォークスルーとフィードバックを行います。 発表者がデザインを説明します。参加者は、ユーザーへの影響、プロダクトの目標、標準、技術的制約に基づいてフィードバックを共有します。
4. まとめます。 主な学びと次のステップを確認します。Product Design Review では、今後参照できるように、希望する形式でフィードバックを記録し、問題に優先順位を付けます。

フィードバックのエチケット — すべきこと、避けること

すべきこと

• 具体的で建設的な意見を伝える。
• うまくいっている、またはうまくいっていない 理由 を説明する。
• 意図を理解するために質問する。
• 問題点だけでなく、うまくいっている点も伝える。
• 時間を守り、話題からそれないようにする。

避けること

• 個人への批判にする。
• 「好きではありません」のような曖昧な意見を述べる。
• 会話を独占する。
• 背景を把握せずに解決策を提案する。
• その場でデザインする。何が不足しているかを伝え、解決はデザイナーに任せる。

議論が停滞したときに使える、切り出しのフレーズをいくつか紹介します。

• 「これはユーザーのどのような問題を解決するものですか？」
• 「[blank] がよくわかりません。説明してもらえますか？」
• 「代替案として [blank] を検討しましたか？」
• 「この部分が優れているのは、[blank] だからだと思います。」

よくある参加時の落とし穴

• 「気に入りません。」 これはフィードバックではありません。所見をユーザーのニーズ、ビジネス上のニーズ、標準、慣習、または技術的な制約に結び付けてください。できない場合は、伝えないでください。
• 「あなたはユーザーではありません。」 個人的な偏見を、誰もが感じることのように提示しています。所見ではなく、偏見として明らかにしてください。
• 「なぜ？」の聞き方がよくない。 「なぜそうしたのですか？」と聞くと、デザイナーを守勢に立たせます。「Xをすることで、何を実現しようとしているのですか？」なら、同じことを角を立てずに確認できます。
• レビュー中に解決策を出す。 善意からの提案が、デザインに波及することがあります。ギャップを説明し、修正方法はデザイナーが後で検討できるようにしてください。
• 否定的なフィードバックばかり。 デザイナーは、うまくいっている点に向かうのと同じくらい、うまくいっていない点から離れる方向にも進みます。まず強みを伝え、その後に課題を伝えてください。
• 考慮されていない影響。 「簡単にできるのでは……」という要望は、思わぬ連鎖を招くことがあります。提案が単純に思えるときは、目に見える波及効果を伝え、デザイナーに判断を委ねてください。

プロダクトデザインレビューのファシリテーター向け手引き

進行役を務める場合（単に参加するだけではなく）：

• レビューの前。 フィードバックを集める方法を選びます。適切な関係者を特定し、招待します。発表者が説明資料（目標、背景、初期の反復、ユーザー調査、ビジネス上の目標、エンドユーザーの目標）を準備できていることを確認します。
• レビュー中。 範囲を定めます。フィードバックに関する期待値を設定します。「なぜ」を明らかにします。ウォークスルーを進行します。範囲と評価基準をあらかじめ示したうえで、意見を募ります。合意した形式でフィードバックを記録します。範囲外の話題は後回しにします。
• レビューの後。 挙がった課題に優先順位を付けます。発表者と次のステップを確認します。

他のスキルとの組み合わせ

• design-review。 セッション中、フィードバックの 内容 には design-review を活用します。30/60/90フレームワーク、行動規範、そして（60%／90%の段階では）content-style-guide が含まれます。このスキルは場の進行を整え、design-review は話す内容を整えます。
• using-figma。 Figmaファイルを使って発表する場合は、using-figma を使って、場に情報を詰め込みすぎずに、デザインの背景情報（スクリーンショット、メタデータ、変数）を議論に取り入れます。

出力形式

批評会の準備または進行を手伝うよう依頼された場合：

1. 形式 — Weekly Critique または Product Design Review。
2. 役割 — 進行役、発表者、参加者。
3. 発表者の準備内容 — 目標、制約、未解決の質問、求めるフィードバック。
4. アジェンダ／進行の流れ — 背景 → 確認の質問 → ウォークスルー → フィードバック → まとめ。
5. 場での注意点 — 発表する成果物を踏まえて、起こりそうな具体的なエチケット上の落とし穴。

最後は必ず、まとめの質問を明示して締めくくります。発表者は次に何をする予定ですか？