When is Enough, Enough? Or When Do You Stop Testing and Start Building?

One of the most challenging decisions teams face is determining when to transition from testing designs to actual development. In reality this decision is fairly straightforward. The problem is that our organisation structures and processes have made it complicated.

Design is Risk Reduction

The four key product risks: Desirability, Usability, Feasibility and Viability, are great lenses for identifying the biggest, leap-of-faith assumptions that we have in our product ideas. Leap-of-faith assumptions are the ones that are critical for the product to be successful but also the ones that we have the least amount of evidence for.

Armed with our key assumptions to test we can identify quick and cheap experiments to evaluate whether they are true or not. When running these early tests we are looking for signals and not statistical significance because the chances of our ideas being successful are low and we don’t want to over-invest unnecessarily.

As we learn more about our product and our customers we can start to increase the complexity of our experiments and the amount of evidence we need to see before we can move forward. This is where things become gray because we now have a choice between creating increasingly complex prototypes or moving to development.

The Over-Testing Trap

Design teams often feel pressure to continue reducing risk, driven by two key factors:

Professional Pride

Designers, like any professionals, take pride in their craft. It’s only natural for them to want to perfect designs before handing them off to development. This means that designers will want to continue polishing their prototypes long past the point of diminishing returns in terms of new information that we are learning.

Without clear boundaries, teams can get stuck in a cycle of constant refinement, believing they can eliminate all uncertainty through better design. The problem is that upfront experiments reduce risk but they cannot eliminate it. It is only when a customer has a product in their hands that we know for certain whether they like it or not. This means that there will always be uncertainty when we cross the design-development threshold.

Restrictive Processes

Many organisations still follow Waterfall and Water-Scrum-Fall processes where development is measured using time and cost metrics. This means that developers will prioritise building the designs they have been given rather than trying to iterate and learn whether they are the right designs.

Given these organisational pressures for delivery, designers have to continue eliminating risk past the most efficient handover point because no further refinement will happen during delivery.

Why is this a false question?

While a lot of processes view design and development as distinct phases, in reality, they are part of the same continuum. Prototypes evolve into MVPs, and MVPs evolve into fully-featured products.

Instead of viewing development as the implementation of completed designs it needs to be viewed as a continuation of the design process. In factories it is very hard to change an assembly line after it has been built. Software products aren’t assembly lines though; they are constantly evolving. We should lean into this difference instead of away from it. We need to release early and often to gather feedback from customers and iterate towards better products.

Once we phrase development as design the question of when to move from design to development is no different from choosing when to move from a landing page test to a prototype. We move when we have exhausted the value of the cheaper and easier testing approach and we have the confidence in our assumptions to move to the more accurate, but expensive, testing method.

Cross-Functional Teams: A Better Way Forward

As I mentioned above, our functional structures and processes lead to this complex, and costly, handover decision. Cross-functional teams integrate designers, developers, researchers, and product managers from the start. This collaboration eliminates the need for formal handoffs within the team and creates a shared sense of ownership.

Empowered teams also redefine the roles of designers and developers. Designers aren’t just handing off wireframes and prototypes; they’re involved in implementation, ensuring the design vision is preserved. Similarly, developers contribute to the design process, offering insights into technical feasibility and scalability.

This approach transforms design and development into a single, fluid process.

Conclusion: The Balance of Risk and Action

The question of “When is enough, enough?” doesn’t have a one-size-fits-all answer. Each product, team, and market presents unique challenges and opportunities. However, by focusing on the learning/effort balance and embracing the fluidity between design and development, teams can make informed decisions about when to transition.

Ultimately, the goal is not to eliminate risk but to reduce it to a manageable level, enabling the team to move forward with confidence. By fostering a collaborative, cross-functional approach, you can navigate this balance effectively and create products that customers love while achieving the business goals.