01. We understand the work from the inside.
Our first conversation focuses on the situation you want to change. What delays delivery? Where does work come back for corrections? What information is missing when someone needs to make a decision? We then walk through a real example with the people who handle it. A manager and an operational employee can reveal different sides of the same process.
In a large organisation, a single order or document may pass through several departments. We look for the points where responsibility changes, waiting begins or context gets lost. These are often the best opportunities to simplify the work.
- The project objective and how the work is currently done.
- The people who will use the solution and make decisions.
- The most common path and the situations that cause difficulty.
02. We define the rules, data and first scope.
We ask for representative samples: a typical form, document or report with personal data and unnecessary confidential information removed. Rather than looking only at a straightforward example, we examine missing information, duplicates and corrections. We establish who can change data and when approval is needed.
We select a small but complete part of the process. It should have a starting point, a sequence of steps and a useful outcome. This makes it possible to test the solution in everyday work. We also record dependencies and the elements deliberately left for later.
- What starts a case, and how do we know it is complete?
- Who is responsible for each piece of information?
- How do we handle an exception or a reversed decision?
The essentials to start with
We start with specific work and speak to the people who do it.
The first scope covers a complete workflow and its most important exceptions.
The prototype, test criteria and acceptance all refer to the same user tasks.
03. We test the idea with a prototype.
We lay out the key screens and work through the tasks a future user will perform. Do they understand the status? Can they find the document? Do they know why an action is unavailable? This is the time to test wording, the order of steps and the information needed to make decisions.
The prototype supports a discussion about how the work should happen. It does not pretend to be a finished system: real integrations, access controls and data storage still need to be built and tested. We turn the agreed findings into a scope that can be developed and accepted.
04. We build the solution and its connections together.
We connect the interface to the rules, data and systems it needs. We check access to APIs, documentation and environments before assuming that a full exchange of information is possible. We establish which tool is the source of each piece of data and how the connection should behave after an interruption or a repeated event.
We develop the project in agreed parts that can be demonstrated and checked. New ideas are recorded and assessed against the objective. This means a significant change can deliberately alter the scope, rather than quietly changing expectations about delivery time and cost.
05. We also test what might happen differently.
We verify the scenarios agreed during discovery: the normal path, missing data, incorrect permissions and unusual decisions. For integrations, we test retries and unavailable sources. When migrating information, we compare the data to confirm that its meaning has been preserved.
Users have the opportunity to try important tasks in a context relevant to their work. A phone-based application needs a different perspective from a panel used at a desk. Acceptance criteria relate to specific outcomes and the agreed scope.
- Can the user complete the right task?
- Can they view and change only the information they are authorised to access?
- Is an error understandable, with a defined way to resolve it?
06. We launch in a way that suits the business.
Where the process allows, we begin with a pilot involving a selected group or subset of data. This lets us compare the new approach with the existing workflow and refine the details before extending access. Otherwise, we plan an agreed cutover point and what to do if a problem occurs.
Before acceptance, we agree responsibilities, how users will receive the information they need and how issues will be handled. Code ownership, access credentials, documentation and project handover arrangements depend on the contract and agreed scope. We discuss them early so the business knows what it will receive and how the solution can be developed further.
07. We review the effect and plan the next steps.
We return to the problem we started with. We check task completion time, waiting, corrections or another measure selected earlier. Not every benefit needs a chart: being able to find a status without tracking down the person who knows can be an important result in itself.
Maintenance, backups, monitoring, updates and responses to support requests are defined within the agreed scope of our work together. New modules follow user observations and business priorities. Development then addresses real needs while the core process remains under control.
Where does the conversation begin?
- We agree ownership, access and maintenance responsibilities before handing over the solution.
- We assess the effect against the original problem and starting point, rather than the number of features added.
