Case Study Craft

A skill for creating product design portfolio case studies that demonstrate thinking, personality, and craft — not process checklists.

Core Philosophy

This skill is grounded in a single principle: a case study is about the designer, not the project. It should reveal how you think, what you value, and why your judgment matters. Process steps are scaffolding for the story — never the story itself.

The design industry is saturated with formulaic case studies that follow identical templates: Problem → Research → Personas → Journey Map → Wireframes → Final Designs. These are forgettable. Hiring managers scan 40+ portfolios per position, spending roughly 30 seconds on initial review. They skip straight to final designs first. Only if the output is strong do they go back to understand the process.

Beautiful work gets the interview. Strategic work lands the job.

A note on using AI to write case studies

The most common failure mode when using AI to assist with a case study is that it defaults to the same checkbox template the design industry has been trying to escape for years. Ask a generic AI for help with a case study and you'll get: Problem → Research → Personas → Journey Map → Wireframes → Final Designs — dressed up with slightly different headings.

This skill is built to prevent that. It does not automate the thinking. It cannot — and should not — replace the judgment calls that make a case study yours. What it can do is help structure raw material that you provide, challenge generic framing with sharper alternatives, and push every section toward specificity and point of view.

The way this skill is designed to work:

• It asks questions before it drafts anything. The raw material — decisions, tensions, outcomes, voice — comes from the designer.
• It resists process-phase structure by default, and will propose narrative alternatives based on what the project actually contains.
• It flags generic writing patterns (corporate speak, process-listing, context vacuums) rather than producing them.
• It treats every section as an argument to be made, not a box to be checked.

If the output feels formulaic, that's a signal to push back — add more of your specific context, opinions, and decisions. The more you put in, the less generic it gets.

---

Before Writing: The Strategic Questions

Before drafting a single word, answer these questions. They determine everything — structure, emphasis, tone, visuals, length.

1. Who is reading this?

Case studies fail when they try to serve every audience simultaneously. A single case study cannot optimally serve instructors, peers on Medium, recruiters, and hiring managers. Prioritize ruthlessly.

For hiring managers at target companies: Lead with outcomes and judgment. Show the quality of your output. Demonstrate that you connect design decisions to business results. These readers have 30 seconds initially, then 15–20 minutes if you pass the scan.

For peers / publication audiences (Medium, blogs): Lead with transferable insights. Teach something. The reader should walk away with a principle they can apply to their own work.

For portfolio visitors (your own site): This is the primary format. Optimize for scannability, visual impact, and a coherent story arc. This is where you control the experience end-to-end.

2. What is your area of focus?

The case study structure should reflect the designer's strengths and the role they are pursuing. A case study from someone pursuing a UX Research role looks fundamentally different from one targeting a Product Design Lead position.

• Research-focused: Emphasize how insights were gathered, synthesized, and turned into decisions. The backstage of the process is the star.
• UI/Visual-focused: Let the craft speak. Large visuals, polish, motion, interaction details.
• Strategy/Leadership-focused: Emphasize stakeholder alignment, team building, cross-functional influence, and measurable outcomes.
• Systems-focused: Show the architecture of decisions — token structures, component logic, scalability thinking.

Promote your strongest skills. Showing shallow work in areas outside your focus hurts more than omitting those areas entirely.

3. What is the one thing someone will remember?

Every strong case study has a single memorable element — an insight, a visual moment, a clever reframe, a surprising outcome. Identify it before you start writing and build the narrative toward it.

4. What is the first sentence?

Most case studies open with a company description: "Acme Corp is a B2B SaaS platform that helps teams manage X." This is the blandest possible start. The first sentence is where a reader decides in a fraction of a second whether to continue.

Strong opening patterns:

• A tension: "Every analyst on the team had a private spreadsheet. That spreadsheet was the product's biggest competitor."
• A number that reframes the problem: "The average query took four hours. The design team's job was to make it feel like thirty seconds."
• A provocation: "We were designing a dashboard no one asked for — but everyone needed."
• A constraint: "We had three weeks, no existing design system, and a CEO who approved every screen."

