Preparing a UX Design Portfolio Case Study

Select the right project

Start from the role and capabilities the reviewer needs to assess, such as interaction design, research judgment, systems thinking, visual craft, or cross-functional leadership. Choose a project with consequential decisions and enough evidence to explain them. A famous brand is less useful than work whose reasoning you genuinely own.

Confirm what you may disclose. Remove personal data, internal strategy, unreleased screens, credentials, and confidential metrics according to agreements. Replace sensitive details only when the substitution preserves meaning, and label reconstructed, redacted, or hypothetical material. Never imply that altered data is a verified product result.

Frame context and contribution

Open with product, audience, problem, project stage, constraints, team, duration, and outcome sought. Then state your responsibilities and decision authority. Avoid 'we' so consistently that reviewers cannot tell what you did, or 'I' so broadly that collaborators' research, code, content, and strategy disappear.

Explain the starting evidence and uncertainty. Show why the team worked on this problem and which assumptions remained. A dramatic problem statement without source or context looks polished but prevents evaluation of judgment. Include constraints that materially shaped the design rather than listing every organizational difficulty.

Tell a decision story

Organize around a few important decisions instead of every workshop and artifact. For each, show the question, evidence, alternatives, tradeoff, choice, and change after feedback. Include sketches, flows, content, states, prototypes, or system details only when they help the reviewer understand that reasoning.

Show iteration by explaining what changed and why. Side-by-side screens without evidence can become a visual spot-the-difference exercise. Include errors, accessibility, responsive behavior, and technical collaboration where relevant to the role. Do not present a standard design-process diagram as proof that each method was necessary or rigorous.

Report outcomes and reflection

Use outcomes you can verify, with definitions, timeframe, and attribution limits. If no product metric exists, report usability evidence, shipped scope, operational learning, or decision impact honestly. Do not invent percentages, imply revenue causation, or claim adoption because a feature launched. Label all sample numbers as hypothetical.

Reflect on what worked, what did not, what you would change, and which question remains. Specific reflection shows judgment better than a claim that the project taught collaboration. End with the final experience and your current assessment, then make navigation and text readable for hurried reviewers and keyboard users.

Outline a hypothetical scheduling case study

Hypothetical designer improved shift-swap review for restaurant managers but has no verified business metric.

1. Frame the hypothetical manager problem, team, constraints, designer contribution, and evidence from recent swap attempts.
2. Select two decisions about coverage context and approval confirmation, showing alternatives and usability observations.
3. Present final normal, error, keyboard, and responsive states while crediting engineering and research collaborators.
4. Report verified task evidence only, label every sample number hypothetical, and reflect on missing longitudinal outcome data.

Portfolio case-study outline

Use this structure to create a concise, truthful review path.

• Role target, capability demonstrated, project relevance, disclosure permission, redactions, and hypothetical labels.
• Product context, audience, problem, evidence, constraints, team, duration, responsibility, and decision authority.
• Decision question, alternatives, research or data, tradeoff, choice, iteration, contribution, and collaborator credit.
• Final flow, content, states, responsive behavior, accessibility work, technical handoff, and shipped scope.
• Verified outcome, definition, timeframe, attribution limit, unresolved question, reflection, and current assessment.

Common mistakes

• Showing every process artifact while leaving the consequential design decisions and personal contribution unclear.
• Inventing product impact or presenting hypothetical numbers as measured outcomes to make the project sound stronger.
• Publishing confidential customer, company, or unreleased product information without explicit permission.

Try one

Sources

• Nielsen Norman Group UX portfolio guideGuidance on selecting portfolio work and explaining process, contribution, and outcomes.
• Nielsen Norman Group portfolio case-study guidanceGuidance on writing scannable UX case studies with context and evidence.