Write a UX case study without inventing metrics.

Start with the project status, not a success headline

A case study without business metrics can still explain a useful piece of design work. Its job is to make your reasoning inspectable, not to imitate a launch report. Begin by identifying whether the work is a self-initiated concept, a school assignment, an internal proposal, or a released product. State your role and the information you could access. A prototype and a production service support different kinds of claims.

Separate what you made from what changed for people. A revised navigation structure is an output. Evidence that people found something more easily is an observation requiring a suitable study. Increased retention is a different claim requiring product data and careful interpretation. Do not let those categories blur together.

Make a claim ledger before editing the story

Copy every sentence containing an achievement into a small ledger. Give each sentence a source, a boundary, and an action: keep, narrow, relabel, or remove. Sources might include a dated design version, your own decision notes, approved usability notes, or an authorised analytics report. A polished screenshot is evidence of a design output, not evidence of customer satisfaction. If a source is missing, do not repair the gap with a plausible number.

• Output: identify the actual artifact and the part you personally contributed.
• Observation: record the task, context, and evidence behind the statement.
• Interpretation: explain the reasoning and any competing explanations you considered.
• Proposal: use future language and state what would need to be checked.

Replace vague impact with an inspectable decision

Choose a decision that a reader can inspect without taking your word for it. Show the relevant earlier state, the problem you identified, an alternative, and the reason for your choice. Annotate the exact element rather than presenting an entire screen at unreadable scale. If the concern came from your own review rather than participants, name it as an expert judgment or design assumption, not a user finding.

Put limitations next to the evidence

When you do have qualitative material, describe its context. Explain how participants were recruited, what they attempted, and what the prototype could not do. A convenience sample is not representative of every potential customer. An assisted attempt is not an independent completion. Quotes illustrate a perspective; they do not establish how common that perspective is. Do not turn a small set of comments into a percentage presented as product performance.

Publish only material you have permission to share. Remove identifying details, but remember that a recognisable situation can identify someone even without a name. Do not upload recordings, sensitive screenshots, or raw transcripts to a public portfolio, shared design board, or unapproved AI service. Withhold evidence when safe disclosure is uncertain.

End with a measurement plan, not an imaginary result

A useful next step specifies the question, method, and decision it would inform. For the hypothetical pickup concept, a future usability task could ask someone to explain where and by when they would collect a book. Before running it, define how you would distinguish independent understanding from moderator help. Record any protocol changes. This is a plan, not evidence that the proposed design works.

If the work later ships, agree on data access, privacy, a baseline, and the observation period with the responsible team. Consider other changes that could affect results before attributing an improvement to design. Until then, finish with what exists now, what remains uncertain, and the smallest useful check. Honest scope is more informative than a confident but unsupported impact sentence.