The first sentence should create a question in the reader's mind that only the rest of the case study can answer.

---

The Anti-Template: Narrative Structures That Work

Do NOT follow a rigid template. Instead, choose a narrative spine that fits the project. Here are proven structures — adapt, combine, or invent your own.

Structure A: Insight-Led

Each major section is organized around a key insight or decision, not a process phase. Headings themselves tell the story — a reader scanning only headings should understand the arc.

When to use: Complex projects with multiple turning points. Projects where the interesting part is what you learned, not what you did.

Example pattern:

• Context + stakes (brief)
• Insight that reframed the problem
• How that insight changed the approach
• The solution that emerged
• What the outcome revealed

Reference: Karolis Kosas's CUJO case study uses this approach — each section heading delivers a new insight as you scroll. "For an ordinary person, anything related to cyber security seems abstract and cryptic" reframes the entire design challenge in one sentence.

Structure B: Before/After Transformation

Frame the entire case study as a transformation story. What was broken, what you did, what changed.

When to use: Redesigns, optimization projects, projects with clear metrics improvement.

Example pattern:

• The situation before (with evidence)
• The core tension or constraint
• The key moves you made (2–3, not 12)
• The after state (with evidence)
• What you'd do differently

Structure C: Decision Log

Walk through the 3–5 most consequential decisions in the project. For each, explain the context, the options considered, the tradeoffs, and why you chose what you chose.

When to use: Senior/Lead roles where demonstrating judgment matters more than showing wireframes. Projects with ambiguity and competing priorities.

Example pattern:

• Project context + your role (brief)
• Decision 1: framing + options + choice + outcome
• Decision 2: ...
• Decision 3: ...
• Cumulative impact

Reference: Joel Califa's DigitalOcean Design Leadership case study operates this way — it walks through hiring, performance, design reviews, trust-building, and design studios as a series of strategic decisions, each with context and rationale.

Structure D: Zoom-In

Start with the big picture, then progressively zoom into one specific area where you did your most interesting work. Go deep rather than wide.

When to use: Large projects where you owned a specific surface. Projects where depth of craft matters more than breadth of process.

---

Writing Principles

Lead with context, not process

Before describing what you did, establish why it mattered. What was the business situation? What were the constraints? What was at stake? A hiring manager evaluates your entire case study through the lens of the context you set.

Critical distinction: If the project was a school assignment or speculative redesign, say so. If it was a real product with real constraints, explain those constraints. Hiring managers calibrate expectations based on this context. Unconstrained projects should produce exceptional output; constrained projects earn credit for navigating tradeoffs.

Show the thinking between steps

The most common failure in case studies is disconnected steps — research findings that don't visibly influence the design, user quotes that float without connecting to decisions. Every transition should answer: "Because we learned X, we decided Y."

Focus on insights, not activities

"We conducted 8 user interviews" is an activity. "We discovered that 73% of users were building workarounds in spreadsheets because the tool couldn't compose cross-source calculations" is an insight. Activities are boring. Insights are memorable.

Test: Would someone feel compelled to highlight a sentence from your case study? If not, the writing is too procedural.

Write short

After writing the first draft, cut it by 30%. Then cut again. Short paragraphs. Short sentences. If a section can be replaced by a visual, replace it.

Hiring managers scan. They do not read word by word on first pass. Your headings alone should tell a coherent story.

Be specific, not corporate

"Improved the user experience" means nothing. "Reduced onboarding drop-off from 67% to 31% by replacing the 8-step wizard with a progressive disclosure pattern" means everything.

Use your own voice. If the writing could appear in any designer's portfolio without modification, it's too generic.

Talk about what went wrong

Acknowledge failures, pivots, things you'd do differently. This signals maturity and self-awareness — qualities hiring managers value highly in senior candidates. A case study that presents a frictionless process is either dishonest or boring.

State your opinions

