A UX research diary study asks participants to record relevant experiences as they happen over time. It is useful when a product question spans days, changing contexts or repeated attempts that a single interview cannot reconstruct reliably. Start by defining the event to record, the minimum useful entry and how the records will inform a design decision.
Choose this method as part of a UX research plan, not simply because an app is used every day. If you need to know whether a button label makes sense during a short task, a usability session may be more direct. If you need to understand what happens between receiving a parcel notification and finally collecting the parcel, a diary can preserve the intervening context.
The example below is a proposed study for a fictional parcel-locker service. Its team wants to understand why planned collections are delayed and what information people need when they try again. The example entries illustrate analysis; they are not observations from real participants.
Ask a question that needs evidence across time
“Do people like our pickup screen?” is too broad for this study. A useful question is: “What changes between deciding to collect a parcel and successfully opening the locker?” That question connects an intention, one or more attempts, and an outcome.
Define the decisions the study can inform. The team might change where it shows the pickup code, how it communicates locker access hours, or how it helps someone resume after a failed attempt. The diary cannot establish which interface change will work best by itself. It can identify situations worth investigating in a later prototype.
Nielsen Norman Group's diary-study guidance describes collecting self-reported experiences over time and choosing event, interval or signal-based logging. The practical choice depends on the behavior. For this parcel example, record a plan or attempt when it occurs, then use a short agreed check-in to distinguish a day without an event from a missing entry.
Write recording rules a participant can actually follow
“Tell us whenever anything relevant happens” leaves too much interpretation to the participant. Instead, name a small set of events: deciding when to collect, changing that plan, attempting collection, and completing or abandoning an attempt. Allow one entry to cover connected events, rather than demanding a separate form for every tap.
Choose the reporting period around the service cycle. A study intended to follow a notification through collection needs enough time for that cycle to occur. It does not automatically need a month, and a fixed seven-day period may miss a delayed delivery. Document the entry and exit conditions, how late arrivals will be handled, and how the study ends for someone who receives no parcel.
Recruit people who are likely to encounter the relevant task during the period. A research screener with concrete experience questions can distinguish frequent collectors from people who have never used a locker. Include the contexts that could affect the decision, such as collection during a commute or collection on behalf of someone else. Do not assume that device ownership alone makes someone eligible.
Tell people how much effort an entry should take and how to contact the researcher. Agree on a practical reporting channel and accessible alternatives. A voice note may suit someone who cannot conveniently type a long response, but do not encourage recording while driving or during another unsafe activity. Explain what not to include, such as an actual pickup code or another person's address.
Use a short entry template with neutral prompts
Ask for the experience before asking for a rating. A neutral prompt gives people room to describe an easy collection, a change of plan or a problem the team did not anticipate.
| Prompt | What it helps establish |
|---|---|
| What were you trying to do? | The immediate goal, including planning or postponing rather than only collecting. |
| When did this happen, and when are you recording it? | The event time and the possible effect of delayed recall. |
| Where were you, and what else was happening? | Relevant context without demanding a precise address. |
| What did you use or look at? | The app, message, locker display or another source involved. |
| What happened next? | An outcome or unresolved attempt. |
| Was anything unexpected or difficult? If so, what? | Room for difficulty without presuming every event was a failure. |
Make attachments optional unless they are necessary for the research question. A screenshot can supply context, but give participants a way to redact identifying details. Do not ask for credentials, active codes or private conversations. Test the submission flow yourself and with a pilot participant: the diary mechanism should not become a larger task than the event being studied.
Follow one experience before aggregating the entries
Consider this invented sequence. On Monday, participant P04 receives a notification at work and plans to collect after a meeting. The meeting runs late, so collection is postponed. On Tuesday evening, P04 reaches the locker but cannot immediately locate the code in the message thread. They open the app, find the code and collect the parcel.
Three entries from that person do not represent three independent users. Keep them connected as one experience. The Monday delay concerns the person's schedule; the Tuesday interruption concerns information retrieval. Combining both into “pickup friction” would hide the distinction.
Use a Mockitt whiteboard to arrange anonymized excerpts in chronological order, with separate notes for interpretation and open questions. This is a manual synthesis workspace. Collect the original diary records through the agreed research channel and keep sensitive source material in its approved location.
A useful follow-up is, “You mentioned looking in the message thread before the app. What were you expecting to find there?” A leading follow-up would be, “Would a bigger code button have solved it?” The first clarifies the experience; the second introduces the team's preferred solution before the problem is understood.
Distinguish a missing entry from a day without an event
An empty diary does not tell you whether nothing happened, the participant forgot to report, the submission tool failed, or the reporting burden became too high. Build a lightweight way to clarify this, such as an agreed check-in with “No relevant event today” as a legitimate response.
Record late entries as late. Do not silently replace their submission date with the recalled event date. Both can be useful: one places the experience in sequence, while the other describes how close the report was to the event.
If a participant stops responding, follow the study's contact and withdrawal arrangements. Do not invent an outcome or treat absence as evidence of satisfaction. When reporting the study, distinguish completed experience sequences from partial ones. The partial records may still reveal useful situations, but they cannot support claims about how those experiences ended.
Move from sequences to patterns without losing the context
Analyze within each participant's timeline first. Mark the goal, trigger, context, channels, obstacle and outcome. Keep the excerpt or entry identifier beside the interpretation so another researcher can understand what supports it. Then compare similar episodes across participants.
For the parcel example, compare code-retrieval episodes separately from changes of plan. Note whether people who found the code easily used a different channel, had already opened the app, or were in a different situation. A counterexample can narrow a claim more usefully than another similar complaint.
The number of entries mentioning an issue is not automatically its prevalence among customers. Participants contribute different numbers of events, and the sample was recruited for a particular question. Report what the study supports: for example, that a particular sequence occurred in several recorded experiences, alongside its context and exceptions. Use an appropriate additional method if the decision requires a population estimate.
In the final research synthesis, separate the evidence from the proposed response. “P04 searched the notification thread before opening the app” is an example observation. “Make the current collection code easier to retrieve” is an opportunity. “Add a persistent code card” is one possible design.
Turn a finding into the next design question
Bring one well-supported situation into a prototype. For the example, show the parcel status, code availability and a route back to the code after someone leaves the screen. Review the sequence with realistic content and the interruptions uncovered in the diaries, rather than only demonstrating the ideal uninterrupted path.
Keep a short connection between the evidence and the decision: which entries motivated the change, what the prototype is meant to test, and what would cause the team to reconsider. A diary study earns its effort when the team can explain what it learned about real contexts and how that learning changed the next product question.