How to Write a Design Case Study When You Cannot Share Metrics

Say what kind of evidence you do have

You may have research findings, design critique, usability observations, implementation checks, or a documented handoff. State the source and scope: who participated, what task was studied, what environment was used, and what the method could not establish. If you only inspected the prototype yourself, do not call that user testing.

Describe the result you can verify

A shipped component, a revised workflow, a documented design system, or a decision adopted by the team can be an outcome. Name what changed and how you know it happened. If post-release behavior is unknown, say that plainly and avoid implying the work improved a metric.

Use a clear limitation statement

Example wording

“The revised request flow was handed to engineering and released. I did not have access to post-launch completion data, so I cannot claim that it increased submissions. I would compare completion and validation errors for the same audience and period if that data became available.”

Adjust it to the actual project. Do not claim a release, study, or data source that you cannot verify.

Explain what you would learn next

Identify the question that remains and the evidence that could answer it. That might mean observing people complete a task, checking support requests, validating an implementation with assistive technology, or reviewing an agreed product metric. A next step should follow from the uncertainty, not act as a generic “more research” ending.

Avoid turning confidentiality into a vague success claim

If details cannot be shared, describe the constraint and use approved, non-sensitive evidence. “Results were strong” is still a claim that needs support. A smaller, clear account of your role and reasoning is more trustworthy than an impressive number without context.