Designers with a clear point of view produce more interesting case studies. Don't hedge. If you believe something about the problem space, say it directly.

Clarify your contribution in team projects

One of the most common ambiguities hiring managers flag: they can't tell what you specifically did. Avoid this by separating team outcomes from personal decisions throughout — not just in a role description box at the top.

The pattern that works: use "we" for shared team actions and outcomes, "I" for specific decisions, choices, and moments of judgment.

• Too vague: "We conducted research and identified three key insights that shaped our direction."
• Specific: "We ran eight interviews over two weeks. I made the call to discard the persona framework after session three — the user segments were more homogeneous than we'd assumed, and the framework was adding overhead without adding precision."

The goal isn't to claim credit aggressively. It's to give hiring managers something concrete to ask about in the interview. Every "I" statement is a potential conversation starter. Vague "we" statements are conversation enders.

For solo/freelance work, the same principle applies in reverse: be honest about the absence of a team when that's the case. "I was the only designer" is a signal of scope and autonomy, not a weakness.

---

Visual Execution

The visual quality of the case study itself is a design deliverable. A UX-focused designer is not excused from making the case study beautiful. Visual craft communicates that you care about your work.

Image and visual guidelines

• Use large images. Small thumbnails prevent readers from evaluating your craft. Full-width or near-full-width visuals.
• Only show work you're proud of. You do not need to include every deliverable. Omit weak artifacts even if they were part of the process.
• Re-create deliverables if needed. Post-project, redesign your artifacts so they're consistent throughout the case study and effectively communicate your points.
• Include motion and prototypes. Video walkthroughs and prototype recordings are dramatically more effective than static screens. A prototype is worth a thousand static artboards.
• Design the reading experience. The scroll rhythm, the pacing of text and visuals, the whitespace — treat the case study page itself as a design project. It should feel like flipping through a magazine feature.
• Never let the tool dictate the aesthetic. A Notion export, a Medium post, or a Google Doc has the visual identity of the tool, not of you. If your case study looks identical to every other Notion page on the internet, the presentation itself undermines your credibility as a designer. The writing platform is a drafting tool. The final output must be designed — whether that means a custom HTML page, a Webflow build, a carefully styled Notion layout, or a polished PDF.

The 30-second scan test

A hiring manager will scan your case study in 30 seconds before deciding whether to read further. In that scan, they should absorb:

1. What the project was (clear headline/intro)
2. Whether the output quality meets their bar (strong visuals, visible early)
3. Whether you had a real role with real impact (role + outcomes, stated upfront)

If any of these are unclear in a 30-second scroll, restructure.

---

Anatomy of Strong Case Study Sections

The Opening (first screen)

The opening must do three things immediately:

1. Identify the project and your role — one or two sentences maximum
2. Establish the stakes — why this project mattered to the business or users
3. Signal quality — a strong visual, a compelling metric, or a bold statement

Avoid lengthy company descriptions. One sentence of context is enough. The reader should understand what they're about to read and why it's worth their time within 5 seconds.

Role and results metadata should be visible immediately — not buried. State your specific role (not just "UX Designer"), the team composition, timeline, and 2–3 headline outcomes. This is not boasting; it's context that helps hiring managers calibrate.

The Problem / Context Section

Frame the problem through the lens of specific evidence — user quotes, data points, observed behaviors. Avoid abstract problem statements ("users needed a better way to..."). Ground every claim.

A strong framing technique: present the problem as a tension between two forces (user needs vs. technical constraints, business goals vs. user experience, speed vs. quality). Tensions are inherently interesting.

The Middle (Process + Decisions)

This is where most case studies become generic. Avoid:

• Listing process steps without explaining why each was necessary
• Including research methods without sharing what they revealed
• Showing wireframes without explaining what drove the layout decisions
• Describing iterations without explaining what changed and why

Instead, every section should contribute an insight or demonstrate a decision. If a section doesn't do either, cut it or merge it.

The Solution / Output Section

Many case studies describe the process in great detail only to conclude with underwhelming solutions. The output is the climax. Give it proportional weight.

