I hear all the time from engineers and developers who disdain user-centered innovation practices. Inside jokes about the black turtleneck crowd abound, Steve Jobs notwithstanding. Conventional technical wisdom holds that “soft” front end techniques are too fuzzy, too unstructured, too based on magic or art. Certainly not up to technical snuff, and particularly “unscientific.”
As an engineer in the design field, I’m always puzzled by this claim—since good design practice seems to me to have a lot in common with the very bedrock foundation of science: the scientific method itself.
The two fields—science and design—certainly seem at face value to be light years apart, practiced by people with very different training, values, and personalities. But the problems faced by designers and scientists are similar, and the parallels between the scientific method as practiced by scientists and good innovation and user-centered design techniques are striking.
To see why, look at the essential components of the scientific method:
Characterization of phenomena via observation and recording
Formulation of hypotheses to explain the observations
Use of the hypothesis to predict new phenomena
Performance of experimental tests of the hypotheses’ predictions
Even if most normal people readily forgot these steps, together they form the pillars of scientific inquiry and are the very foundation of human discovery.
Let’s poke around with these one at a time… I’ll start with Characterization here and talk about other aspects in later posts.
The times after Copernicus were times in which there were great debates about whether the planets in fact went around the sun along with the earth, or whether the earth was at the centre of the universe and so on. Then a man named Tycho Brahe evolved a way of answering the question. He thought that it might perhaps be a good idea to look very very carefully and to record exactly where the planets appear in the sky, and then the alternative theories might be distinguished from one another. This is the key of modern science and it was the beginning of the true understanding of Nature – this idea to look at the thing, to record the details, and to hope that in the information thus obtained might lie a clue to one or another theoretical interpretation. [Emphasis added]
Think about that. Although he had his own views, Tycho Brahe believed that the truth would follow from setting aside his assumptions and observing and carefully recording what he saw.
So what does Tycho have to do with product design and innovation?
Well, the essential questions in product design are what to make, how to make it and how to profit. “Great debates” often ensue about these questions—arguments rage about what the requirements really are, what features should be included, and what people really will want, use or value. I saw these arguments every day in my previous life doing innovation in a big tech company—I’ll bet you see similar arguments in your company as well.
With innovation based on customer-centered design, our approach is similar to Tycho’s: observe and record. Characterizing the behavior, attitudes and values of a product’s intended users gives designers data to design from—really not much different than Tycho’s carefully recorded data about planetary positions giving Johannes Kepler the data he needed to derive the laws of planetary motion. In both cases, observation about the natural world yields the raw material for innovation. In both cases, the imperative is the same: set aside assumptions and record what you see—not in a lab, but in the real world. There are lots of ways to do this work for customers; I’m biased toward Contextual Inquiry and it has significant advantages, but it’s by no means the only way to get the job done.
Now, scientists have a bit of an advantage over designers—an unambiguous language to record and talk about their observations, namely mathematics. Observations can be recorded, analyzed and shared using this common language.
Designers face the same challenge: they also need a language to talk about user observations. Otherwise, discussions about customer observations devolve into anecdotes and stories: “I saw this,” “you saw that.” To address this problem, designers have created formalisms to represent user behavior for product design, including process mapping, use cases and personas. The work models used in Contextual Design are another example. Although there are lots of user behavior models out there and none have the precision nor the universality of mathematics, representing observational data in a formalized way is crucial to making that data actionable when it’s time to create designs and capture requirements.
Using models instead of stories has three main advantages. First, it allows you to compare the findings of one field interview with another and recognize patterns across a market in a much more robust way. As an example from my distant past, what looked like lots of disconnected stories about interpersonal friction getting in the way of customers “properly” using my system management software became visible as symptoms of a common cultural pressure when I represented my data using a cultural model. Second, using formal models gives your designers, engineers, business analysts and others on your product team a language to talk about customer data. This helps a cross-functional team talk about implications of what they found, and also helps them know what to pay attention to when they’re in the field gathering data in the first place. And lastly, recording data using models makes the data externalized and extendable—so your record of customer intimacy becomes a living corporate resource instead of tacit knowledge stuck inside the marketing guru’s or chief designer’s head.
So the first step in user-centered innovation is similar to the first step in the scientific method: observe and record. In my next post, I’ll talk about the crucial step in both design and scientific inquiry: hypothesis creation. We’ll see some important and crucial differences, including the distinction between quantitative and qualitative data, and what makes experimental design different from prototype testing. But we’ll also see some interesting parallels.
One last thought. Your third grade teacher was probably not Richard Feynmann, but I’ll bet he or she taught you that to write well, you had to first understand your audience. Even the infamous Mr. Cliff knew that. Product design is no different – you have to understand your audience to do that well, too.