“We want the system to be smarter” is hard to turn into development work. “Every day we check the same order across three spreadsheets” is already close to a solvable problem. The difference between those two sentences usually comes from one careful observation, not a longer requirements meeting.
Start with something that happened recently
The UK government’s Service Manual recommends understanding users through interviews, observation and existing evidence, and treating untested opinions as assumptions.[1] For a business system project, that means asking an employee to walk through a piece of work they recently finished, instead of going straight to a wish list of features.
Take logistics exception handling. Have the operator start from the moment the exception message arrives and show how they look up the order, check the device records, contact the person responsible and close the ticket. Note why they switch pages each time, which fields they copy and which step waits on someone else’s reply. Don’t interrupt while observing, and don’t rush to turn every step into AI.
Separate working time from waiting time
A process that takes a day is not a day of work. It may hold ten minutes of looking things up, two hours of waiting for confirmation, and a gap where nobody picks it up. Speeding up text generation alone leaves the main delay in place.
Split the process into three kinds of time: active work, waiting on systems and waiting on people. Active work can be reduced with better interfaces or automation; waiting on systems means checking the APIs and data updates; waiting on people usually calls for a clear owner, notification rules or approval limits. Only once it’s split this way is there something specific to judge whether AI should step in.
Write exceptions into the requirements, not into launch day
The normal flow is easy to describe; exceptions reveal where the system’s limits are. How do you find an order when the number is missing? Which system do you trust when two disagree? Who takes over when the owner is on leave? Questions like these decide whether a system works in the real world.
We suggest a short exceptions table, with one row per case: the trigger, how it’s handled today, the automated actions allowed and who takes over. Cover the frequent or high-impact exceptions first, and send everything else explicitly to a pending queue. The table exists to make responsibility visible, not to list every possibility.
Use small samples to choose the next step, not to draw big conclusions
Watching the work a few times is enough to find candidate problems, but not enough to prove a company-wide loss of efficiency. When choosing a pilot, add examples from different shifts, skill levels and task complexity. Keep the time estimates from interviews separate from the actual times in the system logs.
A good discovery output can be just four pages: the current process, the main blockers, the pilot scope and how it will be accepted. Mark what is still unconfirmed and name the next check. The team’s discussion then shifts from “whose idea is better” to “which assumption is worth testing first”.
In your next requirements interview, ask the person to walk you through the last piece of work they finished, and ask: which step forced you to leave the system you were in?
References
This article combines public sources with SWYZL & Co.’s recommended methods. The hypothetical scenarios illustrate design thinking and do not represent client results.