• Show the solution in context (real devices, real scenarios)
• Explain how specific design decisions connect back to insights from earlier sections
• Include interaction details, edge cases, states — not just the happy path
• If possible, show quantitative results

The Reflection / Outcomes

End with what changed — for users, for the business, for you. Include metrics where available, even directional ones. Then add what you learned or would do differently. This is the section that separates senior designers from junior ones.

---

Adapting to Channel

The same project may need different versions for different channels.

Portfolio website: Full case study. Process, output, reflection. Visual-heavy. This is the canonical version.

Medium / blog: Rewrite to focus on transferable insights other designers can use. The audience is there to learn, not to evaluate you as a candidate. Teach something.

Dribbble / Behance: Visual highlights only. The best UI moments, with minimal context. These platforms don't support long narratives.

LinkedIn: Focus on business impact and strategic framing. LinkedIn readers care about outcomes, leadership, and industry relevance.

Presentation / interview format: See the section below.

---

Translating the Written Case Study to a Verbal Interview

The written case study and the interview story are not the same thing — but one should prepare you for the other. Hiring managers often ask you to walk them through a case study live. Designers who haven't thought about this translation tend to either read from memory (too rigid) or improvise without structure (too scattered).

The compression map

A 2,000-word written case study should compress to a 5–7 minute verbal story. The mapping:

Written section	Verbal equivalent	Target time
Opening / context	One or two sentences: what the product was, what your role was, what was at stake	30 sec
Problem framing	The tension or constraint that made this hard	30–45 sec
Key decision(s)	Two, maximum three decisions — each with context, options, and your reasoning	2–3 min
Output	What you shipped — described, not walked through screen by screen	30–45 sec
Outcome + reflection	What changed, what you learned	30–45 sec

The most common mistake: spending too much time on context and process, then rushing the decisions and outcome. Invert it. The decisions are the substance.

How to identify the right decisions to tell verbally

From your full case study, extract the 2–3 moments where:

• You had genuine options and chose deliberately
• Something unexpected forced a pivot
• You pushed back on a brief, a stakeholder, or your own earlier thinking
• The risk of being wrong was real

These are your verbal story. The rest is available if they ask.

Handling "tell me about your process"

This is an invitation to tell a story, not recite a methodology. Resist the impulse to describe what steps you followed. Instead, anchor to a specific decision or moment: "The most interesting part of the process on this project was when we realized the thing we'd been asked to design was actually the wrong problem..."

If the interviewer genuinely wants to know which methods you used, they'll ask. Lead with judgment, not process vocabulary.

The written case study as interview prep material

Before an interview, re-read your own case study and ask:

• What are the three questions this case study most likely to generate?
• What is the one thing I want them to walk away remembering?
• What would I have done differently — and why?

Prepare answers to all three. The best interview performances feel like a conversation about work the designer actually cares about — not a rehearsed presentation of a portfolio piece.

---

Common Failures to Avoid

1. The checkbox parade: Research → Personas → Journey Map → Wireframes → Designs. Every case study using this structure looks identical. Structure around insights, not process phases.

2. The missing connection: Research findings that don't visibly influence design decisions. If you can remove the research section and the design section still makes the same sense, the sections aren't connected.

3. The underwhelming climax: Detailed process followed by predictable, unpolished output. If the final designs don't impress, the process description can't save them.

4. The absent voice: Writing so generic it could belong to anyone. No opinions, no personality, no point of view. The case study should feel unmistakably yours.

5. The everything bagel: Trying to include every deliverable and every step. Curation is a skill. Omit mercilessly.

6. The context vacuum: Jumping into process without establishing what kind of project this was, what constraints existed, or what your actual role was. Hiring managers will assume the worst if you don't specify.

7. Metrics without context: "Increased conversion by 40%" means nothing without the baseline, the timeframe, and what else was changing simultaneously. Contextualize every metric.

