Systems
How to plan the first version of a custom system
A first version starts with a clear process, the people who use it and the problem that needs to stop happening.
A feature list is useful, but it doesn’t tell the whole story of a system. Start with one important process and describe how it works today: who initiates it, what information comes in, who decides and what should come out at the end.
Describe the work before the screens
Use a concrete situation. Instead of “we need a dashboard”, write down the questions the team needs to answer and where the data is. Instead of “we need a registration form”, identify who can create, review and change records.
Talk to the people doing the work. Exceptions, rework and shortcuts help reveal what the first version needs to solve.
Choose one main workflow
A first version can focus on a workflow that makes sense from end to end. Define its input, expected result and review criteria. Features that don’t support that workflow can wait for another stage.
- Which task creates the most friction?
- Who needs to use the solution first?
- Which rules cannot be ignored?
- What information already exists in other tools?
- How will we check that the solution helps with the work?
Plan access and integrations early
Permissions and connections influence scope. Record which data each role may view and which systems offer integration interfaces. The existence of an API does not confirm that all necessary data is available.
Leave room to learn through use
After the first delivery, talk to the people using the system. Organize issues, difficult tasks and new priorities. Let real context guide improvements rather than a long list written before the first test.
Explore custom systems and describe the essentials in the quick quote.