Design input beyond requirements

Using value drivers to shape real design decisions

When organisations look to develop a product—internally or with external assistance—the instinct is often to start by writing a comprehensive requirements specification. This document is expected to define scope, support cost and schedule estimates, and provide a basis for verification and validation later on.

That instinct is understandable. Requirements feel solid. They feel contractual. They feel safe. They promise to translate imprecise stakeholder needs into a format suitable for engineering work.

But when requirements become the only form of design input, something important is lost: guidance on how the product is meant to deliver value in use. On how to make it genuinely good rather than merely acceptable.

In this note, I explore why pass/fail requirements alone are insufficient, why they are most powerful when kept focused and minimal, and how introducing a small number of value drivers can help guide design decisions without undermining verification, traceability, or regulatory discipline.

What requirements do well—and what they don’t

Requirements are excellent at defining boundaries. They specify what must be safe, compliant, and minimally acceptable. Standards, environmental limits, interface constraints, regulatory clauses—without these, products don’t make it to market.

Requirements act as hygiene factors. Meeting them gets you into the game. They demarcate the acceptable design space.

What they rarely do well is guide trade-offs inside that space. They seldom indicate where effort is best spent, which compromises are acceptable, or what “better” means once the minimum has been achieved. As a result, many requirements specifications describe very clearly what a product must not be bad at—while remaining largely silent on what would make it truly valuable.

Why value refuses to be binary

Part of the difficulty is that value is rarely delivered in an all-or-nothing manner.

Consider instrument warm-up time. A requirement might state: “Warm-up time shall not exceed three minutes.” Easy to verify. Yet it implies that 2:59 delivers full value while 3:01 delivers none. Users to not experience products that way. Value typically changes gradually.

he same is applies to stability, interpretability, consistency between units, or effort required to maintain performance. Improvements in these areas usually come at a cost elsewhere—power, complexity, flexibility, development time.

Design is therefore not about hitting a single target. It is about navigating trade-offs between competing qualities. Requirements define the boundaries of that space, but they rarely indicate where within it the product should aim to operate.

That choice is where value is created—or lost.

I find it useful to think of design as navigating a landscape rather than aiming at a single point. Requirements define where you are allowed to walk—the boundaries of the terrain. Within those boundaries, value is uneven: some directions lead uphill, others downhill. Progress involves trade-offs rather than clear wins. What matters is not simply remaining inside the borders, but understanding where the high ground lies.

Value drivers: a different kind of design input

This is where value drivers become useful.

Value drivers are not requirements in the traditional sense. I avoid calling them that deliberately—not because they are optional, but because their function is different.

A value driver expresses how value is created for a particular stakeholder. It is directional rather than binary. It legitimises certain trade-offs over others and guides architectural decisions early, when they are still inexpensive to change.

Value drivers do not replace requirements. They sit alongside them.

Requirements define what must be true, what must not go wrong; value drivers define what makes a design worth choosing, they clarify what matters most.

Different stakeholders, different value drivers

Products rarely have a single stakeholder. Users, buyers, patients, operators, service teams, regulators, manufacturers, and developers all experience value differently—and sometimes in tension with one another.

As a developer, I may again value different aspects: the ability to reuse proven architectures, circuits, or software modules from earlier projects. That reuse can reduce risk, shorten development time, and improve reliability—even though it is largely invisible to the end user.

All of these are legitimate value drivers. Making them explicit allows trade-offs to be discussed deliberately, rather than discovered painfully later on.

From hygiene to guidance

For example, alongside a formal accuracy requirement, I might introduce a value driver such as: “Under unchanged conditions, repeated measurements should behave predictably enough that users do not feel compelled to verify results during a normal working shift.” This is not a pass/fail statement. It does not specify a single number. But it immediately pushes design discussions toward stability, drift visibility, internal references, and confidence signalling.

Similarly, a value driver aimed at buyers might state: “Nominally identical units should behave consistently enough that results can be compared without per-unit tuning or adjustment.” This legitimises effort spent on manufacturing consistency and architectural robustness, even if those choices slightly increase development cost.

And a value driver aimed at development risk might state: “Where feasible, the design should favour reuse of previously proven subsystems over novel implementations, provided this does not compromise primary user value.” That explicitly acknowledges developer value—and makes it discussable, rather than something that quietly biases decisions anyway.

Why fewer requirements often lead to better designs

There is a common assumption that more comprehensive requirements produce better outcomes. The logic is simple: greater precision reduces ambiguity.

In practice, the opposite is often true.

Every requirement—and every tightly defined threshold—removes degrees of freedom from the design space. Constraints are necessary, but when they accumulate too early, exploration becomes constrained before understanding has matured.

What appears to be clarity becomes pre-emptive optimisation.

Experienced designers often recognise this intuitively. They aim to keep early requirements minimal and boundary-focused: just enough to define what must not be violated. Doing so preserves freedom to explore architectures and trade-offs before committing to specifics that are difficult to undo.

This is where value drivers become particularly important.

In such a deliberately wide design space, guidance becomes more important, not less. Value drivers provide that guidance. They do not constrain solutions directly; they pull the design toward regions of higher stakeholder value.

Requirements define the edges of the field. Value drivers influence how the game is played.

From intent to evidence

In regulated or safety-critical contexts, value drivers must ultimately connect to evidence. In practice, I treat them as design intent and decompose them into questions that can be examined:

• What does “predictable behaviour” mean in terms of repeatability or drift?
• How quickly would instability become visible?
• What diagnostics make uncertainty observable?
• How much user intervention is required in normal operation?

Each question can be explored through bench data, ageing studies, unit-to-unit comparisons, usability work, or field trials. No single test proves “value”, but together they demonstrate alignment between intent and behaviour.

Value drivers do not weaken verification. They enrich it.

Why good design input evolves

Value drivers rarely appear fully formed at the start of a project. Understanding where value really lives is often iterative with doing the design work itself.

Early drivers are broadly directional. As prototypes are built and failure modes uncovered, they sharpen. Some are refined. Some are split. Occasionally, some are discarded. What matters is that their evolution is deliberate and documented, rather than implicit.

Design, verification, and validation are not strictly sequential steps. They inform one another continuously. Effective design input reflects that reality.

A simple sense check

One question I often return to:

“If this product passes all of its requirements, will it still feel like a good design six months into real use?”

If the answer is uncertain, compliance may be well defined—but value is only implicit.

Making value drivers explicit has proven one of the more reliable ways to close that gap.

What this means for how we work together

This perspective has practical implication for how collaboration is organised.

When requirements function primarily as a contract—a complete, fixed description of deliverables—fixed-price agreements make sense. They provide clarity when uncertainty is low and value is already well understood.

Value-driven design operates differently. By keeping early requirements focused and preserving design space, we accept that some important questions can only be answered through exploration. Progress becomes gradual rather than binary. The point at which additional effort yields diminishing returns becomes a matter of judgement.

Under fixed-price arrangements, incentives can drift apart. Designers are rewarded for stopping when requirements are met. Clients are rewarded for freezing scope early and resisting adaptation. Neither behaviour reflects bad intent; it reflects rational responses to contractual framing.

Collaborations aimed at explore value benefit from structures that make judgement explicit: phased work, time-boxed iterations, and regular checkpoints where learning, priorities and trade-offs are reviewed deliberately. Cost exposure remains controlled, but flexibility is preserved where it creates the most impact.

The shift is not from rigour to informality. It is form defining success solely in terms of specification compliance to defining it in terms of value realised.