8. The Notion export: A Notion page exported as-is is not a portfolio-ready case study. Default typography, emoji section headers (🚨 🎯 🧩 🚀), and zero visual hierarchy signal that you didn't invest design attention in your own presentation. Notion is fine as a writing tool. The output needs to be designed before it represents you. This applies equally to raw Medium posts, Google Docs exports, and any other tool that produces default-styled output.

9. The emoji-header substitute: Using emoji as pseudo-icons before every section heading (🔍 Problem, 🎨 Design, 📊 Impact) is the 2025 equivalent of the bootcamp template. It creates the illusion of visual structure without any actual design. Replace emoji headers with insight-driven sentences that tell the story. "The Design Challenge" is generic. "Biomedical researchers drown in literature — and search engines make it worse" is a point of view.

10. The annotated screenshot gallery: If your case study has fewer than 500 words of substantive writing (excluding captions, labels, and headers), it's a feature gallery, not a case study. A hiring manager scrolling through screenshots with one-line captions learns what you made but nothing about how you think. Either deepen the writing or merge the work into a larger case study where it can be properly contextualized.

---

Output Format Guidelines

When creating the actual case study content, adapt to the requested format:

Markdown (for Notion, portfolio sites, etc.)

• Use heading hierarchy intentionally — H1 for project title only, H2 for major narrative beats, H3 sparingly for subsections
• Include image placeholders with descriptive alt text and sizing notes
• Use horizontal rules to create visual breathing room between sections
• Keep paragraphs to 2–3 sentences maximum
• Use blockquotes for user quotes or key callouts

HTML / Web

• Design the reading experience: generous whitespace, large typography, full-bleed images
• Consider scroll rhythm — alternate between text-heavy and visual-heavy sections
• Include sticky navigation or progress indicators for long case studies
• Optimize for both desktop and mobile reading

Word Document (.docx)

• Use consistent heading styles for navigation
• Include a table of contents for longer case studies
• Embed images at readable sizes
• Use callout boxes for key insights, quotes, and metrics

Presentation

• One idea per slide
• Maximum 3 bullet points per slide, each under 10 words
• Full-bleed images where possible
• Speaker notes carry the narrative; slides carry the visuals

---

Data-Heavy & Observability Product Calibration

Designing for analytics dashboards, monitoring tools, observability platforms, and data products introduces challenges that generic case study advice doesn't cover. Hiring managers in this space look for a specific set of signals.

What this space actually cares about

Information density vs. clarity tradeoffs. Data products live in a permanent tension between showing everything (what power users want) and showing the right thing at the right time (what drives correct decisions). Show that you understand this tension and made conscious tradeoffs — don't just present the final design as though the answer was obvious.

Designing for expert users. The standard UX principle of reducing cognitive load applies differently when your users are analysts, engineers, or domain experts who want density and depth. Explain how you thought about your user's expertise level. A dashboard designed for a junior analyst and one designed for a senior SRE are fundamentally different artifacts.

Making invisible behavior visible. Observability and monitoring tools are fundamentally about representing system state — data that has no inherent visual form. Show how you translated abstract signals (logs, metrics, traces, model outputs, query performance) into something that allows a human to act quickly and with confidence. This is the core design problem of the domain.

The query-to-insight path. In data products, the journey from "I have a question" to "I have an answer I trust" is the primary user experience. Map it explicitly. Where does it break down? What did your design do to compress or clarify it?

Working at the intersection of data engineers and end users. Case studies for these roles should demonstrate that you understood both the data model and the user's mental model — and that you helped close the gap between them. Show collaboration with data/engineering stakeholders, not just UX research.

What to show

• Before/after of a complex data view — with annotations explaining why specific information hierarchy decisions were made
• Evidence of user mental models around data interpretation (not just task flows)
• Any work that reduced time-to-insight, error rates, or miscommunication of data meaning
• How you handled edge cases: empty states, error states, data lag, partial data — these are the moments that distinguish thoughtful data product design from surface-level work
• If relevant: how the design supports different levels of analysis depth (overview → drill-down → raw data)

Language that resonates in this space

