Your revised screen puts a pickup location under “Ready for pickup.” A reader can see the change, but still needs to know why you made it. Put the task, the observation that exposed the problem, your interpretation and the interface revision beside each other. That gives the reader a path through your reasoning.
A UX case study template should let someone trace a design decision back to its evidence. Use the original fictional evidence appendix below to practice that connection. It includes two interface exhibits and a proposed retest, with no claim that an actual user study took place.
Open the complete example · Download the full HTML source
State the task and your contribution
Begin with what the person using the interface needed to do. In this teaching example, task T1 is: find where to collect a reserved book. The original library-status card says “Ready for pickup” but does not name a pickup location. A separate branch-hours note lists opening hours.
Identify the interface version, research method and your own responsibilities when those facts are available. Distinguish the work you performed from work done by a teammate. The example leaves real project dates, participant recruitment, permissions and contributor details blank; its fictional notes are authored teaching material.
Nielsen Norman Group's portfolio guidance recommends showing the problem, your role, how you reached a proposed solution and the evidence behind design iterations. Use those questions to select exhibits that explain a decision. A gallery of polished screens cannot show which observation led to a particular change unless you make that connection explicit.
Keep observations separate from your interpretation
The two supplied notes below are invented, not quotations or records from people we tested:
- O1: During T1 on the original exhibit, fictional participant P01 asked which branch held the reserved book.
- O2: During T1 on the original exhibit, fictional participant P02 looked at the branch-hours note for a collection location; that note supplied hours only.
The analyst's finding F1 is that the collection location is missing beside the pickup status in the original exhibit. O1 and O2 are the supporting notes. They do not establish how frequently the problem occurs among library users, or whether every person would respond in the same way.
The GOV.UK research-analysis guide separates what observers saw or heard from the findings drawn from those notes, then uses findings to decide design or research actions. Its guidance helps organize this appendix; it does not turn fictional notes into real research.
Connect the finding to a specific design revision
Design decision D1 adds “Collect at West Branch, holds shelf” immediately below the pickup status. The original exhibit does not contain that line; the proposed revision does. The branch-hours note remains a separate piece of information.
Explain what the change is intended to address: it places the collection instruction beside the status the person is already reading. The revised location text is an original fictional interface requirement, not a fact about an actual library. In your own case, use the location and terminology the project has confirmed.
The evidence chain is O1 and O2 → F1 → D1. Showing D1 works as a local screen change does not show that it solved T1 for users. The before/revision controls in the example only switch the displayed exhibit. They do not reserve a book, record a participant response or complete a usability test.
Keep this evidence appendix with the project's research notes and design files. Use the case study portfolio guide when you are ready to place the finished case among your other work. This appendix supplies the reasoning behind one iteration rather than another portfolio index or result-first project summary.
Write the evaluation section honestly
The proposed retest asks a person to identify the collection location from the revised exhibit without a hint. Record their actual response, whether help was needed, the tested version and the relevant session reference. The example leaves those observations empty because no retest was performed.
If you have a completed evaluation, describe its method, participants and limitations from the permitted records. If the work ended at a prototype, explain the next question you would test. Do not fill the outcome section with an invented completion rate to make the case look finished.
The general case-study template helps when you also have a business comparison that needs defined measures and denominators. Keep those results distinct from what a small set of observation notes supports.
Download the complete Markdown model or use the blank scaffold for your own task, observations, interpretation, decision and evaluation. An optional HTML reading copy in NOS can put the evidence trail beside the interface exhibits for review. Preserve the required portfolio format and private research source.
Finish by following one visible design change back to its source note. If the connection is missing, add the evidence or describe the change as a hypothesis to investigate.
Download the filled UX evidence appendix · Download the blank UX case scaffold