A useful case study explains why the design took its final form. Connect the brief, decisions and evidence so a reader can follow the work without attending your project meetings.
The anatomy of a clear case study
- 01Context
Who is it for, and what needed to change?
- 02Decision
What did the team choose, and why?
- 03Evidence
What observation or test supports it?
- 04Outcome
What is known, and what remains untested?
The award form may allow only a short description, or it may ask for a longer presentation. Build a complete working narrative first, then edit it to the actual requirements. There is no universal award-entry word count: prioritise the information that helps someone understand your contribution.
Start with a one-paragraph project summary
Identify the project, intended user, problem and scope of the work. Name the project’s stage. The reader should know whether you are describing a launched website, a manufactured object or a concept before encountering claims about its results.
A useful summary answers four questions: what is it, who is it for, what needed to change, and what did your team deliver? Save broad claims such as “revolutionary” for evidence that can support them; usually a specific explanation is clearer.
Give the brief enough context
Describe the situation that made the work necessary. Include the constraints that explain your decisions: available space, materials, an existing technical platform, a limited content team or a manufacturing process. Do not turn this section into a complete project diary.
For a website, distinguish the client’s business objective from the visitor’s task. For a product, distinguish the commercial positioning from the physical activity the object supports. Both perspectives can matter, but they answer different questions.
Select the decisions that carry the story
Choose two or three decisions and give each its own short section. Use the sequence “observation, choice, reason, evidence.” Include an alternative when it makes the final choice understandable, not simply to show that many options were explored.
Place the relevant image beside the explanation. A detail photograph can support a statement about assembly; a sequence of interface states can show how a task progresses. Captions should identify what the reader needs to notice.
Separate the outcome from the ambition
Describe what is known at the time of writing. A launched product may have production or service data; a prototype may have observations from a limited test. Neither needs to pretend to have the other’s evidence.
If a number is important, include the baseline, method and scope. A shorter task time in one small test is not proof that every user will work faster. If reliable outcome data is unavailable, describe the completed work and the next validation step without implying that future results have already occurred.
A worked example: turn a claim into an explanation
Hypothetical claim: “Our innovative comparison page transformed the customer experience.”
More useful version: “Buyers needed to compare three equipment models before requesting a quote. The previous layout placed specifications on separate pages. We introduced a comparison view that keeps the same attributes in the same order and retains the selected models when visitors return from a detail page.”
The second version explains a problem and a response. It still needs evidence before claiming improved task completion. A subsequent paragraph could report an actual usability test, including its conditions and limitations, or state that evaluation is planned. Do not invent a percentage to make the story appear finished.
Replace a slogan with a design decision
“Our innovative comparison page transformed the customer experience.”
The task, change and supporting evidence are missing.
“Buyers needed to compare three models. We placed matching specifications side by side and retained their selections when they returned from a detail page.”
Now the reader can identify the task and the design response.
Use an outline you can shorten
- Summary: the project, audience, problem and status.
- Brief: the scope and constraints that shaped the work.
- Decisions: the important changes and why they were chosen.
- Evidence: images, observations or measurements supporting the claims.
- Outcome: what was delivered, what is known and what remains untested.
- Credits: the team, collaborators and permitted image sources.
When editing to fit a form, remove repetition before removing the reasoning. A compact account of one well-supported decision is more useful than a list of ten unexplained features.
Adapt the emphasis for each nomination
A single project can receive recognition in several categories. Keep its name, authorship and factual background consistent, but explain the contribution relevant to each nomination. An entry about packaging should not rely only on the product’s interaction design; a website entry should show the website’s own experience.
The same research may inform several submissions, but the supporting images and argument should fit the work being assessed. Check the programme’s conditions for multiple entries before proceeding.
Finish with an independent read-through
Ask a colleague who was not involved to identify the user, problem, central decision and result. If they cannot, revise the structure. Check names and credits, remove private data and obtain the relevant publication permissions.
Continue with the product design entry guide, the web design submission guide or the product submission checklist.
Entry requirements vary by programme and edition. Check the Design Skill Awards brief or the International Excellence Awards brief for the current status, categories, fees and deadlines. These preparation guides do not replace the official rules.