design-brief-generator

デザインブリーフジェネレーター

概要

関係者間の認識を合わせ、デザインプロジェクトを導く、包括的で構成の整ったデザインブリーフを作成します。このスキルは、プロジェクトの範囲、目標、制約、成功基準を明確に定義するブリーフの作成をデザイナーに支援します。

対象者：

• UX/UI デザイナー
• プロダクトデザイナー
• デザインリード
• デザインシステムチーム
• ブランドデザイナー

---

クイックスタート

1. デザインブリーフを作成する

対話型スクリプトを実行します。

scripts/generate_brief.sh

次の項目を網羅する包括的なデザインブリーフの作成をガイドします。

• プロジェクトの目標と目的
• ターゲットユーザーとペルソナ
• デザイン上の制約
• 成功基準
• スケジュールと成果物

2. ブリーフを検証する

ブリーフの完全性を確認します。

scripts/validate_brief.sh <brief_file.md>

重要なセクションがすべて含まれているかを確認します。

---

中核となるワークフロー

デザインブリーフを作成するタイミング

デザインブリーフを使用するケース：

• 新しい製品や機能のデザインプロジェクト
• デザインシステムの取り組み
• リデザインプロジェクト
• ブランドアイデンティティプロジェクト
• UX リサーチの取り組み

省略するケース：

• 小規模な UI の調整
• バグ修正
• 既存デザインの小さな反復

---

デザインブリーフの構成要素

1. プロジェクト概要

含める内容：

• プロジェクト名と説明
• 背景と状況
• 今このプロジェクトに取り組む理由
• ビジネス目標
• 解決するユーザーの課題

例：

## Project Overview

**Project:** Mobile app redesign
**Background:** Current app has 2.8 star rating with users citing confusing navigation
**Business Goal:** Increase app retention from 15% to 40% (Day 30)
**User Problem:** Users can't find key features, leading to frustration and abandonment

---

2. デザインの目標と目的

成功の定義：

• 主なデザイン目標
• 副次的な目標
• 成功指標
• 必須項目とあれば望ましい項目

例：

## Design Goals

**Primary Goal:** Create intuitive navigation that helps users complete core tasks in < 3 taps

**Secondary Goals:**
- Reduce visual clutter by 40%
- Improve accessibility (WCAG AA compliance)
- Establish reusable component library

**Success Metrics:**
- Task success rate: 90%+
- Time on task: -50%
- SUS score: 75+

---

3. ターゲットユーザーとペルソナ

誰のためにデザインするのか：

• 主なユーザーペルソナ
• ユーザーのニーズと課題
• ユーザーの目標と動機
• 技術的な習熟度
• 利用状況

例：

## Target Users

**Primary Persona:** Sarah, Marketing Manager
- **Age:** 32-45
- **Tech Savvy:** Medium
- **Goals:** Create campaigns quickly, track performance
- **Pain Points:** Current tool too complex, takes too long
- **Context:** Uses on desktop during work hours, sometimes mobile

---

4. デザイン原則と方向性

プロジェクトの指針となる原則：

• 中核となるデザイン原則
• ビジュアルの方向性
• インタラクションパターン
• コンテンツ戦略
• アクセシビリティ要件

例：

## Design Principles

1. **Clarity over cleverness** - Users should never wonder what to do next
2. **Progressive disclosure** - Show what's needed, hide complexity
3. **Consistent patterns** - Use established design system components
4. **Accessible by default** - WCAG AA minimum, aim for AAA

---

5. 範囲と制約

対象範囲と対象外の範囲：

対象範囲：

• 対象となる画面やフロー
• プラットフォーム（ウェブ、モバイル、タブレット）
• デバイスとブラウザー
• アクセシビリティ要件

対象外の範囲：

• デザインしないもの
• 今後検討する事項

制約：

• 技術的な制限
• スケジュール上の制約
• リソース上の制約
• 準拠するブランドガイドライン

例：

## Scope

**In Scope:**
- Dashboard redesign (5 screens)
- Mobile responsive (iOS, Android)
- Dark mode support
- WCAG AA compliance

**Out of Scope:**
- Admin panel (separate project)
- Native mobile apps (web only)
- Marketing website

**Constraints:**
- Must use existing design system
- Launch deadline: 8 weeks
- Development team: 2 engineers
- No custom illustrations budget

---

6. ユーザーフローとユーザージャーニー

デザインする主要なユーザー経路：

• 主なユーザーフロー
• 入口
• 意思決定ポイント
• 成功状態
• エラー状態

例：

## Key User Flows

**Flow 1: Create Campaign**
1. Land on dashboard
2. Click "New Campaign"
3. Choose template
4. Customize content
5. Preview
6. Publish
7. Success confirmation

**Flow 2: View Analytics**
[Define the flow]

---

7. 成果物とスケジュール

納品するもの：

