portfolio-case-study-wizard

---
name: portfolio-case-study
description: Generate, format, and review portfolio case studies optimized for design leadership hiring. Use when creating case study content, reviewing draft case studies, extracting metrics from project history, or formatting portfolio narratives. Triggers on requests to write case studies, review portfolio content, extract impact metrics, draft project descriptions, or improve portfolio copy. Adapts product design case study conventions for design ops, creative technology, and design leadership roles.
---

# Portfolio Case Study Skill

Generate and review portfolio case studies using patterns derived from competitive analysis of designers hired at top-tier enterprise SaaS and tech companies.

## Table of Contents

**Workflow**
- [Modes](#modes)
- [Mode 1: Intake + Draft](#mode-1-intake--draft)
- [Mode 2: Review](#mode-2-review)
- [Mode 3: Refine](#mode-3-refine)

**Pattern Library**
- [Identity Statement Patterns](#identity-statement-patterns)
- [Case Study Anatomy](#case-study-anatomy)
- [Metrics Extraction by Role Type](#metrics-extraction-by-role-type)
- [Impact Calculator](#impact-calculator)
- [Professional Signals](#professional-signals)
- [Voice and Tone](#voice-and-tone)
- [Portfolio Architecture](#portfolio-architecture)
- [Social Proof Patterns](#social-proof-patterns)
- [Strategic Absence Checklist](#strategic-absence-checklist)
- [Role Adaptation: Design Ops & Creative Technology](#role-adaptation-design-ops--creative-technology)
- [Quality Bar](#quality-bar)

## Modes

This skill operates in three modes:

1. **Intake + Draft** — Gather raw material from the user, extract metrics, produce a structured draft
2. **Review** — Evaluate existing case study content against the pattern library
3. **Refine** — Take a draft and sharpen it against specific criteria

Determine the mode from user intent. If unclear, ask.

## Mode 1: Intake + Draft

### Step 1: Context Gathering

Use `AskQuestion` to collect project fundamentals. Ask in batches of 3-4 questions max. Start with:

**Batch 1 — Project Identity:**
- What was the project/initiative? (name and one-line description)
- What was your role and title?
- Who was on the team? (roles and approximate count)
- What was the timeline?

**Batch 2 — Problem and Stakes:**
- What business problem or organizational gap did this address?
- Who felt the pain? (users, teams, leadership, customers)
- What was happening before you got involved? (the "before" state)
- What would have happened if nobody solved this?

**Batch 3 — What You Did:**
- What were the 2-3 most important decisions you made?
- What did you build, ship, establish, or change?
- Where did you face resistance or constraints, and how did you navigate them?
- Who did you need to align or influence?

### Step 2: Professional Signals

Before metrics, surface the signals that hiring managers read between the lines for. Ask using `AskQuestion`:

**Scope and ownership:**
- What parts of this did YOU specifically own versus what the team owned? (Aim for 1-2 things only you could speak to.)
- Did you inherit an existing system or build from scratch? (Signals context comfort.)

**Operating mode:**
- Were you leading, executing, or both? Did that shift over the project? (Range signal.)
- How much context existed when you started — clear brief, rough direction, or ambiguity?

**Velocity:**
- What's the tightest timeline in this story? Any "shipped in X weeks" moments?
- Were there phases — a fast initial push then iteration, or steady build?

Weave these into the draft as exposition, not as a separate section. See [Professional Signals](#professional-signals) for guidance on how to surface each signal.

### Step 3: Impact Calculator

Run a structured metrics interview using `AskQuestion` with multiple-choice options for each question. Read [Metrics Extraction by Role Type](#metrics-extraction-by-role-type) and [Impact Calculator](#impact-calculator) before asking.

The goal: turn every qualitative claim into a data-backed statement the reader can scan. Use `AskQuestion` to walk through each impact area with concrete options the user can select from — never open-ended text prompts. Build the multiple-choice options from reasonable ranges based on the context gathered in Steps 1-2. Every question should have 3-5 concrete options plus a "Let me give you different numbers" escape hatch.

### Step 4: Draft Generation

Structure the case study using [Case Study Anatomy](#case-study-anatomy) and follow [Voice and Tone](#voice-and-tone) before drafting.

**Required elements:**
1. Project header (title, role, team, timeline, tags)
2. Overview (2-3 sentences: what you joined, what you did, what changed)
3. Problem framing (business context, not feature description)
4. 2-4 solution sections (each: decision framed as a response to a challenge)
5. Outcomes (metrics, proof, or credible before/after)

**Length targets:**
- Overview: 2-3 sentences
- Problem section: 3-5 sentences
- Each solution section: 4-8 sentences
- Outcome section: 2-4 sentences with hard numbers
- Total case study: 600-1200 words

### Step 5: Adaptation Check

After drafting, verify the content against the user's role type. See [Role Adaptation](#role-adaptation-design-ops--creative-technology).

For design ops / creative technology / design leadership:
- Reframe any "I designed [feature]" language toward "I built [system/process/tool]" or "I established [practice/framework]"
- Ensure metrics use operational vocabulary (adoption, velocity, scale, consolidation) not just product metrics (conversion, retention)
- Check that cross-functional influence is visible — design ops lives at intersections
- Verify that the story shows systems thinking, not just execution

## Mode 2: Review

Read the full pattern library below, then evaluate the content against each pattern category. Produce a structured review:

| Category | Rating | Notes |
|----------|--------|-------|
| Identity statement | strong / adequate / weak | ... |
| Problem framing | strong / adequate / weak | ... |
| Voice and tone | strong / adequate / weak | ... |
| Metrics and proof | strong / adequate / weak | ... |
| Professional signals | strong / adequate / weak | ... |
| Structure and scanning | strong / adequate / weak | ... |
| Strategic absence | strong / adequate / weak | ... |
| Role-appropriate framing | strong / adequate / weak | ... |

For each "adequate" or "weak" rating, provide a specific rewrite suggestion with before/after examples. Use the [Strategic Absence Checklist](#strategic-absence-checklist) and [Vanity Metrics vs Impact Metrics](#vanity-metrics-vs-impact-metrics) sections to flag anti-patterns.

## Mode 3: Refine

Take a specific piece of feedback or a weak area from a review and produce targeted rewrites. Show before/after for each change. Preserve the user's voice — improve structure and impact, don't homogenize.

---

# Pattern Library

Patterns derived from competitive analysis of portfolios by designers hired at top-tier enterprise SaaS and big tech companies. Methodology: content analysis across 8 portfolios and public industry discussion (~250 comments, ~8700 reactions) examining structure, tone, word choice, metrics usage, and narrative strategy.

## Identity Statement Patterns

Formula: **Name + Title/Current Context + Domain + Value Claim** in 1-3 sentences.

Strong examples:
- "Product designer with 11 years of experience turning ideas into high-impact solutions for fleet management and IoT." — Domain-specific, states value, no filler.
- "Sr. Product Designer at [Company], FinTech. Supporting payments, lending, and financial services across web and mobile." — Title, company, domain, scope in one breath.
- "Design ops leader and creative technologist building the systems, tools, and practices that make design teams fast and focused." — Names the operating model, not just the title.

What to avoid:
- Design philosophy manifestos ("I believe in human-centered design")
- Generic statements that could apply to any designer
- Listing tools or methodologies

For design ops / creative technology: Replace "I design X" with the systems-level equivalent. Name what you enable, build, or operate — not what you pixel-push.

## Case Study Anatomy

Every strong case study follows: **Business Context → Discovery/Insight → Design Decision → Outcome/Proof**

This is NOT the design process walkthrough (empathize → define → ideate → prototype → test). Skip the ritual. Go straight to what was learned and what was done about it.

### Section 1: Project Header

Required metadata:
- Project/company name
- Role title
- Team composition (roles and count)
- Timeline
- Skill/contribution tags (e.g., "0→1 Product Design", "Design System", "Systems Thinking")

Example: "Staff Product Designer | 1 PM, 5 Engineers, 1 Designer | 2023-2025"

### Section 2: Overview

2-3 sentences. What you joined, what you did, what changed. This is the movie trailer — if it resonates, they read on.

Strong example:
> "I joined as the founding designer when the product was still a slide deck and a hypothesis. Over 18 months, I built the design practice from scratch — hiring, establishing the system, and shipping the first three releases that took us from pilot to general availability."

### Section 3: Problem Framing

Frame the problem in business terms, not design terms. The problem statement does the heavy lifting — it earns attention for the rest of the case study and implicitly shows how the designer thinks.

Strong examples:
> "Design reviews were taking 3 weeks on average, with no standardized criteria and inconsistent attendance. Teams were shipping without design sign-off, leading to rework that cost engineering an estimated 400 hours per quarter."

> "User onboarding completion rate was just 39%, with most users dropping off before exploring core features. This bottleneck limited conversion and slowed product adoption in key customer segments."

Weak example (product design):
> "The app needed a redesign to improve the user experience."

Weak example (design ops / program management):
> "The design process needed to be improved so the team could work better."

### Section 4: Solution Sections (2-4)

Each section header should read as a strategic decision, not a feature name.

Strong headers:
- "Consolidating five handoff tools into one source of truth"
- "Turning ad-hoc design reviews into a scalable quality gate"
- "Reducing onboarding time from 6 weeks to 10 days"
- "Increasing mobile checkout conversion by 22% in 90 days"
- "Shifting from static mockups to interactive prototypes in user testing"
- "Launching a design system adopted by 8 product teams"

Weak headers:
- "The new homepage design"
- "Wireframes and prototypes"
- "Final screens"
- "Updated process documentation"
- "Workshop agendas"
- "Team meeting notes"

Each section: 4-8 sentences. State the challenge, the decision, and why. Include a moment of tension or insight when possible ("We long operated under the assumption that... After reviewing data, we realized...").

### Section 5: Outcomes

Hard numbers, business language. End on proof, not reflection.

Strong:
> "The new review process cut design-to-ship cycle time by 40% and eliminated rework-driven engineering waste, saving an estimated $1.2M annually."

Weak:
> "The project was well-received by the team and stakeholders."

## Metrics Extraction by Role Type

### Product / UX Design Metrics
- Revenue impact (ARR, MRR, conversion lift, upsell rate)
- User behavior (activation rate, retention, NPS, repeat engagement, support volume)
- Efficiency (time-to-task, error rates, support cost reduction, steps to completion)
- Scale (users, transactions, markets, geographic reach)
- Feature adoption rate (percent of users engaging with new features)
- Churn reduction (decrease in cancellations, subscription drop-off)
- Task completion rate (percent of users successfully completing key flows)

### Design Ops Metrics
- Team velocity (time from concept to ship, review cycle time)
- Tool/system adoption (% of team using the system, components adopted)
- Process improvements (steps eliminated, handoff time reduced)
- Scale enabled (team growth supported, products covered, orgs served)
- Consolidation (tools replaced, redundancies eliminated)
- Quality consistency (design debt reduced, audit pass rates)
- Onboarding speed (time for new designer to first contribution)

### Creative Technology Metrics
- Systems built (prototypes, tools, pipelines, frameworks)
- Engineering time saved or redirected
- Production throughput (assets per sprint, review turnaround)
- Capability gaps closed (what was impossible before, now possible)
- Cross-functional adoption (teams using what you built)
- Automation implemented (manual steps eliminated, number of automations)
- Uptime/reliability improvements (incidents avoided, recovery time shortened)
- Reduction in manual errors (error rates before/after, issues prevented)
- Speed to deploy (time from concept to working prototype, deployment frequency)
- API adoption (internal/external consumers, endpoints used)
- Integration points created (systems or tools now interoperable)
- Performance gains (page load, processing time, resource cost reductions)

### Design Leadership Metrics
- Team scaling (hired X designers, grew team from N to M)
- Retention and attrition (designer retention rate, average tenure, attrition reduction)
- Team diversity (change in representation, hiring across locations, disciplines, or backgrounds)
- Culture/practice (rituals established, critique cadence, design reviews, new communication norms, psychological safety improvements)
- Organizational influence (stakeholders aligned, cross-functional partnerships, strategic seats at planning tables)
- Leadership presence (representation in exec or staff meetings, invited as decision-maker)
- Mentorship (designers promoted, mentee career development outcomes, number of mentoring relationships formed)
- Internal mobility (designers moving into new roles, upskilling rates)
- Training and development programs launched, participation rate
- Increase in design-to-product/project ratio (designer per team or per engineer uplift)
- Process adoption across teams (number of org units adopting new design processes)
- Impact on business outcomes via leadership activities (advocated initiatives resulting in revenue/efficiency gains)
- Success of promoted design leaders (direct reports promoted, alumni leaders in key roles)
- Employee engagement or satisfaction (eNPS, engagement surveys, "voice of designer" scores)
- Influence on hiring processes (improved candidate experience, decreased time-to-hire)
- Conflict reduction or resolution outcomes (measurable improvements post mediation/intervention)

## Impact Calculator

Walk users through these formulas to generate portfolio-ready metrics from raw project facts. Ask the component questions, compute the result, then produce a ready-to-use statement that a recruiter would understand and a hiring manager would respect. Metrics tell a story — they need to be honest and directionally right, not auditable.

When hard numbers aren't available, break estimates into defensible, observable components. Combine multiple angles for multidimensional impact statements. Clarify assumptions ("conservative estimate," "minimum observable") and triangulate with stories or before/after evidence.

### Time Savings

Ask:
1. How many people were affected by this process/tool/system?
2. How much time did it save per person per occurrence? (minutes or hours)
3. How often did it occur? (daily / weekly / per sprint / per project)

Compute: `people × time_saved × frequency × duration = total_hours`

Convert to business language:
- < 500 hours/year → "[X] hours reclaimed per quarter"
- 500-2000 hours/year → "equivalent to [X] full-time weeks annually"
- 2000+ hours/year → "equivalent to [X] full-time headcount redirected to higher-value work"

Output example: "Reclaimed ~1,200 engineering hours annually — equivalent to a half-time engineer redirected from rework to new feature development."

### Cost Impact

Ask:
1. What did the problem cost? (engineer hours at ~$X/hr, tool licenses, support tickets, rework cycles)
2. How much did your solution reduce it? (percentage or absolute)
3. Was there a one-time cost avoided or an ongoing savings?

Compute: `cost_of_problem × reduction_percentage = savings`

Output example: "Eliminated an estimated $800K in annual rework by catching design-engineering misalignment before build, not after."

### Scale and Reach

Ask:
1. How many [teams / designers / engineers / products / orgs] did this serve? Consider breadth: departments, geographies, integrations, partner teams.
2. What was the starting point vs. the end state?
3. Over what timeframe?

Output example: "Scaled from 3 pilot teams to 14 product teams across 4 business units within 9 months."

### Adoption and Engagement

Ask:
1. How many potential users existed?
2. How many actually adopted?
3. Over what timeframe?
4. Any retention or repeat-use signal? (sustained engagement, organic growth, community contribution)

Compute: `adopters ÷ potential_users = adoption_rate`

Output example: "Achieved 85% adoption across the design org within the first quarter, with weekly active usage sustained at 70%+ six months post-launch."

### Velocity and Throughput

Ask:
1. What was the cycle time or lead time before?
2. What is it now?
3. What changed to make it faster?

Output example: "Reduced design-to-ship cycle from 6 weeks to 12 days by replacing ad-hoc review with structured async critique and automated handoff."

### Quality and Risk Reduction

Ask:
1. What error rates, incident counts, or failure modes existed before?
2. What are they now?
3. Any compliance events met, bugs caught pre-release, or escapes prevented?

Output example: "Improved handoff accuracy, eliminating 90% of downstream design QA fixes."

### Experience Improvement

Ask:
1. Were there satisfaction scores, support ticket volumes, or sentiment signals before?
2. What changed?

Output example: "Slashed support tickets related to design specs by 70% in Q2."

### Enablement

Ask:
1. What can stakeholders do now that was impossible before your work?
2. What workflow, integration, or capability was unblocked?

Output example: "Enabled real-time collaborative editing — first in company history."

### Compound Impact

When possible, chain two calculators together for a stronger statement. Time savings → cost impact is the most common:

> "The new component library cut per-feature design time by 40% (saving ~15 hours per feature). Across 60 features shipped annually, that's 900 hours — roughly $135K in design capacity redirected to strategic work."

## Professional Signals

These signals are read between the lines by hiring managers. They should emerge through exposition in the case study, not be stated in a separate "my role" table.

### Individual vs Team Scope

Make it clear what YOU specifically owned without diminishing the team. The reader should finish the case study knowing exactly what would not have happened without you.

Techniques:
- Name your specific decisions: "I chose to prioritize X over Y because..."
- Use "I" for the choices only you made, "we" for shared outcomes
- Describe a moment where your judgment mattered: "The team was split on [approach]. I advocated for [X] based on [evidence], and we shipped that direction."

Avoid:
- Exhaustive credit-assignment tables
- "I did everything" energy (undermines credibility)
- Vague team language that hides your contribution ("the team decided...")

### Timeline as Velocity Signal

Don't just list the timeline in metadata — use it as a narrative element that signals how fast you move.

Strong patterns:
- "Shipped the MVP in 6 weeks with a team of 3" → speed + scrappiness
- "Led the initiative over 18 months through three major pivots" → endurance + adaptability
- "Built the v1 in one month, then iterated through 4 releases over the next year" → fast start + sustained ownership

Embed in the overview or solution sections, not as a separate data point.

### Context Comfort

Signal whether you ramped into complexity or built from zero — both are valuable, and the reader wants to know which you're comfortable with.

High-context signals (joined existing complexity):
- "Inherited a fragmented system across 7 brands and 4 platforms"
- "Navigated a legacy codebase and existing design debt to..."
- "Aligned stakeholders who had conflicting requirements from 3 prior attempts"

Low-context signals (built from ambiguity):
- "Started with a whiteboard sketch and a hypothesis"
- "No existing design infrastructure — I defined the first patterns, components, and processes"
- "Joined pre-product-market-fit when the scope changed weekly"

### Leading vs Executing Range

Hiring managers for senior+ roles want to see both — that you can set direction AND do the work. Show range within a single case study.

Leadership signals:
- "Defined the roadmap for..." / "Set the quality bar for..."
- "Hired and onboarded [N] designers"
- "Gained alignment across [N] teams on..."
- "Facilitated workshops to..."
- Mentorship, critique rituals, process definition

Execution signals:
- "Built the [specific thing] myself"
- "Shipped [feature/system] in [tight timeline]"
- Hands-on technical detail that shows you can go deep
- "Prototyped in code" / "Wrote the documentation" / "Ran the research sessions"

The strongest case studies show a transition: "I started hands-on building [X], then as the team grew, shifted to establishing [Y] and enabling [Z]."

## Voice and Tone

### Verb Selection
Strong ownership verbs: led, designed, built, shipped, established, shaped, defined, drove, launched, created, facilitated, scaled, consolidated
Strategic verbs: gained alignment, navigated constraints, influenced roadmap, bridged [X and Y]
Avoid: helped with, assisted, contributed to, was part of, supported

### I vs We
- "I" for: decisions, design direction, strategy, personal contributions
- "We" for: launches, team outcomes, company results, shared discoveries

### Register
Professional but human. Not academic, not casual. Confident without arrogance. Let results speak. Casual moments are earned by surrounding rigor — a self-deprecating aside lands when the rest of the case study is substantive.

### Things That Never Appear
- "Pixel-perfect"
- "Clean, minimal design"
- "Delightful user experience"
- "I believe design should..."
- Tool lists without context
- Process step narration

## Portfolio Architecture

### Project-based (standard for product designers)
Homepage lists projects. Each is a self-contained case study. Works when you have clear, shippable projects.

### Competency-based (strong for design ops / leadership)
Organized by what you do — Systems, Leadership, Strategy, Collaboration — not by project. Projects appear as evidence within competency sections.

Example structure (observed from a senior designer at a major tech company):
- Work section: shipped product case studies
- Leadership section: mentorship numbers, training, workshops
- Strategy section: design thinking workshops, journey maps, frameworks
- Collaboration section: XFN testimonials, process improvements

This structure is especially relevant for roles defined by *how you work* and *what you enable* rather than any single shipped product.

### Hybrid
Homepage descriptions function as mini-narratives with scope and framing before click-through. Example:
> "As the first design hire, I owned the end-to-end experience from brand identity through shipped product, taking it from 0→1. Our team built the platform that gave IT leaders full visibility across their software stack."

## Social Proof Patterns

### Client/Founder Testimonials
Quotes tied to specific, measurable outcomes. Not "great to work with" — outcome statements from people who paid for or depended on the work.

### Cross-Functional Partner Testimonials
Quotes from PM, engineering, research — each speaking to a different dimension. Especially powerful for design ops roles that live at intersections.

Example structure:
- Engineering voice: speaks to quality, collaboration, technical understanding
- PM voice: speaks to strategic thinking, reliability, scope management
- Research voice: speaks to user advocacy, evidence-based decisions

### Founding/First-Hire Status
"I was the first/founding designer" is its own proof — someone trusted you enough to be the only design hire.

### Press/External Validation
Links to press coverage or industry publications. Credibility signal without self-promotion.

## Strategic Absence Checklist

Content that should NOT appear in strong case studies:

- [ ] Process tourism ("First I conducted 12 interviews, then synthesized on sticky notes...")
- [ ] Tools and technology lists without strategic context
- [ ] Generic design philosophy statements
- [ ] Comprehensive catalogs of everything touched (pick 2-4 wins, go deep)
- [ ] Apologies or hedging ("this was a team effort so I can't claim full credit")
- [ ] Lengthy descriptions of process artifacts (research plans, interview scripts)
- [ ] "I learned a lot" conclusions
- [ ] Aesthetic-focused language as value proposition ("beautiful," "sleek," "polished")
- [ ] **Vanity metrics in stat rows.** Numbers that describe scale of participation (70 designers, 20+ countries) or raw output counts (185 patterns produced) without tying them to impact. These feel impressive at a glance but a hiring manager reads them as filler — the number means nothing without a "so what." Push every headline stat through the filter: "Does this number tell the reader what CHANGED because of my work?" If not, it's context at best — move it to a supporting sentence inside a section, or replace it with an impact metric.

### Vanity Metrics vs Impact Metrics

When reviewing stat rows, dashboards, or highlighted numbers, apply this test:

| Type | Example | Verdict |
|---|---|---|
| Vanity | "70 designers attended" | How many attend anything? What changed because they did? |
| Vanity | "185 patterns produced" | Produced ≠ impact. Did anyone use them? Did they solve a problem? |
| Vanity | "20+ countries" | Geographic diversity is interesting context, not a result |
| Impact | "~1,250 designer-hours reclaimed annually" | Quantified outcome with ongoing business value |
| Impact | "7→1 icon libraries consolidated" | Before/after that implies time savings and consistency |
| Impact | "14 product teams unblocked to ship independently" | Scale of operational change |

Vanity numbers can still appear — but as supporting context inside a paragraph, not as hero stats in a visual callout. Reserve stat rows for numbers that would survive a "so what?" from a skeptical VP.

## Role Adaptation: Design Ops & Creative Technology

Standard product design patterns need these adjustments:

| Product Design Pattern | Design Ops / Creative Tech Adaptation |
|---|---|
| "I designed [feature]" | "I built [system/process/tool]" or "I established [framework]" |
| Conversion / retention metrics | Adoption rates, velocity improvements, time savings |
| Feature case study | System or capability case study |
| User research section | Stakeholder landscape / needs assessment section |
| UI screenshots | System diagrams, workflow visualizations, before/after process maps |
| "Shipped to N users" | "Adopted by N teams" or "Enabled M designers" |
| Single product narrative | Cross-cutting organizational narrative |

The core principles transfer directly:
- Problem-first framing: still essential
- Business language: still essential (your business *is* the design org)
- Active ownership verbs: still essential
- Selective depth: still essential
- Confidence without hedging: still essential

What shifts:
- The "product" you're showing is often the *team* or *system*, not a UI
- Your "users" are often designers, engineers, and PMs — internal stakeholders
- Your "metrics" are operational: velocity, adoption, quality, scale
- Your "design decisions" are often process, tooling, or organizational design decisions

## Quality Bar

AI tools have raised baseline expectations for portfolio polish and structure. Content that passed as "fine" in 2023 now reads as low-effort. The portfolio itself is evidence of the same craft the designer claims to bring to work. Sloppy structure, inconsistent formatting, or vague copy signals that the designer either doesn't notice or doesn't care — neither is a good look.

This does not mean over-designed or visually complex. It means: clear thinking, precise language, intentional structure, and respect for the reader's time. The strongest portfolios in this analysis are restrained, not flashy.