Design Brief

Contextual Design Brief Skill

You are operating with design brief capabilities. This skill ensures that NO design work begins without a thorough understanding of context. Generic designs happen when context is missing — this skill prevents that.

Core Philosophy

"I think people get too focused on the different frameworks and processes, and you start to forget, what are you actually doing?" — Karri Saarinen, Linear

Design without context produces generic output. This skill forces the creation of a design brief that grounds all subsequent decisions in the specific product, users, and goals.

When to Invoke This Skill

ALWAYS invoke before:

• Creating a design system
• Generating logos or brand assets
• Building UI components
• Designing layouts or wireframes
• Any visual design work

Skip ONLY when:

• A complete design brief already exists
• Extending an existing, well-documented design system

Phase 1: Product Definition

Do not accept vague descriptions. Drill down to specifics:

The Differentiation: 5. Why would someone choose this over alternatives? 6. What is this product's "unfair advantage"? 7. What does this product do that competitors refuse to do?

The Constraints: 8. What platforms must this run on? 9. What technical constraints exist? 10. What brand constraints exist (if any)?

Phase 2: User Specificity

Generic user descriptions produce generic designs. Be ruthlessly specific:

Psychographics (deeper): 4. What do they value in tools? (Speed? Power? Simplicity?) 5. What frustrates them about current solutions? 6. Are they choosing this tool, or is it chosen for them?

Context of Use: 7. When do they use this? (Daily driver vs. occasional) 8. Where do they use this? (Office, mobile, field) 9. How much attention can they give? (Focused vs. distracted) 10. What else are they doing while using this?

Expertise Gradient: 11. What does a beginner need? 12. What does a power user need? 13. How do people progress from beginner to power user?

<values>
  <primary_value>What they care most about</primary_value>
  <secondary_values>Other things they value</secondary_values>
  <anti_values>What they actively dislike</anti_values>
</values>

<context>
  <frequency>How often they use this</frequency>
  <environment>Where they use it</environment>
  <attention_level>focused/partial/distracted</attention_level>
  <concurrent_tasks>What else they're doing</concurrent_tasks>
</context>

<journey>
  <entry_point>How they discover/start using this</entry_point>
  <beginner_needs>What novices require</beginner_needs>
  <power_user_needs>What experts require</power_user_needs>
  <progression_path>How users level up</progression_path>
</journey>

Phase 3: Design Principles

Not generic principles — principles specific to THIS product and THESE users:

Bad Principles:

• "User-friendly" — too vague, applies to everything
• "Modern design" — meaningless
• "Clean and intuitive" — every product claims this

Principle Test: A good principle helps you make decisions. If it doesn't rule anything out, it's not useful.

Phase 4: Emotional Targets

Define the emotional response the design should evoke:

Tone Spectrum:

Playful ←————————————→ Serious
Casual ←————————————→ Professional
Friendly ←————————————→ Authoritative
Warm ←————————————→ Cool

Energy Spectrum:

Calm ←————————————→ Energetic
Minimal ←————————————→ Dense
Subtle ←————————————→ Bold
Quiet ←————————————→ Loud

Complexity Spectrum:

Simple ←————————————→ Powerful
Guided ←————————————→ Flexible
Opinionated ←————————————→ Customizable

Phase 5: Reference Audit

Study real products — but extract principles, don't copy aesthetics:

Bad Reference Usage:

• "Let's do dark mode like Linear" (copying without understanding)
• "Make it look like Stripe" (aesthetic theft)

Reference Selection Criteria:

• Serves similar users (not just same industry)
• Solves similar problems (not just looks nice)
• Has documented design reasoning (not just pretty)

<principles_to_extract>
  <principle>What principle they demonstrate</principle>
  <how_they_execute>How they implement it</how_they_execute>
  <how_we_might_apply>How we could apply this (differently)</how_we_might_apply>
</principles_to_extract>

<what_not_to_copy>
  <element>What we should NOT copy</element>
  <why>Why it wouldn't work for us</why>
</what_not_to_copy>

Phase 6: Anti-Goals

What this design should explicitly NOT be:

Good Anti-Goals:

• "Not for beginners" — accepts expertise requirement
• "Not customizable" — values opinion over flexibility
• "Not visually flashy" — substance over style

Bad Anti-Goals:

• "Not ugly" — too obvious
• "Not bad" — not specific

Complete Design Brief Output

Validation Checklist

Before considering the brief complete:

Using the Brief

Once complete, this brief should be:

1. Referenced in every design decision — "Per the brief, our users value X, so..."
2. Updated when assumptions change — Briefs are living documents
3. Shared with all contributors — Everyone should know the context
4. Used in critiques — "Does this align with principle #2?"

The brief is not bureaucracy — it's the foundation that makes intentional design possible.