Hiring managers for observability and analytics roles respond to: information architecture, signal-to-noise ratio, progressive disclosure, data literacy, time-to-insight, query latency, alert fatigue, dashboard sprawl, mental model alignment, schema abstraction. Use the domain's language — it signals fluency, not just familiarity.

---

B2B Product Calibration

B2B design has its own logic that differs meaningfully from consumer product design. Hiring managers at B2B companies look for different signals.

Stakeholder complexity is the real UX problem. In B2B, the buyer and the user are rarely the same person. The person who approves the tool is often not the person who uses it daily. Show that you navigated this — how you balanced the needs of procurement, IT, administrators, and end users simultaneously.

Metrics look different. Consumer UX metrics (engagement, retention, NPS) translate poorly to B2B. The relevant metrics are: time-to-value for new accounts, support ticket deflection, task completion in high-stakes workflows, contract renewal signals, onboarding completion. If you have any of these, use them. If you don't, describe the behavior change you were designing for.

Enterprise constraints are design inputs, not excuses. Security requirements, compliance constraints, integration limitations, legacy system dependencies — in B2B these are real. Naming them and showing how your design navigated them is more impressive than a clean concept that ignores them.

The sales cycle as context. In B2B, design often influences whether the product gets sold, not just whether it gets used. If your work supported a demo, a trial conversion, or a procurement evaluation, that's worth stating.

---

Senior / Lead Level Calibration

For experienced designers (10+ years), case studies should signal seniority without leaning on years of experience as the primary credential. The effective approach:

• Lead with outcomes, not tenure. Concrete results establish credibility more effectively than a timeline.
• Show systems thinking. How your work connected to broader product strategy, organizational structure, or business model.
• Demonstrate influence beyond your direct scope. Stakeholder alignment, cross-functional collaboration, mentorship, process improvements.
• Include the "why not" reasoning. Explaining what you considered and rejected demonstrates judgment depth.
• Be comfortable with ambiguity. Senior work often involves unclear requirements, competing priorities, and imperfect information. Show how you navigated that.
• Use the founding/first-designer angle when it applies. If you were the first or only designer at a company, that's an inherently compelling narrative — building from zero, making product bets with limited data, shaping the design culture. Don't bury it. "I was the founding designer at an AI biomedical research platform" opens a fundamentally different story than "I was a senior product designer at Causaly." The founding context implies scope, autonomy, and risk that a feature-level case study doesn't convey.

---

Handling Confidential & NDA-Restricted Work

Senior designers often find that their strongest work is under NDA. This is a real constraint but not an excuse to exclude the work entirely. Strategies for presenting restricted work:

State the constraint upfront. "This case study uses only publicly available materials and reconstructed flows" is honest and immediately calibrates expectations. Hiding the restriction and hoping nobody asks is worse than naming it.

Show what you can: Anonymized user flows (replace brand names, remove proprietary data), reconstructed screens built post-engagement to illustrate the design approach without revealing production UI, outcome metrics stated directionally ("increased completion rate by ~30pp") without attribution, and narrative descriptions of your decision-making process — which is rarely itself confidential.

Lead with the problem and thinking, not the screens. For NDA work, the Decision Log structure (Structure C) is particularly effective. The reasoning behind your choices is yours to share even when the screens are not. A well-told story about confidential work — with clear stakes, specific decisions, and honest reflection — is more valuable than a detailed walkthrough of unrestricted work that was less impressive.

Use the restriction as a framing device. "I can't show the production UI, but here's what made this problem hard..." creates intrigue rather than apology. The reader leans in because the constraint implies the work was significant enough to protect.

Never fabricate or embellish. If you can't show real metrics, say "metrics are under NDA" rather than inventing plausible numbers. Hiring managers have finely tuned BS detectors.

---

Portfolio-Level Strategy

Individual case study quality matters, but portfolio composition — what you include, what you exclude, and how pieces relate to each other — determines the overall impression.

How many case studies?

