In my blog on design thinking , I explained that the logical core of design thinking is the design cycle: investigate the problem context, design possible solutions, validate them. In all stages of the design cycle, the designer faces uncertainty that must be managed.

  • Investigate the problem context. There will never be total certainty about what is the problem to be solved.
  • Design possible solutions. There is never total certainty about the range of possible solutions that can be designed.
  • Validate the solutions. There is never total certainty about the properties of any solution.

Despite these persistent uncertainties, the designer must come up with a result that will be implemented. There is an irreducible design risk that the wrong problem is solved or a wrong solution implemented. Here I want to discuss two important ways of managing design risk, prototyping and process management.

Prototyping

When a solution is designed, it must be validated. The ultimate test is to give it to users and see if it solves their problem. This is often too expensive or too unsafe to do. Setting up a production line for a new drug and selling it to patients just to see what happens —that is, to test it—is expensive for the manufacturer and unsafe for the patients. Validating a solution is to test it before it is implemented.

What can we do to test a solution? Sometimes, math and science can be used. For example, the forces that hold together a bridge can be computed from its design, and the attention span of the operator of an autonomous vehicle is known from psychology. Evidence from math and statistics can be used to validate a design before even a test setup has been constructed.

But this is not enough to validate innovative solutions for which there is no previous evidence. Validating an innovative design requires the construction of prototypes that can be tested. Depending on the kind of solution, these prototypes may be videos or animations of a narrative that explains the solution concept. They may be graphical illustrations, mockups, scale models, marketing material, brochures, web sites, or software prototypes. And yes, they may also be paper-and-scissor prototypes.

A test of a prototype is an experiment in a simulated or real-world problem context. The goal is to find out what the effect of an implemented solution would be. To manage uncertainty, and reduce it to an acceptable level, this is usually ordered in a series of experiments. The tests start with a simplified, safe context, and then become more realistic to end up with pilot projects in real-world contexts. How this is done is part of the management of the design process.

The Design Process

Designers iterate many times over the design cycle, and it is a concern of design management to decide in which order to make the decisions. There are some well-known approaches to this, a few of which I discuss next.

Linear design

The design process can be managed as a linear process that progresses from a thorough understanding of the problem context to the generation of possible designs, followed by testing and evaluation, concluding with the selection of one design. In a purely linear process, there is no backtracking to an earlier stage.

If we apply a linear process at all aggregation levels of the product —the system, its subsystems, their components and so on—then we get the well-known V-model of engineering.

A major risk of a linear process is that during the process, problem understanding turns out to be insufficient. But in a strictly linear process there is no room for returning to context investigation. Depending on available time and budget, we may allow iterating to an earlier stage, or we may even start a second process that starts all over again but now using the lessons learned from the first design process.

Allowing iteration or starting a second design process extends the duration of the design process. This creates the risk that by the time the design is delivered, the context has changed, making the design irrelevant. To reduce this risk, we may simply deliver the imperfect product of the first iteration to the customer and hide any redesigns in the maintenance process. We can take this idea to the extreme and choose a lean process.

Lean design

At the other extreme of linear design is the lean process in which, after a brief context analysis and solution design, a minimum viable prototype is implemented and transferred to the problem context. The prototype is not tested in the laboratory, but in the real world with real users. Feedback from real users will be used to further improve the design.

Lean design comes with its own terminology. You don’t update your design, no you “pivot” just like a basketball player does. And you don’t do something as old-fashioned like developing a product, no, you develop your customers.

A risk of the lean process is that due to the immaturity of the product, users will be so dissatisfied that they will refuse to use updates of your solution.

In the extreme case, your solution may be unsafe and harm users. Lean design may be good for developing games or social media applications, but when livelihoods or lives are at stake, it is a bad idea. For safety critical systems, some linear process should be followed. If safety is not at stake, you may consider a middle path, agile design.

Agile design

Agile processes iterate over the design process in periods of a few weeks, after which the solution is transferred to the problem context. It is the responsibility of project management to select features for the next iteration, based on risk, safety and utility for the user.

Agile design has its own terminology too. There is a “backlog” of requirements still to be implemented, the developers perform a “sprint” to produce the next iteration, and they start each day with a “stand-up” meeting to discuss progress and divide tasks.

A risk of agile design is that the project will miss the bigger innovation by iteratively focusing on the next feature achievable in two weeks. Climbing the next hill in sight may lead you away from the high mountain climbed by your competitor.

Another risk is that by successively accumulating features, product architecture slowly evolves into an unmaintainable mess.

What to do?

The core question in design management, as in all other aspects of your life, is what to do. My advice here is to not be distracted by fancy terminology nor be deluded by the fad of the day but to choose your design process based on properties of the design problem, such as the available time and money to produce a design, the (un)familiarity with the design problem, and the risks for the user.