Writing honest case studies when nothing was measured

When nothing was measured, an honest UX case study says so once, plainly, and then labels precisely what did happen: handed off, merged, released, reported in use. Commits and pull requests are activity, not outcomes. A clear status vocabulary, dated and sourced, makes a product design portfolio more credible than an invented percentage, because a reviewer can check every claim against what you're actually showing.

None of my case studies has a measured outcome. That isn't unusual for a designer at a small product company with no analytics on the features I worked on. What follows is how I write about that, and the rules I set myself for this site.

Why most UX case studies overclaim

The usual template asks for "Impact" at the end, and there's pressure to fill it. So people write "improved efficiency by 40%" with no baseline, method or time window. Reviewers have seen hundreds of these. A round, high number that doesn't connect to the design shown reads as a red flag, not a result.

The quieter overclaim is the verb. "Shipped" can mean a Figma page marked ready, code on a branch, or a feature every customer uses daily. "I built" can mean I built it, or I designed it and an engineer built it. These blur together, and the reader can't tell which you mean.

Why commits aren't outcomes

As a designer who also writes frontend code, I'm tempted to count things the repository can count: commits, merged changes, lines. They're real, and they're easy to chart. But they answer the wrong question.

• They measure effort, not effect. Ten commits can be ten fixes for one bad decision.
• They reward noise. Splitting work into smaller commits doubles the number and changes nothing for users.
• They leak. Commit messages, branch names and ticket numbers are internal detail about how an employer builds software.

So I don't show commit or pull-request counts anywhere, and I don't put ticket numbers, hashes or release tag strings on the site. I say "a tagged release in September 2026", which tells a reader what they need.

A status vocabulary for design portfolios

Every case on this site carries one or more of these labels, each with a date and, where it matters, a source.

Label	Means	Doesn't mean
Design handoff	The design was marked ready for development or handed to an engineer	Built, reviewed or tested
Merged to production	The code was merged into the production line, on a date	Every customer has it, or uses it
Tagged release	It's included in a named release	Adoption, or anyone noticing
In use (first-party report)	Someone inside the company told me it's being used, and I say who	Independent verification or a number
Measured outcome	A metric with a method, a period and a denominator	Anything else. "None" is a valid entry

Two more labels sit outside that ladder: Concept, paused for work that never became a product, and Work in progress for designs still being explored.

The labels stack, and none implies the next. Bulk Import has a Design handoff before June 2026, then Tagged releases in July and August, built by the senior frontend engineer. Cash sessions has Merged to production in June 2026 and In use (first-party report). Myra is a concept, paused: no app was released.

How to write "Measured outcome: none"

Once, in the results section, without apology. Then do the three things that make the absence useful.

1. Say what you do have, and where it came from. For cash sessions, the feedback I can cite came through one channel:

Properly used by real shops.

Reported to me by the CEO

That's real, and it's useful, but it's informal and second-hand, so it's labelled as exactly that and nothing more.

2. Make the claim as narrow as the evidence. For Bulk Import I don't write "removed the trip back to Excel". I write that supported errors are repaired in the product before posting, and that some problems still start in the file.

3. Name what you'd measure first, and why. For Bulk Import: whether the same file is uploaded again within a day, because that's the proxy for the main claim. For the backup page: how often people leave and come back, and how many emailed links expire unused. Research reviewers read this as method; hiring managers read it as product sense.

How do you show employer work in a UX portfolio?

Ask, and agree the scope

I asked first. BIC Technology, the company behind Tigg, allowed product screens. That permission didn't extend to everything else that comes with a codebase, so I set the boundary myself: product behaviour, UI states, microcopy and design reasoning are on the site; ticket numbers, code, file paths, internal tool names and anything that would help a competitor are not. Teammates appear by role: the CEO, the senior frontend engineer, QA.

Reconstruct instead of blurring

Where I don't yet have a clean screenshot, I redraw the screen with fictional data and label it as a reconstruction: "the old validation screen, redrawn; the labels are the real ones; the file name, counts and messages are fictional." Advice differs here. Nielsen Norman Group lists blurring identifying details as one option, alongside showing process and recreating designs generically. The Interaction Design Foundation advises against blacking out parts of a case study, because it can still breach an agreement and it hurts credibility. I side with reconstruction: it's clearer to read and safer to publish.

Label every image

Every figure on this site has a provenance: screenshot, Figma, reconstruction, exploration, diagram, chart or photo. An exploration is never presented as the final design, and a reconstruction is never presented as a screenshot.

Credit: use exact verbs

The most common credibility problem in portfolios is unclear contribution. I use three verbs and stick to them:

• "I designed and built": cash sessions on web, the POS side of batch and serial tracking, the backup page.
• "I designed; the senior frontend engineer built": Bulk Import. Decisions my frames didn't cover are credited to them by name of role.
• "Proposed, not shipped": the next steps at the end of each case.

Being the only designer at Tigg makes this easier to say and more important to say carefully. I write about that role in being the only designer on a product team.

A checklist for honest case study writing

• A status label on every case, with a date and a source.
• "Measured outcome: none" stated once, where results go.
• Feedback quoted with its channel ("reported to me by the CEO").
• No commit, PR or ticket counts as evidence.
• Exact verbs for who designed and who built.
• Permission obtained, and its scope respected.
• Every image labelled; reconstructions use fictional data.
• Research numbers shown with their sample and limits (see consent-first sharing).
• A "what I'd measure" line for every claim you can't prove.
• No invented interviews, participants or quotes, ever.

Does this make a portfolio weaker?

I don't think so. The cases read smaller than they might, and the claims are easier to defend in an interview. For graduate admissions, where readers look closely at method, an honest limits section is evidence of the research habit they're looking for. My research page is written the same way.

References

• Rachel Krause, 5 Steps to Creating a UX-Design Portfolio, Nielsen Norman Group.
• Yu Siang Teo, How to Handle Non-Disclosure Agreements (NDAs) When You Write Your UX Case Study, Interaction Design Foundation.