Designing business software workflows around a feature list is the fastest way to build something that gets opened once and abandoned. Feature lists are easy to write, easy to sell, and almost never describe how the work actually runs.
Every platform we have built started the same way: someone described a process that worked, but only because a person was holding it together with attention and memory. A dispatcher who knew which drivers answered their phone. An operations manager who kept the real schedule in a notebook because the system could not represent it.
Map the business software workflows before writing code
Before we write anything we map the work as it actually runs, including the parts people are slightly embarrassed by. The workaround is usually the most valuable thing in the room. It marks the exact point where the existing tools stopped matching reality, and it tells you what the software has to absorb.
This is slower at the start. It also removes most of the expensive rework later, because you are no longer guessing which of twenty features matter. The GOV.UK Service Manual makes the same point from a research angle in its guidance on user research: observed behaviour beats reported preference nearly every time.
What changes when the process leads
- Screens follow the order the work happens in, not the order the database is structured in
- The common path is fast, and the rare path is possible rather than blocked
- Fields that nobody fills in get removed instead of made optional
- Reporting comes out of work already being done, not a second round of data entry
- Permissions match real responsibility rather than an org chart drawn two years ago
The workaround is the specification
When someone keeps a private spreadsheet alongside the official system, that spreadsheet is a specification written by the person who understands the job best. It records what the system failed to capture, in the exact shape the work needs. We ask to see those files early, because they compress months of requirements gathering into an afternoon.
The same is true of the informal rules that never made it into a manual: the customer who always gets called first, the job type that needs two people, the week in the month when everything doubles. Software that cannot express these forces people back to the notebook.
Where feature lists still help
None of this means feature lists are useless. They are a reasonable way to communicate scope once you already understand the work, and they are how most procurement processes are structured. The failure is treating the list as the starting point rather than the output. A list derived from observed process is a plan. A list derived from a competitor’s marketing page is a guess.
How we know it worked
The measure we care about is whether people use the software when nobody is asking them to. Adoption driven by a mandate tells you very little. Adoption driven by the tool being faster than the workaround it replaced tells you the workflow was modelled correctly.
That is the test we apply before calling anything finished, and it is why our discovery work looks more like sitting in an operations room than running a workshop.
Read next: What secure case management software actually needs. Or see the platforms we are building.