Diary Study

Ask someone in an interview how they found a document last week and the answer comes out smooth. They typed the title into search and opened it. Follow the same person's screen and you find them digging through chat for a link, giving up and asking a colleague, and finally rebuilding the document from scratch. They weren't lying. Their memory simply didn't store it that way.

Memory keeps the exceptional. The moment something went badly wrong stays sharp, while a small annoyance that happens three times a day never becomes a story and disappears. A customer interview sits with one person for about an hour, and only what surfaces within that hour becomes material. Things spread across time drop out for the same reason: the rhythm of writing a weekly report, the reconciliation work that only appears at month end, the problem that only shows up while traveling. None of that is visible from a single sitting.

A diary study collects those moments where they happen instead of asking about them afterward. Participants agree to log for about two weeks and write a short entry at the moment the thing occurs. Nothing has to pass through memory, so the small stuff survives, and because the study runs over a stretch of time, anything that only happens on a cycle shows up too.

Narrow the question to one sentence, decide the format and the trigger, recruit and pilot for a few days, run the full period, and meet each participant once at the end.

1. Narrow what you want to know to a single sentence. Not "we want to understand our users" but "what does an admin on a team of five or more actually do when looking for a document someone else made." That sentence decides what the log entries ask for.
2. Decide what gets logged and when. The trigger is either an event ("every time you go looking for a document") or a time ("once each evening"). The format has to fit in three minutes. Three questions plus one photo is the ceiling; anything longer and entries start dropping off on day three.
3. Recruit. Research recruiting is the work of finding participants who match your conditions, and a diary study asks more of people than most methods, so plan for drop-off. If you need logs from eight people, start with twelve, and set the incentive higher than for a single interview.
4. Pilot for about three days. Running it with two or three people first reveals whether the questions make sense and whether the trigger actually occurs. Finding out after a full two weeks that the question was wrong means starting over.
5. Run the period and read the entries as they arrive. If someone goes quiet for two days, reach out. Whether the silence means they were busy or means the situation never came up is completely different information.
6. Meet once at the end. Entries are short, so the reason behind them is usually missing. Open a participant's own log with them and ask "you stopped here on this day — what was going on?" and the context attaches on the spot.

It fits for behavior scattered across time: a habit that repeats every few days, work that only appears on a weekly or monthly cycle, a task that runs over several days instead of finishing in one sitting. It belongs to qualitative research, which works out why people behave as they do through what they say and what you observe, so the headcount stays small. Eight participants under similar conditions is usually enough for the same stories to start repeating.

There are places it doesn't fit. First, it's overkill for anything that happens inside one screen. If you want to know what confuses people on the signup screen, a usability test with five people answers it the same day. There's no reason to spend two weeks.

Second, it can't give you proportions. Five of eight participants logging the same annoyance is plenty for deciding what to look at next, but it does not translate to 60 percent of your users. When the size matters, turn what came out of the study into survey questions and ask separately.

Third, logging changes behavior. Asked to write things down, people are more deliberate than usual, and in the annoying moments they skip the entry altogether. So trust the first two days less than the rest, and read the empty days as data too. When you need the situation exactly as it is, field research — going to where the work happens and watching — does that better.

"An interview won't surface this. Let's do a two-week diary study."

The kind of problem that gets lost when you rely on one sitting's recall.

"Eight log fields means everyone drops out by day three."

A warning that the burden on participants will cut the data short.

"Two participants went quiet from day three. Let's find out why first."

Treating the missing entries themselves as a signal worth chasing.

At Pagedeck the team ran one last quarter before rebuilding the document organization feature. Noa asked nine admins from teams of five or more to log every moment they went looking for a document someone else had made, for two weeks. Three questions: what they were looking for, where they started looking, and how many minutes it took.

Something that never came up in interviews showed up every week in the logs. Across nine people over two weeks, there were 23 cases of giving up on the search and rebuilding the same document. The numbers showed exactly where the pain point sat — the spot where a customer gets stuck. Mia used the logs to reshuffle the next quarter's priorities.

The most common mistake is assuming more logging is better. Adding fields feels like it should add knowledge. But once a participant spends more than three minutes a day, answers get shorter by day three and days go missing by day five. Two weeks of three well-answered questions is worth more than two weeks of ten questions answered half the time.

Reading the entries as conclusions is just as common. A participant writes "search was slow so I gave up," and fixing search speed looks like the answer. Ask about it in the closing session and it turns out nothing was slow — the results gave no way to tell which version was current, so they opened them one by one until they ran out of patience. Entries record what happened and when; they usually leave out why. Skip the closing session and you spend a quarter fixing the wrong problem.