デザイン成果物：

• ユーザーリサーチ（必要に応じて）
• ワイヤーフレーム
• 高精細モックアップ
• インタラクティブプロトタイプ
• デザイン仕様書
• コンポーネントのドキュメント
• アクセシビリティに関する注記

スケジュール：

• 第1～2週：リサーチとワイヤーフレーム
• 第3～4週：高精細デザイン
• 第5～6週：プロトタイプとテスト
• 第7～8週：改善と引き継ぎ

---

8. 成功基準

成功の測定方法：

定性的指標：

• ユーザーテストのフィードバック
• 関係者の承認
• デザイナーによるレビュー
• アクセシビリティ監査の合格

定量的指標：

• タスク成功率
• タスク所要時間
• エラー率
• SUS スコア
• NPS

例：

## Success Criteria

**Usability Testing:**
- 8/10 users complete primary task without help
- Average SUS score: 75+
- Zero critical accessibility issues

**Business Metrics (post-launch):**
- 40% Day 30 retention (up from 15%)
- 90% task completion rate
- < 5% error rate

---

デザインプロジェクトの種類

1. 新機能のデザイン

注力する領域：

• ユーザーニーズの検証
• 既存製品との統合
• インタラクションパターン
• エッジケース

ブリーフのテンプレート： ユーザーフローを重視した標準ブリーフ

---

2. リデザインプロジェクト

注力する領域：

• 現状分析
• 機能している点と機能していない点
• 移行に関する検討事項
• 変更前と変更後の比較

追加セクション：

• 現在の課題
• 競合分析
• デザイン監査の結果

---

3. デザインシステム

注力する領域：

• コンポーネント一覧
• デザイン原則
• 使用ガイドライン
• ガバナンス

追加セクション：

• 導入戦略
• ドキュメント作成計画
• メンテナンス計画

---

4. ブランド／ビジュアルデザイン

重点領域：

• ブランド属性
• ビジュアル言語
• ムードボード
• デザインの検討

追加セクション：

• ブランドガイドライン
• 適用例
• アセットの納品物

---

ステークホルダーとの合意形成

課題を把握するための質問

開始前に確認すること：

1. 解決する課題は何ですか？
2. ユーザーは誰ですか？
3. ビジネス目標は何ですか？
4. スケジュールはどうなっていますか？
5. どのような制約がありますか？
6. 成功をどのように測定しますか？
7. 誰の承認が必要ですか？

ステークホルダーによるレビューのプロセス

ブリーフのレビュー用チェックリスト：

• プロダクトマネージャーがレビュー済み
• エンジニアリングリードがレビュー済み（実現可能性）
• デザインリードが承認済み
• 主要なステークホルダー間で合意済み
• 成功指標に合意済み
• スケジュールを確認済み
• リソースを割り当て済み

---

デザインブリーフのベストプラクティス

すべきこと：

• ✅ 「なぜ」から始める - 課題を明確に述べます
• ✅ 成功を定義する - 具体的で測定可能な基準を設けます
• ✅ 制約を含める - 技術、時間、リソースに関する制約を示します
• ✅ 例を示す - インスピレーションや参考資料を提示します
• ✅ 早い段階で賛同を得る - ステークホルダーにドラフトをレビューしてもらいます
• ✅ 簡潔にまとめる - 最大2～3ページにします
• ✅ 視覚的にする - 図、モックアップ、参考資料を含めます

してはいけないこと：

• ❌ 解決策に飛びつく - まず課題に焦点を当てます
• ❌ 曖昧にする - 「もっと良くする」では役に立ちません
• ❌ 制約を無視する - 制約は解決策を形作ります
• ❌ 孤立して作業する - PMやエンジニアリングを早い段階から巻き込みます
• ❌ 調査を省略する - データに基づいて判断します
• ❌ アクセシビリティを忘れる - 最初から考慮します

---

デザインブリーフにおけるアクセシビリティ

最低要件

すべてのデザインブリーフに含める項目：

WCAG 準拠：

• 目標レベル（A、AA、AAA）
• 色のコントラスト要件（テキストは4.5:1）
• キーボードナビゲーションへの対応
• スクリーンリーダーとの互換性
• タッチターゲットのサイズ（最低44x44px）

テスト計画：

• スクリーンリーダーでのテスト（NVDA、JAWS、VoiceOver）
• キーボードのみでのナビゲーション
• 色のコントラストの検証
• 自動テスト（axe、Lighthouse）

完全なチェックリストについては、references/accessibility_guidelines.mdを参照してください。

---

部門横断の連携

プロダクトチームとの連携

PMが提供するもの：

• ビジネス要件
• ユーザーリサーチ
• 成功指標
• スケジュール上の制約

デザイナーが提供するもの：

• デザインの専門知識
• ユーザー体験に関する提案
• 実現可能性に関するフィードバック
• デザインのスケジュール

