generate, format, and review portfolio content and case studies, helping you sharpen your storytelling and metrics for design and product hiring expectations. bring your own starter content, or use the skill to start from scratch. language adapts for different roles - designer, design ops, product, creative technologist, design leadership, etc.
Generate and review portfolio case studies using patterns derived from competitive analysis of designers hired at top-tier enterprise SaaS and tech companies.
Workflow
Pattern Library
This skill operates in three modes:
Determine the mode from user intent. If unclear, ask.
Use AskQuestion to collect project fundamentals. Ask in batches of 3-4 questions max. Start with:
Batch 1 — Project Identity:
Batch 2 — Problem and Stakes:
Batch 3 — What You Did:
Before metrics, surface the signals that hiring managers read between the lines for. Ask using AskQuestion:
Scope and ownership:
Operating mode:
Velocity:
Weave these into the draft as exposition, not as a separate section. See Professional Signals for guidance on how to surface each signal.
Run a structured metrics interview using AskQuestion with multiple-choice options for each question. Read Metrics Extraction by Role Type and 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.
Structure the case study using Case Study Anatomy and follow Voice and Tone before drafting.
Required elements:
Length targets:
After drafting, verify the content against the user's role type. See Role Adaptation.
For design ops / creative technology / design leadership:
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 and Vanity Metrics vs Impact Metrics sections to flag anti-patterns.
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.
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.
Formula: Name + Title/Current Context + Domain + Value Claim in 1-3 sentences.
Strong examples:
What to avoid:
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.
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.
Required metadata:
Example: "Staff Product Designer | 1 PM, 5 Engineers, 1 Designer | 2023-2025"
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."
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."
Each section header should read as a strategic decision, not a feature name.
Strong headers:
Weak headers:
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...").
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."
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.
Ask:
Compute: people × time_saved × frequency × duration = total_hours
Convert to business language:
Output example: "Reclaimed ~1,200 engineering hours annually — equivalent to a half-time engineer redirected from rework to new feature development."
Ask:
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."
Ask:
Output example: "Scaled from 3 pilot teams to 14 product teams across 4 business units within 9 months."
Ask:
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."
Ask:
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."
Ask:
Output example: "Improved handoff accuracy, eliminating 90% of downstream design QA fixes."
Ask:
Output example: "Slashed support tickets related to design specs by 70% in Q2."
Ask:
Output example: "Enabled real-time collaborative editing — first in company history."
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."
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.
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:
Avoid:
Don't just list the timeline in metadata — use it as a narrative element that signals how fast you move.
Strong patterns:
Embed in the overview or solution sections, not as a separate data point.
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):
Low-context signals (built from ambiguity):
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:
Execution signals:
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]."
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
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.
Homepage lists projects. Each is a self-contained case study. Works when you have clear, shippable projects.
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):
This structure is especially relevant for roles defined by how you work and what you enable rather than any single shipped product.
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."
Quotes tied to specific, measurable outcomes. Not "great to work with" — outcome statements from people who paid for or depended on the work.
Quotes from PM, engineering, research — each speaking to a different dimension. Especially powerful for design ops roles that live at intersections.
Example structure:
"I was the first/founding designer" is its own proof — someone trusted you enough to be the only design hire.
Links to press coverage or industry publications. Credibility signal without self-promotion.
Content that should NOT appear in strong case studies:
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.
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:
What shifts:
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.