How to Start a UX Case Study When You Feel Stuck

The real problem

Most designers do not get stuck because they have nothing to say. They get stuck because they try to write the final story too early. A better way to start is to collect the raw material first: the problem, your role, key decisions, constraints, and one important change that happened during the project.

The stuck feeling usually comes from trying to write the reasoning in its final form before you have figured out what the reasoning is. The page stays blank because you are trying to solve two problems at once: understanding what happened, and writing it clearly. These are easier to do in sequence.

What to focus on instead

The way out of stuck is to stop treating the case study as a writing problem and start treating it as a retrieval problem. What you are looking for is already in your memory of the project. The writing comes after. Start by answering blunt questions in whatever language comes naturally.

Key principles:

• Do not start with the perfect introduction.
• Start with one project moment you remember clearly.
• Write messy notes before polished paragraphs.
• Answer one focused question at a time.
• Turn notes into structure only after the thinking is visible.

A practical structure

Use this simple flow:

1. Context: What was the product and situation? Answer in rough notes, not polished prose.
2. Problem: What needed to change? Write it in one sentence, imperfect is fine.
3. Role: What did you specifically do? Start with verbs.
4. Decision: Name one important choice you made. Just name it.
5. Reasoning: Why that choice? What evidence or constraint shaped it?
6. Outcome: What changed? Write what you know, not what sounds impressive.

These six questions are a retrieval tool, not a template. You are not writing sections yet. You are answering questions in rough notes. Once the answers exist, the structure gives you something to write from. The blank page is only blank because the answers are not on the page yet.

Example framing

Weak framing:

I redesigned the flow and improved the user experience.

Stronger framing:

I focused on the onboarding step where users were unsure what to do next. Instead of adding more explanation, I simplified the sequence and made the next action more visible. This helped the team align around a clearer first-use experience.

The stronger framing is also easier to write when you have notes. Once you have the situation, the decision, and the reasoning in rough form, putting them into clear sentences is a much smaller task than starting from nothing.

What to avoid

• Do not turn the case study into a gallery of screens.
• Do not hide your role behind vague “we” language.
• Do not overclaim impact if you do not have evidence.
• Do not describe every step equally; highlight the decisions that mattered.
• Do not copy another designer’s case study structure without adapting it to your own project.

Final thought

Getting unstuck is usually a retrieval problem, not a writing problem. Once the raw material is on the page, the case study tends to write itself. What you are looking for was already in the project. You just need to pull it out before you can put it in.

More case study guides

• what hiring managers look for in UX case studies
• writing a UX case study without metrics
• showing your contribution in a team project