エンジニアリングチームとの連携

ブリーフに記載すべき、エンジニアリングチームが必要とする情報：

• 技術的な制約を明記
• インタラクションパターンを定義
• エッジケースを文書化
• コンポーネントの再利用箇所を特定

デザインチームがエンジニアリングチームに提供するもの：

• デザイン仕様
• コンポーネントのドキュメント
• インタラクションの詳細
• レスポンシブのブレークポイント

---

デザインツールとテンプレート

推奨ツール

デザインブリーフ：

• Notion（共同編集ドキュメント）
• Confluence
• Google Docs
• Figma FigJam（ビジュアルブリーフ）

ユーザーフロー：

• Figma
• Miro
• Whimsical
• FigJam

プロトタイピング：

• Figma
• Framer
• ProtoPie
• Principle

---

デザインブリーフの例

例1：モバイルアプリの機能

# Design Brief: In-App Messaging

## Project Overview
Add direct messaging between users within our fitness app.

**Business Goal:** Increase engagement, reduce churn
**User Problem:** Users want to connect with workout partners

## Design Goals
- Enable 1:1 messaging
- Keep it simple and focused
- Integrate with existing notifications

## Target Users
Primary: Sarah, fitness enthusiast, 28-45, uses app 4x/week

## Scope
**In:** 1:1 text messaging, read receipts, notifications
**Out:** Group chat, media sharing (future phase)

## Success Criteria
- 40% of users try messaging in first 30 days
- 20% become weekly active messagers
- No increase in support tickets

## Timeline
6 weeks: Research (1w), Design (3w), Prototype & Test (2w)

---

例2：ダッシュボードのリデザイン

# Design Brief: Analytics Dashboard Redesign

## Project Overview
Redesign analytics dashboard to improve data comprehension.

**Current Issues:**
- Users overwhelmed by data
- Key metrics buried
- Poor mobile experience

## Design Goals
1. Surface most important metrics first
2. Enable drill-down for details
3. Make it mobile-friendly

## Target Users
- Marketing managers (primary)
- Executives (secondary)
- Data analysts (tertiary)

## Success Criteria
- Users find key metric in < 10 seconds
- Mobile traffic increases 30%+
- SUS score: 75+

## Timeline
8 weeks (Research: 2w, Design: 4w, Testing: 2w)

---

リソース

スクリプト

• generate_brief.sh - 対話形式でブリーフを生成
• validate_brief.sh - ブリーフの完全性をチェック

参考資料

• design_brief_template.md - 包括的なテンプレート
• accessibility_guidelines.md - WCAGチェックリスト
• design_principles.md - 一般的なデザイン原則
• user_research_methods.md - リサーチのガイダンス

---

デザイナー向けのヒント

ブリーフを作成する前に

1. ステークホルダーと話す - 実際の課題を理解します
2. 既存のリサーチを確認する - ゼロから始めないようにします
3. 技術的な制約を確認する - エンジニアリングチームに相談します
4. スケジュールを把握する - 現実的に考えます

ブリーフの作成中

1. テンプレートから始める - 既存のものを一から作り直さないようにします
2. 具体的にする - 曖昧なブリーフは、曖昧なデザインにつながります
3. ビジュアルを含める - ムードボード、参考資料、例を含めます
4. 成功を定義する - うまくいったことをどのように判断しますか？

ブリーフ作成後

1. PM とレビューする - 目標とスコープをすり合わせます
2. エンジニアリングチームとレビューする - 実現可能性を検証します
3. ステークホルダーの承認を得る - 明示的な承認を得ます
4. 生きたドキュメントとして扱う - 学びに応じて更新します

---

よくある落とし穴

落とし穴 1：範囲が広すぎる

問題：「アプリ全体を再設計する」 **解決策：**フェーズに分け、優先順位を付けます

落とし穴 2：解決策から始める

問題：「Apple のような見た目にする」 **解決策：**見た目ではなく、ユーザーの課題から始めます

落とし穴 3：制約がない

**問題：**技術的な制限や時間の制約を無視する **解決策：**制約を文書化し、尊重します

落とし穴 4：調査を省略する

**問題：**思い込みに基づいて設計する **解決策：**最低限、既存のデータを確認します

落とし穴 5：成功基準が曖昧

問題：「より良くする」では測定できません **解決策：**具体的で検証可能な基準を定めます

---

まとめ

優れたデザインブリーフは、次のことを行います。

1. 課題を明確に定義する
2. 目標と成功基準を設定する
3. ユーザーとそのニーズを特定する
4. 制約（時間、技術、予算）を文書化する
5. ステークホルダー間の合意を早期に形成する
6. 過度に指示することなく作業の指針となる
7. 学びに応じて進化する

始めましょう：

scripts/generate_brief.sh

これにより、デザインプロジェクトを成功させるための強固な基盤ができます。