Operations ·
Watch the work before writing the requirements
A useful software brief starts with a real task. Watch where information is copied, decisions wait and people work around the official process.
By Norwind
Follow a task from beginning to end
Choose a task that matters to the business and ask the person doing it to show the normal sequence. Use a real, appropriately protected example rather than an idealized demonstration. Notice what arrives before work can begin, which systems are opened and how completion is communicated. A process diagram is useful context, but the working sequence is the evidence for the design.
Treat the shortcut as information
A copied spreadsheet or private checklist can reveal a missing capability. It can also reveal a sensible local habit that software should leave alone. Ask what the shortcut protects against. Perhaps the official form cannot express an exception, or a person checks something the system cannot reliably verify. Record the reason before proposing to automate or remove the step.
Turn observations into a small brief
Write down the task, the inputs, the decisions and the outcome the user needs. Include what happens when information is missing or a transfer fails. Then review that description with the people who perform and receive the work. The first change may be configuration, a clearer responsibility or an integration. A custom application becomes relevant when the workflow requires capabilities that the existing tools cannot reasonably provide.
A practical check
- Observe a real task without correcting it as it happens.
- Record each copy, check, wait and exception.
- Agree what a successful outcome looks like before discussing screens.