Early in my career, when I was working in graphic and web design, I designed a website that featured a unicorn. The client reviewed it and asked whether I could make the unicorn more realistic.
It was an inherently contradictory piece of feedback, and therefore quite funny, but it was not meaningless. The client had recognised a discrepancy between what they had imagined and what I had produced. They simply did not have a particularly precise vocabulary for describing that discrepancy.
On another project, I was asked to make a design more “quirky”. Quirkiness presented much the same problem. It was perfectly possible to recognise it, and perhaps even to agree when it had been achieved, but considerably harder to define it in advance as a set of objective design properties.
These sorts of conversations were normal. Design is full of subjective language: warmer, cleaner, more premium, less corporate, friendlier, stronger, more contemporary. A designer who responds by asking the client to define each adjective precisely is unlikely to get very far. Equally, taking the words literally and making arbitrary visual changes is unlikely to produce good work.
The useful work lies between those two extremes.
I learned to construct a frame of reference around what the client was trying to express. I would ask about music, films, art, brands and other designs they liked or disliked. These references did not provide a specification in themselves. What they provided was context: enough overlapping evidence to begin understanding the client's aesthetic vocabulary and the response they wanted to create.
I came to think of this as finding the musicality of the requirement. Once there was enough shared context, I could begin to riff on it.
Years later, working in business analysis, ERP implementation and solution architecture, I began to recognise essentially the same problem in a different vocabulary.
The unicorn had become a workflow.
Business requirements rarely arrive as requirements
It is convenient to imagine that discovery consists of asking stakeholders what they need and recording their answers. In practice, people rarely describe their businesses in the form in which a delivery team needs to consume that information.
They say things such as:
- “It's a bit clicky.”
- “We need better visibility.”
- “Can we automate this?”
- “We need a dashboard.”
- “It should work like the old system.”
- “We need another approval step.”
None of these statements should be dismissed. Each contains information about somebody's experience of the current operation. But they are not yet sufficiently defined to be treated as solution requirements.
Consider “it's a bit clicky”.
The literal interpretation is that the number of mouse clicks should be reduced. Sometimes that is exactly the right conclusion. But business software presents a particular challenge because the interface is often exposing a genuinely complex operating model. A modern ERP may contain finance, sales, inventory, purchasing, manufacturing, projects, documents, communications and reporting within a single application.
It would be perfectly possible to reduce navigation by putting more information and more actions on every screen. The result could also be substantially worse.
There is a relationship here with signal-to-noise (there's an article for that, stay posted! Ed.). Removing a click has value only if it reduces friction without simultaneously increasing the amount of irrelevant information the user has to process. The meaningful question is therefore not simply how many clicks a process contains, but what the user is attempting to accomplish, what information they need at each point, which decisions they are being asked to make, and which steps genuinely add no value.
The phrase “too clicky” is useful evidence. It tells us where to investigate. Treating it as a specification would confuse the symptom with the outcome.
This distinction matters because much of the cost and disappointment associated with technology projects comes not from an inability to build what was specified, but from specifying the wrong thing with great precision.
Requirements are interpretations of evidence
My own working definition is that a requirement is an outcome based on an input.
Something occurs, becomes known or changes state. The organisation requires some consequence to follow.
A customer places an order. Stock falls below a threshold. A supplier misses an expected date. A payment fails. A manager approves expenditure. A service case becomes exceptional rather than routine.
Those are inputs.
The requirement concerns the outcome: what should happen as a consequence, who should know about it, what decision should become possible, who has authority to make that decision and what evidence would demonstrate that the process has worked.
This way of thinking deliberately separates the business requirement from the proposed mechanism.
“Add a button” describes a mechanism.
“Allow a warehouse supervisor to release an exceptional shipment once the credit issue has been explicitly reviewed” describes an outcome and its operating context.
A button may still prove to be the best implementation. The difference is that we now know what the button is for, what authority it represents and what successful use of it means.
That distinction becomes increasingly important as requirements pass between people.
A stakeholder speaks to an analyst. The analyst briefs an architect. The architect defines work for a consultant or developer. Someone creates a test. A user later performs acceptance.
If the original intention is poorly understood, every handoff creates an opportunity for another small interpretation. None of those interpretations has to be absurd for the final result to become significantly different from what the business originally needed.
Ambiguity compounds.
Presentation is not superficial
Dashboards illustrate another aspect of the problem because they sit at the boundary between data and interpretation.
There is a tendency in technology projects to treat the data as substantive and its presentation as cosmetic. My experience in design makes me suspicious of that distinction.
Presentation changes meaning.
A different scale can make the same movement appear dramatic or negligible. Grouping can reveal or conceal a pattern. Colour, prominence and position alter the order in which information is perceived. Aggregating a figure by week rather than by day can produce a completely different narrative from exactly the same underlying transactions.
This does not mean that data should be manipulated to tell whatever story is convenient. It means that data does not interpret itself.
A useful dashboard therefore begins with a decision, not a chart.
What is somebody supposed to understand from this information? What could they reasonably infer from it? What action might follow? What context is required to distinguish meaningful variation from noise?
A KPI that cannot inform any decision may still be interesting, but calling it a key performance indicator does not make it operationally useful.
Conversely, a well-designed presentation can make a complicated situation intelligible very quickly. Presentation is therefore not an ornamental layer placed on top of analysis. It is part of the analytical system.
The same principle applies much more broadly to software. Information architecture, workflow design and visual hierarchy affect what people notice, what they ignore and ultimately how they behave.
Not all unusual processes are bad processes
There is another danger in interpreting ambiguous requirements: an analyst can become so enthusiastic about challenging the current process that challenge itself becomes the objective.
I strongly believe that a good process should survive examination. A procedure that exists only because “we have always done it this way” deserves scrutiny.
But an unusual process is not necessarily an irrational one.
This distinction is particularly important when implementing standard business software. One of the great advantages of an ERP platform is that it embodies a large number of mature, repeatable business patterns. There is usually significant value in adapting an organisation to those standard patterns rather than rebuilding every historical habit inside a new system.
That is the rationale behind a native-first approach.
But native-first should not become native-at-all-costs.
A company's unusual way of working may be historical baggage. It may also be part of the reason its customers choose it.
Indeed, if a particular operating capability genuinely differentiates a business from its competitors, we should not be surprised if generic software does not support it perfectly. If every competitor received the same capability merely by installing the same package, it would not be a particularly defensible differentiator.
The analytical problem is therefore to distinguish variation that exists by accident from variation that creates value.
That cannot be discovered by asking only whether the current process matches the software.
It requires understanding why the process exists, what would be lost by changing it, which customers or outcomes depend upon it, and whether the cost of preserving it is justified by the advantage it produces.
“Because we've always done it this way” is weak evidence.
“This step is how we achieve the thing our customers specifically pay us for” is quite different.
That distinction is architectural, not merely technical.
Ambiguity is valuable at the beginning and dangerous at the end
One of the ideas I am building into OrchestratorOS is that ambiguous source material should be preserved rather than sanitised away.
Discovery begins with messy evidence: conversations, documents, spreadsheets, complaints, observations, old procedures, workarounds and subjective statements.
That mess is valuable.
Someone saying “it's too clicky” tells us something about their lived experience of the process. Replacing that statement immediately with a consultant's interpretation would discard evidence.
The important distinction is between preserving ambiguity as source material and allowing ambiguity to survive as a delivery instruction.
Suppose a stakeholder says:
“We need better visibility.”
That statement is recorded and then interpreted as a request for a dashboard. The dashboard becomes six charts. Those six charts are built correctly and tested successfully. At UAT, the stakeholder looks at them and says:
“That isn't really what I meant.”
This is often described as a requirements problem, but that phrase can obscure what has actually happened. Nobody necessarily failed to listen. Nobody necessarily built the wrong specification. The original statement simply passed through several layers of interpretation without anybody establishing an explicit, testable meaning.
A better delivery chain retains the original statement as evidence, but progressively reduces the ambiguity surrounding it.
What are they unable to see today?
What decision does that prevent?
What information would permit the decision?
Who needs that information?
How current must it be?
What would demonstrate that the new visibility is sufficient?
Only after those questions have been answered should the proposed mechanism acquire the status of a requirement.
That is one of the reasons I favour connecting discovery evidence directly to outcomes, acceptance criteria, implementation and customer validation. The aim is not to create more project documentation. It is to shorten the distance between what somebody originally meant and what eventually gets delivered.
Discovery is an interpretative discipline
This also explains why I do not regard business analysis as transcription.
Artificial intelligence can already transcribe meetings extremely well. It can summarise conversations, identify repeated terms and produce plausible user stories from source material. Those are valuable capabilities.
They do not eliminate the interpretative problem.
The difficult work lies in distinguishing a symptom from a requirement, a proposed solution from an outcome, a historical habit from a competitive capability, and an interesting metric from an actionable one.
That work requires context.
It also requires challenge, but challenge should not mean automatically rejecting what a stakeholder says. A useful consultant should be capable of holding two thoughts simultaneously: the person describing the problem may not yet have expressed the requirement precisely, and they may understand something about their business that the consultant does not.
The purpose of questioning is therefore not to force the stakeholder towards the consultant's preferred answer. It is to construct enough shared understanding that both parties can recognise whether the eventual solution addresses the original need.
This is surprisingly close to the way I learned to work as a designer.
A client did not need to understand typography, visual hierarchy or colour theory in order to tell me that something felt wrong. Their reaction was evidence. My responsibility was to interpret that evidence using the skills they had engaged me to provide.
Likewise, an operations manager should not need to arrive at an ERP discovery workshop having already translated their experience into a perfect functional specification.
If they could do that reliably, much of the discovery work would already have been completed.
From interpretation to acceptance
The final step is the one that turns interpretation into engineering: making the outcome falsifiable.
If we believe we have understood what “less clicky”, “better visibility” or “more quirky” means, we should be able to demonstrate the result and allow the person who expressed the need to decide whether our interpretation was correct.
This is where acceptance criteria become more than a project-management device.
They are a test of understanding.
A requirement that cannot be demonstrated clearly may still contain unresolved ambiguity. Conversely, a small, explicit outcome can often be shown early, challenged cheaply and refined before several dependent assumptions have accumulated around it.
This is the deeper reason for the progression I use in OrchestratorOS:
source evidence → interpreted outcome → acceptance criteria → smallest useful implementation → evidence of acceptance.
The technology involved can vary considerably. The reasoning process should not.
The objective is to allow complexity where the business genuinely contains complexity, while preventing accidental ambiguity from multiplying through the delivery process.
That is an important distinction.
Good architecture is not the elimination of complexity. Businesses are complex because customers, people, money, products, suppliers and exceptions interact in complex ways.
The work is to make that complexity intelligible enough to make deliberate decisions about it.
Years ago, that might have meant establishing what a client meant by a “more realistic” unicorn.
Today it may mean determining what an operations director means by “better visibility” or what a finance team means when they say a process needs “more control”.
The underlying discipline is remarkably similar.
Listen to the language.
Preserve the evidence.
Establish the frame of reference.
Challenge the assumptions.
Understand the intended outcome.
Then make the interpretation precise enough to test.
The unicorn was never really the requirement.