Research staff work without leading the answers

Learn how work actually happens through neutral questions, recent examples and careful observation before proposing software.

An observer watches a dispatch workflow with a tablet and notebook.

Staff interviews can be misleading when the questions invite agreement with a preferred solution. Asking whether a dashboard would help usually produces less useful evidence than asking how somebody decided what to work on yesterday. Research should help your business understand behaviour and context before it asks people to endorse a particular design.

Ask about a recent specific event

Invite a staff member to walk through the last time they completed the task. A hypothetical Cairns tour operator could ask a coordinator to explain yesterday's group booking amendment: what arrived, what they checked, whom they contacted and how they knew it was complete. Specific events reveal details that general descriptions omit. Ask to see an anonymised example where practical. Keep notes about what happened separate from your interpretation of why it happened.

Look for work outside the official process

People may use handwritten lists, personal reminders or informal conversations to bridge gaps between tools. Treat those workarounds as evidence, not as a reason to criticise the person. Ask what the workaround accomplishes and what would happen without it. GOV.UK's guidance on learning user needs emphasises understanding users and their context. Applied to a small business, that means examining the surrounding task, including the interruptions and handovers that a feature list rarely describes.

Include more than enthusiastic users

Speak with people who are new to the process, experienced users and those who struggle with the current tools. Consider different shifts or branches when the work varies. You are not trying to collect a vote on a proposed screen. You are trying to discover meaningful differences in needs. The tradeoff is that a broader sample takes more coordination; start with the groups likely to expose distinct workflows, then investigate gaps revealed by early conversations.

Translate observations cautiously

A single frustrating incident can identify a question without proving that the same problem occurs everywhere. Compare examples, look for contradictions and state what remains uncertain. Turn findings into needs such as knowing whether a booking amendment has been acknowledged, then explore possible solutions. Your next scoping step is to prepare a short interview guide with neutral prompts, recruit several relevant participants and decide which project decision their experiences will inform. Keep solution ideas for the analysis discussion.

Planning checklist

  • Ask about the last actual task.
  • Separate observations from interpretations.
  • Include users with different levels of experience.

Further reading

Discuss your software project with 110s

Related Insight