Take the effort out of the flows your customers use most
Your product works. The people using it still spend more effort than they need to on the few flows your business runs through. We find where that effort sits, remove it, and then check the build against the specification and fix what drifted. Start with one flow, in weeks, for a fixed number.
Scope one task flow
What comes back is a written scope, a number for it, and the short list of things that would change that number. In writing, not a discovery call.
About half the people who start a form never finish it
Zuko Analytics watched 93,022,997 form sessions across 17 industry categories in 2025. One thing to be plain about: that is total abandonment. Zuko does not break out why anyone left. None of it is attributed to design, and we are not going to claim it is.
Show data table
| Dimension | Completed the form | Left without finishing |
|---|---|---|
| All industries | 51.71% | 48.29% |
| On a computer | 54.48% | 45.52% |
| On a phone | 47.53% | 52.47% |
| Financial services | 58.38% | 41.62% |
| Insurance | 55.81% | 44.19% |
People who found it hard do not come back
CEB built the Customer Effort Score and was later bought by Gartner. Across more than 75,000 customers over three years, 96 percent of the people who had a high-effort experience went on to be more disloyal. In a separate test in the same programme, effort predicted loyalty 1.8 times better than a satisfaction score and twice as well as a recommendation score.
Show data table
| Item | Share who became more disloyal |
|---|---|
| After a high-effort experience | 96% |
| After a low-effort experience | 9% |
22%
Moving from 1 to 5
2%
Moving from 5 to 7
Almost all of the return sits in the first move, from bad to good. There is a second half to this that most people selling design leave out. Baymard Institute finds that 42 percent of people who abandon a cart were browsing or were not ready to buy. Baymard does not state a sample or a year on the page where it publishes that, so treat it as a direction rather than a measurement. No interface reaches them. We do not count them in what we promise. If someone quotes you a recoverable revenue figure that includes them, ask which share of it is browsing.
| Option | Loyalty lift |
|---|---|
| Moving from 1 to 5 | 22% |
| Moving from 5 to 7 | 2% |
Loyalty lift on the 7-point Customer Effort Score scale, nearly 50,000 customers. The 22% is the loyalty lift when a customer moves from 1 to 5, and the 2% is the loyalty lift when the same customer moves from 5 to 7.
Measurement is what separates a redesign that helps from one that hurts
Microsoft ran an experiment on Bing where the only thing that changed was three font colours. Task success improved and time to success improved. Two caveats we will say out loud: Microsoft keeps the exact definition of task success proprietary. Also, 10 million dollars is annualised revenue, not measured profit.
Microsoft's numbers, not ours
What a measured change looks like
Kohavi, Deng, Longbotham, Xu, KDD 2014
Same paper, Microsoft and Bing
Same paper, run because the first result looked implausible
The cost curve our category quotes, and what the measurements say
Somebody has shown you the chart where a problem caught late costs a hundred times what it costs caught early. We are not going to use it. Nearly every citation traces to Boehm in 1981. The book rests on four studies from the late 1970s. Their data points were never published. The 30x version gets attributed to NIST. The chart shows what that same report actually measured. Menzies, Nichols, Shull and Layman went looking for the effect across 171 projects and 47,376 defect logs. They did not find it. Those were TSP projects, which front-load reviews. So the result may not generalise. Fixing a flow before it is built is still cheaper. It is cheaper by an amount nobody has credibly measured. We would rather say that than quote a number at you.
Show data table
| Item | Cost of fixing it at requirements against after release |
|---|---|
| Cited as | 30 x |
| Measured in hours | 5 x |
What this costs, and what moves the number
| Shape or term | What it covers |
|---|---|
| One task flow | What it coversA single named flow, bounded in weeks. Research with real participants. The current flow mapped, with the drop-out points marked. The redesigned flow. A specification your software engineers can build from. The smallest thing worth buying, and the one to start with if you have been burned before. The conformance pass is included. We come back for it once the flow is live. |
| The flows that carry the business | What it coversThe two or three journeys your revenue actually runs through, done together so they stay consistent with each other. Ends in a build-ready specification: every state, every error, every empty case, in your existing components where you have them. The conformance pass is included here too, once each flow is live. |
| Alongside the build | What it coversThe same work running next to your delivery, plus the conformance pass. What is different here is timing. We are in the codebase while the code lands, so drift gets caught as it happens rather than after. |
| What moves the number | What it coversHow many distinct task flows are in scope. That is the main driver and you can count it yourself. Then: whether we can talk to your own users, or have to recruit strangers who resemble them. Whether a component set already exists. How many surfaces the flow has to work on. Whether we hand over and stop, or stay through implementation. Regulated and safety-critical work costs more, because the evidence bar is higher. |
| After you sign | What it coversThe number is fixed for the named scope. If the scope changes, we re-estimate it and agree it with you before the work happens. |
| For context, from other people | What it coversNielsen Norman Group publishes that its consulting projects typically range from $40K to $200K USD, and Parallel publishes that its engagements typically start at $10k. Both read in August 2026. Ours depends on the scope above, which is why we would rather scope it than post a band. |
Get a number for your scope
Answer these and we come back in writing. If the honest answer is that you should buy the smaller shape first, we will say that instead.
| Stage | What happens | From your side |
|---|---|---|
| Days 1 to 5 | What happensWhat we read before we ask anyone anything. We go through your analytics, your support tickets and your session recordings. Then we agree the one number this flow has to move. You get the current flow drawn, with the drop-out points marked and the sample size behind each one. | From your sideAccess to analytics and support, and about two hours from whoever knows the flow best. |
| Weeks 2 to 3 | What happensSessions with real people, doing the real task. Moderated task-based sessions, 8 to 12 participants per flow. We recruit from your own users where you can introduce us. Where you cannot, we recruit against a screening definition you approve. Every session is recorded. We write up what people did, not what they said they liked. | From your sideAn introduction to your users if they are reachable, or a screening definition we can recruit against. Plus two to four hours across the fortnight. |
| Weeks 3 to 5 | What happensRedesign, then specify it properly. We redesign the flow, then write it down: every state, every error, every empty case, in your existing components where they exist. Your software engineers get something they can build from without having to guess what happens next. | From your sideOne working session with the software engineer who will build it, before we finish. That way nothing in the specification is unbuildable in your stack. |
| After the build | What happensConformance and fix. We walk the shipped flow against the specification, list every place it drifted, and fix the drift with your team. | From your sideA build we can reach and a branch we can work on. This stage is in every shape. Tell us the flow has shipped and we schedule it. |
We check what shipped against what was designed, and fix the drift
Here is the part that usually goes wrong, and you already know it if you have bought this before. The designs are approved and the software engineers start. The real decisions get made at the keyboard. Spacing, the error state nobody specified, loading behaviour, and whatever turned out to be expensive in your stack. What ships is a cousin of what was designed. Nobody is at fault and nobody is watching.
Whether anyone checks the shipped interface against the design, and fixes what drifted, is rarely something you can find out before you sign. Ours is below, in writing. Ask whoever else is bidding what happens to the design after handoff.
We commit to it, and here is exactly what the commitment is. On the flows named in your scope, after the build, we go through the shipped interface against the specification. We list every place it drifted. We fix those places with your team. We can do it because we are a software engineering firm. We are still in the codebase when the code lands.
What we are not promising is an outcome. Nobody can promise you that a number moves, and anyone who does is selling you something they cannot deliver. What we put in writing is the pass itself. You get the list of every place the build drifted, and the fixes we made with your team.
the software engineering team that builds what these flows becomeName one flow and we will tell you what checking it takes
One that ran
A European hyperlocal marketplace platform came to us with a shopping experience that lagged. Not broken, just heavy enough that people on cheap phones gave up partway through. We rebuilt the frontend around server-side rendering, proper state management and memory-optimised rendering. We stayed on it while the platform grew. The load time got faster on exactly the low-memory devices where it had been worst.
We name the shape of the client, never the client. That holds for every engagement we have, including the ones who would happily let us use their name.
Atyantik engagement record, anonymised
Atyantik engagement record, anonymised
Atyantik internal firm record
Atyantik internal firm record
When this is the wrong thing
Where we fit
You have a live product and a flow you can name. This is the case this work is built for. You do not need to arrive with the number already picked: agreeing the one number that flow has to move is the first thing we do together. The smallest piece of work is enough to tell you whether the rest is worth buying.
Where we are the wrong call
You have many surfaces that all have to stay consistent, and somebody has to keep them that way.
You need an audit or remediation against a named standard, or a conformance deliverable you can show someone.
What to build is not settled yet, and the argument in the room is about the product rather than the interface.
Nothing is built yet, and there is no drop-out data to read and no flow to test.
Design systems. That is a library, a set of rules and an owner, running for years. This work is about the flows themselves, which is a different job with a different end.
Accessibility. Designing around real task flows tends to produce an interface more people can complete. That is not the same as verifying conformance against a standard, and we will not let the two be confused on a page you might quote to a regulator.
Discovery. Redesigning a flow that should not exist is the most expensive way to find that out.
MVP. Build the first version, then come back with real behaviour to look at.
The questions we get asked before signing
How much does this cost, and why does the same job quote at $500 and at $5,000?
How long before I see something?
What exactly do you hand my software engineers?
How do I know this will not make things worse?
How much time does this take from my team?
Can you start small?
Start with one flow
If the honest answer is that you should do something else first, or nothing at all, you get that instead. It is still free to ask.
- A written scope, a number and what would change it, not a deck
- The people who reply are the people who do the work
- You keep the specification and the design files we hand over
- Start with one flow and stop there if you want to