Three to five is the effective range. Hiring managers review 1–2 per portfolio. Having more than five creates decision paralysis and dilutes the strongest work. Having fewer than three feels thin. The goal is: every piece in the portfolio could independently get you an interview. If a case study wouldn't, cut it.

Depth over breadth

Two deeply-told case studies will always outperform six shallow ones. A portfolio full of annotated screenshot galleries signals surface-level engagement with every project. A portfolio with two richly-narrated pieces and one shorter supporting piece signals someone who goes deep.

Combining related work

Multiple projects at the same company can often merge into a single, stronger case study. Two 800-word pieces about different features of the same product are weaker than one 1,500-word piece that tells the story of your tenure and cumulative impact. This is especially effective for senior designers who want to show sustained influence rather than isolated feature work.

When to combine: Same company, related problem space, your role was consistent across both. The combined piece should read as one arc with chapters, not two case studies stapled together.

When to keep separate: The projects target different portfolio audiences (e.g., one is a research piece, the other is a systems design piece), or the work is so distinct that combining them would create a confused narrative.

Domain coherence vs. range

Tailor the portfolio to the role. Applying for a fintech position? Lead with fintech case studies. Applying for an ed-tech role? The analytics dashboard work goes first, and the crypto custody work goes last or gets omitted. A portfolio curated for domain fit signals intent and reduces the cognitive load on the hiring manager.

This doesn't mean eliminating all variety — one case study from an adjacent domain can demonstrate range. But the first piece the hiring manager sees should feel like a direct match to the role they're hiring for.

Ordering strategy

Put your strongest, most relevant case study first. The second position goes to the piece that demonstrates the most complementary skill. The rest are supporting evidence, not starring roles. Most hiring managers won't reach case study #4.

What to retire

Every portfolio benefits from periodic culling. Remove a case study if: it's visually weaker than the rest, it targets an audience you're no longer pursuing, the work no longer represents your current skill level, or it duplicates the strengths of a stronger piece already in the set. Archiving work is not admitting it was bad — it's acknowledging that your portfolio is a curated argument, not a complete record.

---

Process: How to Work With the User

When a user asks for help with a case study, follow this sequence:

0. Assess portfolio context (if reviewing existing work)

If the user has multiple case studies or asks for a portfolio review, evaluate at the portfolio level first:

• How many pieces exist and what is the quality distribution?
• Are there thin pieces that should be merged or retired?
• Does the portfolio have domain coherence for the target role?
• Are there raw Notion/tool exports that need to be designed?
• Is there a flagship piece that could anchor the portfolio?
  Address portfolio-level strategy before diving into individual case study edits.

1. Gather raw material

Ask about or extract from provided files:

• Project context (company, product, timeline, team)
• The user's specific role and responsibilities
• Key decisions and turning points
• Research findings or user insights
• Constraints and tradeoffs
• Outcomes and metrics (even directional)
• What the user learned or would do differently
• Target audience and format

2. Identify the narrative spine

Based on the raw material, recommend a narrative structure (from the options above or a custom hybrid). Identify the single most memorable element and build toward it.

3. Draft with voice

Write in the user's voice — concise, direct, specific. No filler. No corporate speak. Every sentence should earn its place.

4. Iterate on structure before polish

Get the story arc right before worrying about word-level refinement. The structure determines whether the case study is interesting; the writing determines whether it's pleasant.

5. Visual direction

Recommend image placement, visual hierarchy, and any prototype / motion opportunities. Specify what should be shown large, what can be omitted, and where visual breaks should occur.

---

Reference: What Hiring Managers Actually Look For

Based on research with 30+ hiring managers at mid-to-large companies:

• 40+ portfolios reviewed per open position
• 1–2 case studies read per portfolio (they don't review everything)
• 30 seconds initial scan before deciding to read further
• Final designs first — most hiring managers jump to output quality before reading process
• Process only if output impresses — they read backward from the solution
• Biggest frustration: extreme focus on process at the expense of output quality
• Strongest signal: a designer who can both think and deliver, not one or the other