Direct answer
How to write a case study means turning one real situation into a useful, verifiable story. Choose a specific subject, define the reader's question, and collect the evidence first. Then explain the context, challenge, choices, work, results, and lessons. Support each claim and state the example's limits.
How to write a case study: quick summary
A useful case study is proof with context. Define one reader and one problem. Gather the baseline, decisions, work, outcomes, and limitations. Present the result in plain language, verify every material claim, and get the agreed approval. This guide focuses on business, product, agency, and portfolio cases.
Start with one reader, one problem, and one proof point
Decide who should use the case study and what decision it should help them make. A prospective client may need evidence that you understand their problem. A hiring manager may need to see how you think. An internal team may need lessons from a launch. Trying to serve all three usually produces a vague story.
- Reader
- Who needs this evidence, and what do they already know?
- Problem
- What specific obstacle, risk, or missed opportunity did the subject face?
- Proof
- Which verified outcome would make the story useful and credible?
Write a one-sentence goal before you research. For example: “Show ecommerce teams how a clearer checkout flow reduced support requests without hiding delivery costs.” This sentence is an editorial filter. If a detail does not help the reader understand the problem, work, result, or limitation, leave it out.
Collect the evidence before you draft
Do not write the headline first and hunt for numbers that support it later. Build an evidence packet. Gather the original brief, baseline measures, research notes, decision records, work samples, launch dates, outcome data, and known limitations. Record where each fact came from and who can verify it.
Create a small evidence packet
- A short timeline with the starting point, major decisions, launch, and measurement period.
- The metric definition, baseline, final value, source, and date range.
- Screenshots, artifacts, or documents that show the work rather than merely decorating the page.
- Approved quotes and a named owner for factual review.
Give every number enough context to be interpreted. “Conversion increased 18%” is incomplete without a definition. State whether it means a relative increase or 18 percentage points. Name the comparison period and other relevant changes. If the project influenced rather than caused an outcome, say so.
Agree on permission and review
Confirm what the subject will let you publish before the interview. Agree on the company name, participant names, screenshots, confidential figures, quote approval, and final review process. An anonymized case can still work when it gives enough context to judge relevance. A case study needs real subjects, quotes, and results; leave an unsupported gap visible.
A customer story used in marketing can function as an endorsement. The Federal Trade Commission says endorsements must reflect honest experience. They cannot make claims that would be deceptive or unsupported if the advertiser made them directly. Exceptional results need clear context; a vague “results may vary” line does not repair a misleading claim.
Review the FTC's small-business guidance on endorsements and testimonials.
Interview for decisions, not compliments
Send the topic and broad questions in advance, then use the conversation to uncover sequence and judgment. Ask what was happening before the project, why the problem mattered, which options the team considered, what made the work difficult, and what changed afterward. Follow a claim with “How do you know?” and “What evidence can we check?”
- What triggered the project, and why did the old approach stop working?
- Who was affected, and what did they need to do?
- Which constraints shaped the solution?
- What did the team try, change, or reject along the way?
- What changed after launch, and over what measurement period?
- What would you do differently next time?
Specific follow-ups produce better material than a long questionnaire. If someone says the new experience was easier, ask what task became easier and how the team observed it. If they cannot support a statement, treat it as an opinion and label it clearly.
Choose a case study format built around evidence
The familiar challenge, solution, and results arc is a useful start. However, “solution” often hides the most valuable part: the choices and tradeoffs. A stronger case study format uses six connected sections. Each one answers a question the reader needs resolved before trusting the next.
1. Context: who and what situation?
Introduce the subject with only the details needed to understand the case: the organization or project type, audience, scale, stage, and relevant environment. Avoid a long company biography. The reader needs to know whether the situation resembles theirs.
2. Challenge: what needed to change?
Describe the observable problem, who felt it, and what it cost. Separate a symptom from its cause. “Users abandoned checkout” is a symptom. Research might reveal unclear delivery dates, an account requirement, or poor error recovery as contributing causes. State what was known at the time instead of writing with hindsight.
3. Choices: why this direction?
Show the main options, evidence, constraints, and tradeoffs behind the approach. This is where the case becomes instructive. Readers learn more from a clear decision than from a list of deliverables. Include rejected directions when they explain why the final path was reasonable.
4. Work: what happened?
Present the important stages in chronological order. Connect each action to the problem it addressed. Use artifacts where they clarify a decision: a research theme, an early flow, a comparison, a prototype change, or a launch check. A gallery without explanation shows output but not reasoning.
5. Results: what changed?
Report outcomes against the original goal. Combine quantitative evidence, such as task success, revenue, time, error rate, or support volume, with qualitative evidence that explains the change. Name the baseline and measurement window. If results are early, mixed, or influenced by other work, make that visible.
6. Lessons: what transfers?
End with what the team learned, what remains uncertain, and what it would change next time. A single example does not support a universal rule. A lesson is more useful when the reader can see the conditions under which it may apply.
Copy this case study template
Use this case study template as a drafting frame, then remove prompts that do not serve your reader. Draft the summary after the body so it reflects the verified story rather than the hoped-for one.
- Outcome-led title: [Subject] achieved [verified result] by [meaningful change].
- Summary: Identify the subject, problem, work, main result, and one limitation in 80 to 120 words.
- Context: Explain the audience, environment, scale, and starting point.
- Challenge: Define the problem, evidence, constraints, and success measure.
- Choices and work: Show the options, decisions, stages, and important artifacts.
- Results: Compare the baseline and outcome, name the period and source, and add approved context.
- Lessons and next step: State what the team learned, what remains open, and where the reader can go next.
Build the draft from the result backward
Start with the strongest verified result and ask what the reader needs to know to trust it. Write an outcome-led title only when the outcome can be stated honestly. Otherwise, lead with the problem or decision: “How a small team redesigned checkout error recovery” is stronger than an inflated promise.
Place a compact summary near the top. Give time-poor readers the subject, challenge, approach, and result before the full narrative. Then use descriptive headings that form a useful outline on their own. A reader who scans only the title, summary, headings, metrics, captions, and conclusion should still understand the case.
Use quotes to reveal experience or judgment, not to repeat nearby claims. Introduce the speaker's role and why their view matters. Keep their meaning intact, remove only verbal clutter, and obtain approval for the final wording and context.
Design the page so evidence is easy to follow
Give the case study a clear reading rhythm. Separate the summary, context, work, results, and lessons with meaningful headings and space. Reserve result callouts for outcomes the body explains. Place each image beside the decision or change it supports, and write a caption that tells the reader what to notice.
Treat screenshots, charts, and diagrams as evidence. The W3C advises authors to provide text alternatives for informative images and complete text equivalents for complex graphics. Keep every important result available outside a chart or before-and-after image. State it in text and preserve a readable order on small screens.
Review the case study in three passes
First, review proof. Trace every number, date, quote, product claim, and causal statement to a source. Confirm the baseline, units, time period, and calculation. Remove claims that the evidence cannot support.
Second, review the story. Check that the challenge leads to the choices, the work addresses the challenge, and the results answer the original success measure. Cut side projects and background details that break that chain.
Third, review use. Ask two or three people who were not involved in the project to read the draft. Have them explain the problem, main decision, result, and limitation in their own words. Confusion reveals where the case needs clearer context, structure, or language.
How is an academic case study different?
A business or portfolio case study usually demonstrates work and outcomes for a prospective client, employer, or team. An academic case study analyzes a situation through relevant theory and evidence. It may require a methodology, findings, discussion, recommendations, references, and appendices. Follow the assignment and discipline requirements rather than using a marketing template unchanged.
Monash University distinguishes descriptive and problem-solving case studies and notes that required structures vary by discipline. Its guidance also cautions against broad generalization from one specific case. That same caution improves business stories: explain what the example shows without presenting it as proof that everyone will get the same result.
Read Monash University's guidance for academic case study assignments.
Common case study mistakes
Making your company the hero weakens the story. Keep the subject's problem, decisions, and result at the center. Explain your contribution precisely, but do not erase the customer's work or other factors.
Listing deliverables is not a case study. A sequence of workshops, wireframes, and screens tells the reader what you produced, not why it mattered. Connect each artifact to evidence, a choice, and an outcome.
A frictionless success story feels edited beyond recognition. Include a real constraint, a changed assumption, or a remaining limitation. Useful honesty makes the result easier to trust and the lesson easier to transfer.
Final case study checklist
- The title, summary, and body describe the same verified result.
- The reader can identify the subject, challenge, choices, work, results, and lessons.
- Every material number, quote, date, and claim has a traceable source.
- The subject approved the agreed names, quotes, visuals, and confidential details.
- The page states the baseline, measurement period, limits, and other relevant factors.
- Headings, paragraphs, visuals, captions, and text alternatives make the story easy to scan and understand.
- The next step fits the reader's intent and does not interrupt the evidence with a hard sell.
Frequently asked questions
Use the shortest length that gives the reader enough context to understand and trust the result. A focused web case may be 800 to 1,500 words, while a complex project may need more. Structure and evidence matter more than hitting a fixed count.
For a business or portfolio case, use context, challenge, choices, work, results, and lessons. Add an outcome-led title and a short summary. If you are deciding how to write the case study after an interview, sort your notes into those sections before drafting. Academic requirements vary and may also call for theory, methodology, discussion, recommendations, and references.
Yes, but you still need evidence. Use observed behavior, research findings, task completion, stakeholder decisions, approved feedback, or documented process changes. Explain what the evidence can and cannot show. An unsupported testimonial is not a result.
Yes. Describe the industry, audience, scale, and problem closely enough for the reader to judge relevance, while removing details the subject has not approved. Tell the reader that identifying information was withheld. Combining unrelated customers into a fictional success story can mislead readers unless the method is disclosed.
Six to ten open questions are often enough for a focused interview. The quality comes from follow-up: ask for a concrete example, sequence, decision, or source whenever an answer stays general.
Assign a named factual owner on your team and the agreed reviewer on the subject's side. Legal, privacy, security, or brand review may also be needed when the story includes regulated claims, personal data, confidential work, or third-party marks. Approval confirms agreed publication details; it does not replace your own fact check.
Browse more Better Design guides for clear product, design, and content work.