Can I include a case study if the client won't share results data?

Yes. Focus on the problem, your process, and your reasoning. Clearly state that post-launch data wasn't available to you, and describe what you would measure. Process-focused case studies are legitimate and often more revealing than result-only summaries.

Is it acceptable to estimate or infer outcomes?

Only if you label them as estimates or expectations, not measured facts. Write 'we anticipated this would reduce drop-off' rather than 'this reduced drop-off by X%'. The label is what separates honest inference from fabrication.

How do I handle confidential projects I can't fully show?

Describe the problem and your approach in general terms without exposing proprietary details. You can obscure brand names, blur sensitive screens, or use anonymised examples — just note clearly that you've done so and why.

Should I ask the client for a testimonial to strengthen the case study?

Only if you can quote them accurately and with their permission. A vague reconstructed quote is worse than no quote. If they won't provide one, a factual description of the working relationship (duration, scope, repeat engagement) carries similar weight.

How long should a portfolio case study be?

300–600 words of body copy is a reasonable target for most web design projects. Longer is only justified if the project scope genuinely requires it. Prioritise clarity over completeness — readers rarely finish long case studies.

Writing a Portfolio Case Study Without Inventing Results

Why Honest Case Studies Outperform Inflated Ones

Many designers feel pressure to show dramatic numbers: '300% more conversions', 'revenue doubled in a month'. The problem is that most project teams never isolate design as the single cause of a result, and clients who ask probing questions will notice when you can't back up the claim. A case study that accurately describes what happened — and is clear about what you don't know — signals professional maturity, not weakness.

Recruiters and prospective clients read dozens of portfolios. Vague superlatives blur together. Specific, honest accounts of constraints and trade-offs are memorable and credible.

Start With the Problem, Not the Deliverable

Open every case study by stating what was actually wrong or needed. The deliverable (a new homepage, a checkout redesign) is secondary. A reader should understand the business or user problem before they see a single screenshot.

State who had the problem and why it mattered to the business.
Note any hard constraints: timeline, budget, technical stack, stakeholder sign-off requirements.
Keep this section to two or three sentences — precision beats length here.

Fictional example (clearly labelled): 'Fernway Kitchens [fictional] needed a quote-request flow that worked on slow rural broadband connections. Their existing form abandoned at roughly 60% on mobile, according to their own analytics — but they had no budget for a full rebuild, only a four-week dev sprint.'

Define Your Individual Role Precisely

Avoid the word 'we' for every verb. Readers want to know what you specifically did, not what the team did. Being clear about your scope also protects you — you're not claiming credit for work that wasn't yours.

Name your actual role: UX lead, visual designer, front-end developer, project manager.
List what you owned versus what you collaborated on versus what others handled.
If you inherited constraints or decisions made before you joined, say so.

Describe Your Approach, Not Just Your Output

Screenshots and mockups show what you made. The case study should explain why you made those choices. Walk through your reasoning: what you tried first, what you discarded, what informed each decision. This is where your thinking — the thing that can't be copied from a template — becomes visible.

Include methods used (user interviews, card sorting, A/B testing, heuristic review) and note how many people you spoke to if you ran research. 'Five interviews with existing customers' is more credible than 'extensive user research'.

Separate Three Types of Evidence

This is the most important discipline in case-study writing. Label your evidence honestly across three distinct categories:

Measured outcomes — data that was tracked before and after, with a defined methodology. Example: 'Form completion rate rose from 41% to 58% in the eight weeks after launch, measured via the same analytics setup used pre-launch.'
Observations — things you or the team noticed that weren't formally tracked. Example: 'Support staff reported fewer calls about the quote form in the month after release, though call volume wasn't logged systematically.'
Untested expectations — what you hoped or predicted would happen but have no data for. Example: 'We expected the simplified field order to reduce cognitive load, though we didn't run follow-up usability testing to confirm this.'

Mixing these three without labels is where most portfolios go wrong. Stating expectations as results is a form of fabrication, even if unintentional. Keeping them separate shows you understand the limits of your own evidence.

What to Do When You Have Almost No Data

Many freelance and agency projects end at handoff, before any meaningful data exists. That's fine — just say so. You can still write a credible case study by focusing on process evidence: documented research, design decisions with rationale, stakeholder feedback received, and what you'd measure if you had access to post-launch analytics.

Fictional example: 'The client had not set up conversion tracking before launch. I've listed the goals we designed toward and would track form start-to-submit rate, time on form, and mobile drop-off rate as the primary indicators — but I don't have access to that data.' That's honest. It's also more impressive than a made-up percentage.

Keeping It Compact and Readable

A portfolio case study is not a dissertation. Aim for 300–600 words of body text, supported by three to six images or prototypes. Use a consistent structure across all entries so readers can scan your portfolio quickly. Suggested sections: Problem → Constraints → My Role → Approach → Evidence → What I'd Do Differently.

Cut anything that doesn't help the reader understand your thinking or the outcome.
Don't include testimonials you've paraphrased from memory — either quote exactly with permission or omit.
A 'what I'd do differently' note shows self-awareness and often impresses more than a perfect-sounding result.