The work between the screens.
The real requirements often appear when someone shows you how they get through an ordinary day.
Useful software starts with observing a real task in its actual setting. Turn the pauses, workarounds and exceptions into a small workflow people can test, then improve it through use.
A specification is a starting point
A feature request describes what someone wants a system to do. Watching the work reveals why they want it, what surrounds it, and what happens when the expected sequence changes.
A request for a new form might be a request for clearer ownership. A request for another dashboard might be a response to unreliable notifications. Building the requested screen without understanding that context can leave the underlying problem intact.
Ask for a demonstration
Invite a person who does the work to show you a recent example. Let them use their usual tools. Pay attention to the pauses, the copied text, and the moments when they switch from the official process to a personal workaround.
Ask what they are checking and how they know the next step is safe. Avoid assuming that a repeated step is unnecessary; it may be compensating for a constraint the team has learned the hard way.
This is the value of engineers working close to the operation. The person learning the context can carry it directly into the design and implementation.
Sequence of work
From observation to a useful first release
- Observe
Follow one real task using the team’s current tools.
- Map
Identify decisions, owners and hidden constraints.
- Build a slice
Choose a bounded result that improves the job.
- Review in context
Include interruptions, exceptions and recovery.
- Keep learning
Use operating feedback to improve the next release.
The real requirements often appear when someone shows you how they get through an ordinary day.
The setting changes the product
A desktop workflow and a field workflow may share a record but need different interfaces. Someone at a desk can compare several pieces of information. Someone standing beside a delivery vehicle may need one clear action and a way to capture what happened.
For mobile work, interruptions and connectivity are design inputs. Consider what happens if a person begins a task, loses the connection, and returns later. Make it clear which information is saved, what is waiting to synchronize, and where a conflict needs attention.
Good product decisions come from the setting in which the tool has to work.
Decision guide
The setting changes the interface
| Consideration | At a desk | In the field |
|---|---|---|
| Attention | Compare records and supporting context. | Make the next action easy to identify. |
| Connectivity | Confirm updates in connected systems. | Show saved, pending and synchronized states. |
| Interruption | Keep context while switching tools. | Resume safely without repeating completed work. |
Build a useful slice
Choose a portion of the workflow that can become meaningfully better on its own. Keep its beginning and end clear. Put it in front of the people who use it while there is still time to change the assumptions.
Ask them to complete a real task, including an exception. Notice whether they can explain the state of the work and find the next action. A useful review is about the job getting done, not whether the screen resembles the initial sketch.
As the product grows, keep the shared record and responsibility clear across customer, operator and administrative interfaces.
Stay close after it ships
Release is when the design meets the working day. That is when edge cases become concrete and habits begin to change.
A close engineering partnership keeps learning through that transition. It makes the new workflow understandable, improves the rough edges, and helps the team take ownership. The best product is the one that becomes a dependable part of how people work.
Put this into practice
Ask someone to walk you through an ordinary day, not the diagram. The pauses, the side spreadsheets, and the workarounds are the requirements.
If the process crosses devices and interfaces, explore custom web applications.
Related work: Sutton Place.
We build alongside the people doing the work.
Bring us the problem you’re thinking about.