The Design Process and the Scientific Method

Every once in a while, there are rumblings about how the design process should be more like the scientific method. Although I profoundly disagree with this (more in a moment), I can understand this impulse. The design process is messy, difficult to explain and sell, and its results are not certain from the beginning. People want more predictability. (We even heard that one of our competitors was selling their services as “a design machine” to a prospective client in order to claim their process was more reliable.)

What is it about the scientific process that people admire? Predictability, certainty, and repeatability. The essence of the scientific method is to test a hypothesis: if I try this, will it work, yes or no? Any time I repeat that process, if done correctly and no other variables are introduced, I should get the same response. The response can be tallied, measured, and recorded.

For observing, analyzing, and understanding natural phenomena and even for some engineering tasks, this process makes sense. But it does not work well for design, because good design is not repeatable. The general design process is certainly repeatable (strategy > research > concepts > refinement), but the outcome, the result of the process, is never repeatable and never guessed at from the outset, for the simple reason that context in design is too important. I can use the exact same process with two similar organizations working in the same field and end up with two widely varying products. Perform the same process with the same group of people a year apart, and you will get different outcomes. Unlike in science, where, when, and, especially, who is performing the design activity matters.

Unlike the scientific method, which attempts to strip humanity out of its practitioners (because you want the results to be able to be repeated (and tested for accuracy) by anyone able to follow the formula/process), the humanity of the participants is enormously important in design. Different designers may, of course, come up with the same solution, but in design, very frequently there is no one correct solution. The solution that would work for one organization might not for another. Someone inside LG or Motorola might have come up with something similar to the iPhone, but even if they had, it wasn’t the right solution for their organizations. It would have been rejected (likely to their later dismay). The solution has to work for the context.

As materials, technologies, styles, cultural attitudes, etc. change, the solution that was correct five years ago, could seem hopelessly dated. Again, this is in opposition to the scientific method, where the search is for solutions that are good for long periods of time (ideally forever, until a new theory or new data challenges it).

Of course, design outcomes (i.e. products) will be imitated. Knock-offs and clones will be made. But they are not outcomes of a design process, but of a manufacturing or development process. The purpose of a design process is invention: to create something new. The purpose of the scientific process is the discovery of something new. It’s a subtle, but important distinction.

This is also not to say that data doesn’t have a place in the design process. You can use research to enhance or inspire your decisions. You can test different solutions and the data can certainly suggest which solution could be the better one, but data can’t make design decisions, only humans can. Jensen Harris has a great story about using data to design Office 2007:

Many people suggest that “you guys should optimize the UI to match the feature usage data.” On the surface, this sounds like a solid idea; you could have a computer determine the organization and prominence of different features depending on what part of the curve they are in. It would be very scientific. The only problem? We’ve already designed that product, and it’s called Office 2003.

Put another way: if all we want to do is design a product that matches today’s pattern of feature usage—well, I don’t have to do any work! Office 2003 already matches the curve exactly; we can’t do any better than statistical perfection.

The real equation at work here is data + human = design. We need to take the data, analyze it, understand its shortcomings, and use it to inform a design which meets our goals. But, in itself, the data cannot produce a UI because it has no goals and is a reflection of the DNA of a product you already shipped!

Exactly so. Applying the data as it seemed it should have been used, in a scientific manner, would have re-created Office 2003. And no one—I mean no one—wants that. In any case, you cannot test something (or at least test something well) that hasn’t been created yet. No

And here’s one final, secret reason why the design process should never be more like the scientific method: it’s irrational, in the best way. The best designed products, the ones we admire and, more importantly, cherish are those that are emotional and often idiosyncratic. And, often, so is the design process that creates it. Michael Beirut nails this in his article “This is My Process:”

Sometimes I have one great idea but can’t convince the client it’s great and I have to do more ones. Sometimes this leads to a better idea. Sometimes it leads to a worse idea. Sometimes after I go back and explore other ideas we all come back to the original idea. Sometimes the client accepts an idea, and then produces other people who haven’t been involved up to that point who end up having opinions of their own. One way or another it always seems to get done, but never as originally promised.

This is how the design process works. There’s nothing very scientific about it, nor, I think, would we ever want it to be, lest we lose the very things that make it design—the emotion, the humanity, the decision-making—in the first place.