Every discovery workshop produces the same vocabulary. The system is slow. The process is clunky. The customer experience is poor. The platform is too expensive. Competitors are faster. Each of these is sincerely meant and usually true in some sense. None of them can be designed against.
"Slow" does not tell you what is slow, for whom, compared with what, or how fast it would need to be before anyone stopped complaining. A design that answers "slow" will be judged on feel, and feel changes with whoever is in the room. Worse, two people who both say "slow" often mean entirely different things, and the design ends up trying to satisfy both without anyone noticing that they disagree.
The fix is not elaborate. It is a habit: before drawing anything, turn each important word into a number with a baseline and a target. This part shows the small frame we use, how it played out at the series' fictional bank, and what to do when the numbers you need do not exist yet.
Why words are not design inputs
A design input is something a design can be checked against. "Reduce decision time from five working days to same day" can be checked. "Make it faster" cannot, because any improvement qualifies and no amount of improvement is ever enough.
Vague words cause three specific problems in architecture work.
They hide disagreement. When the head of sales says the loan process is slow, that may mean customers wait too long for an answer. When the head of credit says the same thing, it may mean that underwriters spend too long per file. Those point to different designs, and often to opposite trade-offs.
They invite technology-shaped answers. "Slow" sounds like a performance problem, so the conversation drifts to faster infrastructure. In Part 1, Klipspringer Bank's application screens loaded perfectly quickly. The slowness was a queue of people.
They make success unprovable. Without a baseline, nobody can say afterwards whether the programme worked. That is bad for the business and, frankly, bad for the architect, whose design will be judged on anecdote.
A small measurement frame
Klipspringer Bank is fictional, and its systems and figures are illustrative. When its architecture team sat down with the personal-loans unit, they used five questions. The questions are deliberately plain, so that a business owner can answer them without help.
| Question | What it uncovers | Klipspringer's answer |
|---|---|---|
| Where does the outcome fail? | The point in the journey where value is lost | 35% of completed applications leave before a decision |
| How long does the work take? | Elapsed time, end to end | Five to seven working days to decide |
| Where is the waiting time? | The gap between elapsed time and actual work | About two days before review even begins |
| What is the comparator? | The bar customers are actually using | A competitor decides within hours |
| What outcome must change? | The target, in the business's terms | Same day for at least 60%, abandonment under 15% |
Notice the order. The first question finds where value leaks. The second and third separate elapsed time from work, which is the single most useful distinction in process discovery. The fourth anchors the target in what customers see elsewhere, not in what the team thinks is achievable. Only the fifth sets the target, and by then it is grounded.
Elapsed time is not work time
Klipspringer's most important number turned out to be the difference between two others. A loan decision took about six working days. The hands-on work across that period, the minutes an underwriter actually spent looking at an application, came to about two hours.
The rest was waiting. Applications sat for two days in a shared queue that nobody owned. When an underwriter finally opened one, there was a good chance a payslip page was missing or a bank statement was an unreadable photo, so the application went back to the customer and waited again. Loans above R150,000 needed a second signature, and the second signer had their own queue.
This changes the design question completely. If the work took six days, you would look at automating the work. Because the work took two hours, you look at the waiting: why the queue has no owner, why the upload screen lets incomplete documents through, and whether the second-signature rule is set at the right level. Those are cheaper changes than any platform migration, and several of them involve no new technology at all.
Most organisations we work with have never measured this split. It is worth doing even when it is rough. Take thirty or fifty recent cases, record when each one arrived, when someone first touched it, when it left each step and when it finished. A spreadsheet is enough. The ratio of work to elapsed time is usually startling, and it immediately tells you where the design effort belongs.
When the numbers do not exist
Klipspringer was lucky: the data existed, it just lived in two places. Often it does not exist at all, or exists only in a form that would take months to clean. That is not a reason to skip this step. It is a reason to measure crudely and soon.
Sample by hand. Thirty cases traced by a person with a stopwatch and a spreadsheet will tell you more in a week than a data platform will in a quarter. You are looking for the shape of the problem, not for statistical precision.
Use existing timestamps. Emails, workflow logs, document upload times and system audit trails all carry times. They are imperfect, but stitched together they usually reconstruct the journey.
Ask for ranges, not points. "How long does approval take?" invites a defensive single number. "What is the fastest you have seen, the slowest, and the usual?" gets you a range that is closer to the truth.
Write down what you could not measure. An unmeasured number is an assumption. Record it as one, with an owner and a date to replace it with evidence. The requirements and assumptions discipline from our proposal-writing series applies directly.
The number that must not get worse
Every target has a shadow: the thing you could damage while hitting it. Klipspringer could make loan decisions faster by approving more applications automatically. It could also lend to people who cannot afford the repayments, which is both a credit loss and, for a South African credit provider, a breach of the affordability assessment required under the National Credit Act.
So the frame needs one more line, a guardrail measure that the programme commits not to worsen. Klipspringer picked three: the credit loss rate on new loans, the share of applications flagged for fraud review, and the proportion of decisions where the affordability assessment was fully documented. Each had a current baseline. The programme was judged on moving decision time and abandonment while holding those three steady.
This is not bureaucracy. A guardrail measure is what lets the business say yes to an ambitious target, because it limits the downside. Without one, the risk function's only safe answer is to slow everything down.
Keep the set small
There is a failure mode on the other side, too. Once a team discovers measurement, it can produce forty metrics, each defended by someone. Forty metrics are as useless as none, because nobody can hold a design accountable to all of them.
We aim for one or two outcome measures, two or three guardrails, and a handful of diagnostic numbers such as the waiting-time split that explain why the outcome is what it is. Everything else is reporting. Klipspringer's whole programme fitted on one page: decision time, abandonment, three guardrails, and the queue and rework figures that explained them.
When the programme later reached design decisions, such as which components to replace in Part 4, each option was tested against that one page. An option that did not move decision time or abandonment did not survive, however attractive it was technically.
Key points
Vague words hide disagreement. Two people saying "slow" often mean different problems with different designs.
Five plain questions are enough. Where the outcome fails, how long the work takes, where the waiting is, what the comparator is, and what must change.
Separate elapsed time from work time. At Klipspringer six days of elapsed time held about two hours of work, which moved the design from automation to queues and rework.
Measure crudely rather than not at all. Thirty cases traced by hand reveal the shape of the problem.
Name the measure that must not get worse. Guardrails make ambitious targets safe to approve.
Next: Part 3, Business discovery before technical discovery. All parts are on the series page.
How CloudNala can help
We help teams turn complaints into a one-page measurement frame before design starts: trace a sample of real cases, split elapsed time from work time, agree an outcome target with its guardrails, and record what could not yet be measured as named assumptions. It is quick, it is usually revealing, and it gives every later architecture decision something objective to answer to.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an Architecture Discovery Sprint or write to us at consult@cloudnala.co.za