Short answer
People describe their work in summaries, but they do it in documents: an export from the warehouse system, a photo of a handover sheet, a screenshot of an error, a spreadsheet kept on the side. Invite people to share one in an interview and ask about what it shows. That turns "the system is often wrong" into "three picks on Tuesday where the bin was empty and the system showed stock". Tell people what kind of document helps, and ask them to leave out other people's personal details. Treat what they share as evidence about one situation, not proof about the whole operation.
Why a document changes the conversation
A description depends on memory and on vocabulary. A document is specific: it has a date, figures, field names and steps. When someone shares one, the interviewer can ask about an exact line rather than a general impression, and the finding can point to the document behind it.
Documents also reveal the workarounds nobody mentions in a meeting:
- the spreadsheet a planner keeps because the planning system cannot show the next three weeks;
- the paper checklist taped to a machine because the procedure on the intranet is out of date;
- the shared inbox folder where "urgent" requests wait for a second approval.
These are often the most useful evidence in an operational study, and they rarely appear on an official process map.
What to invite, and what to keep out
| Useful | Keep out |
|---|---|
| Exports from operational systems: pick exceptions, ticket queues, approval logs | Customer personal data that is not needed |
| Photos of physical artefacts: handover sheets, whiteboards, labels | Other employees' personal details, health or performance information |
| Screenshots of an error or a confusing screen | Passwords, access codes or anything else that grants access |
| The side spreadsheet or checklist people actually use | Confidential documents the person is not entitled to share |
Say this plainly in the invitation. The GOV.UK guidance on managing user research data counts paperwork that participants refer to as research data, to be managed and protected like notes and recordings. Treat shared documents the same way: stored securely, kept for a stated period and then deleted.
Ask about the document, not just for it
A shared document is the start of a follow-up, not the end. Useful questions:
- "What am I looking at? Where does this come from?"
- "Which line or field matters here?"
- "What happened next with this one?"
- "Is this typical of a normal day, or unusual?"
- "Who else uses this, or would know why it looks like this?"
The fourth question matters most. People tend to share their most striking example, which is useful as an illustration and misleading as a measure.
A fictional example: pick exceptions
A fictional fashion retailer asks warehouse staff why online orders miss the afternoon dispatch. One picker shares an export of Tuesday's pick exceptions from the warehouse management system.
| Order | Item | Bin | System | Found |
|---|---|---|---|---|
| #48211 | Sneakers, 42 | A-12 | 14 | 0 |
| #48214 | Hoodie, M | C-03 | 6 | 6 |
| #48230 | Cap, black | A-12 | 9 | 0 |
| #48236 | Jacket, L | B-07 | 3 | 0 |
The interviewer notices three picks where the bin was empty but the system showed stock, two of them in bin A-12, and asks what happens to those orders. The picker explains that each one waits for a recount by the inventory team, which covers two buildings. Two other pickers share similar exports from different days, and bin A-12 appears in both.
The finding is not "the system is wrong". It is specific: discrepancies cluster in certain bins, recounts depend on a shared team, and orders wait for them. The operations manager can check bin A-12's replenishment process and the recount queue, and both have records.
What a document can and cannot show
A document shows what one system or person recorded at one moment. It cannot show what was not recorded or why a figure is wrong. It cannot show how often a situation occurs either, unless the export covers a defined period. Keep each document beside the account that explains it. Check a pattern against the full record before treating it as general. The input quality control guide covers similar checks for HR data.
Where Lontra fits
In a Lontra conversation, people can share PDFs, Word documents, spreadsheets, screenshots and photos. Lontra reads what they share, says what it noticed and asks about that exact point, as in the example above. Documents people share shape the next questions, including in Deep Study follow-ups. Every finding links to the conversation or file behind it. Shared documents are deleted with the study when its retention period ends: 90 days on the Free plan, up to two years on a paid plan.
Lontra cannot tell whether a person was entitled to share a document. Say in your invitation what is welcome and what is not.
Ask people to show you
The simplest improvement to most internal interviews is one sentence in the invitation: "If you have an export, a photo or a screenshot that shows what you mean, please share it." The conversations that follow are shorter on opinion and longer on evidence.
Frequently asked questions
- Can participants share documents in an employee interview?
- Yes, if the invitation explains what kind of document helps and what to leave out, such as other people's personal details or confidential material the person is not entitled to share. Store shared documents with the same care as interview notes.
- How should a shared document be used in findings?
- As evidence for the situation it shows, linked to the account that explains it. Check whether it is typical before treating it as a pattern, and confirm a pattern against the full system record.
- What if someone shares something they should not have?
- Leave it out of the findings, delete it under your retention process, and remind participants what is appropriate to share. If it contains personal data, follow your organisation's data protection procedure.