Thoughts
Knowledge is created. And in the process of sketching things, we create it over, and over, and over. We often believe that knowledge exists, and it's our job to find it, read it, and absorb it. And for most of us, and in most situations, that's true—we're not the ones creating the knowledge, we're the ones learning from it. But in some contexts, we do create new knowledge by contextualizing data, combining data, and looking at data in new ways.
One helpful way to think about knowledge being created is to imagine a scientist observing a new natural phenomenon: when she aims a water hose at the tulips sitting in her garden, the tulips begin to scream, and they raise their leaves in surrender. (Just go with it—tulips have feelings too!)
Observing that the flowers surrender isn't the creation of knowledge, it's a perceptual process. But making a claim about causality represents the application of that perception, and is the creation of new knowledge. Through controlled experiments, she can start to make deductive claims as well—claims that isolate the treatment of water-hosening. These claims are knowledge, too. And generating a theory of why or how the flowers react is the creation of knowledge as well.
The scientist didn't make the tulip; it's a natural phenomenon. But a designer (and engineer, and all other sorts of people) made the water hose. And just like the tulip isn't knowledge, neither is the hose. Knowledge was certainly used to make it. But what's compelling about the creative process is that, in the process of designing the toy, the team didn't just use existing knowledge. They created new things to know, too.
Imagine a designer is tasked with designing a tulip-scaring water hose. They get started, and spend time drawing. For about five minutes, they draw an initial form. The form matches the shape of most hoses, with a sprayer and a handle. There's not a lot of higher thinking going on, as they are essentially mimicking the archetype of a water hose—they are drawing what they've seen and experienced before. This initial drawing seems insignificant. It took them very little time. It's rough.
In fact, it's not insignificant, because they just created "things to know" about the artificial world. They haven't created knowledge of how pressure works, or how force works, or how water works, or how the bone structure of the hand works, or how the muscles work. But they have created knowledge about how that specific toy will exist. The sketch is data; that the toy will exist is an assertion of data. But their understanding of the sketch itself is knowledge. And that knowledge will inform the next sketch.
Break that down; when they started,
And then they drew something, and suddenly, they did know what it would look like.
The sketch itself is not the knowledge, just like the force of gravity isn't the knowledge. But they know things about gravity, and now they know things about the sketch. They made things to know, and it allowed them to know those things. What!
Design isn't about one and done, and so the next step is to draw the water hose again. But an iteration doesn't come from a clean slate. It's based on that previous iteration, and so that means it's based on the new things they know.
The handle of the first drawing was sparse. The designer saw that and reacted by sketching another drawing, one with more grips on the handle. This generated new knowledge of the design solution again.
And so that second iteration is based on knowledge of all of the above—knowledge of water hoses, pressure, force, anatomy—and the first iteration, knowledge of grip. They've created knowledge, and they've used it. And what's more, they used it in seconds. Iterations happen quickly. We draw, and see, and know, and react, and do it again.
They draw again, responding to the first sketch of grip, and creating a form that better matches a hand. This iteration is based on the collective knowledge of all of the other iterations.
Over the duration of a sketching session, this happens over and over and over. When we talk about how the design process is as important, or perhaps more important, than the design artifact, this is part of what we mean. The process isn't just a set of steps to follow, as prescribed by the "design thinking" colloquialism. It's cognitive, and it's generative.
Think of the implications of this on three main functions of our job as professional designers: craft, critique, and persuasion.
The stimulus for the scientist to begin their knowledge-creation exploration was to observe a natural phenomenon and try to reproduce that phenomenon in a controlled environment. The phenomenon of scared tulips was visceral and real—it was a high fidelity phenomenon (the highest: it doesn't get more real than real.) Reproducing that phenomenon requires creating a simulation that is as close to a real level of fidelity as possible. This is part of the craftsmanship of a good experimental design. While initial explorations may be crude tests of the experiment itself, they aren't sufficient to generate the data necessary for the creation of knowledge, highlighted in a theory.
The implications of this for design is that the craft of execution during the iterative process is directly related to the craft of knowledge that is produced, and the implications of that means that designers need to know how to draw. I don't mean draw with pencil and paper, although that's always helpful. I mean drawing as making, and in whatever medium the designer is working in. Some sort of artifact needs to be made in order to generate knowledge in order to make something better. While that artifact will increase in fidelity through various iterations, it shouldn't increase in craftsmanship: a low-fidelity sketch can still have attention to detail, can still capture intent, and can build on knowledge.
In fact, it has to, or else the knowledge that will be created will be wrong. This isn't to say that whatever the designer made is wrong—that's not a word that means a lot in the context of judging design. It means that what the designer knows about what they made is wrong. There's not enough detail and substance in what they made to truly help them learn from it. It would be like writing a book on science if you didn't know anything about science, and then expecting to be able to read the book and learn about science.
I would argue that one way to achieve bad design is to iterate without craft in making. Without craft during iteration, no matter what the craft of final execution, the knowledge created along the way will be poor or incomplete.
To produce relevant knowledge during design, we need a high level of craftsmanship during iteration.
A critique is an opportunity to bring people together with the sole purpose of improving an existing design. Critiques are typically led by experts (creative directors, or senior designers.) Often, a critique is based on opinion. Opinions are in turn based on experience, and often, grounded in knowledge.
But it's hard to articulate what we know. Experts have "tacit knowledge"—knowledge that they have realized so strongly that they are unable to describe it to someone else. Often, professionals aren't even aware that they have that tacit knowledge; it just is.
And, if you ask an expert to tell you everything they know, most won't be able to do it, because that's not how knowledge is imparted. Teaching is fundamentally about helping people learn. Most teachers have knowledge. But learning isn't about being told the knowledge. Learning happens experientially.
This has implications for how a critique is run. If the critique takes the form of experts telling the designer what is wrong and what can be improved, they aren't passing knowledge, or helping that designer develop their own knowledge. They are providing data. They are saying to the designer, "Look, that tulip is scared."
If design knowledge is generated through iteration and experience, then a critique needs to be formed around those iterations. The participants need to draw and provoke new knowledge and new stimuli. This can happen collaboratively; it has to happen collaboratively in a critique setting, because if all of the participants are drawing their own iterations, only the artifact is shared, not the knowledge that was created while making it.
Perhaps a critique should be renamed a "collaborative knowledge-generation session," because that's really what it needs to be to be relevant for further design.
Knowledge is created during the process of design, and it's held in the head of the people that created it. It's not impossible for other people to acquire that knowledge: that's what learning is. But in the same way that we don't learn how to play the violin through a lecture, we also don't learn design knowledge by hearing about it. We have to experience it.
That makes a persuasive presentation extremely difficult. And like it or not, good design doesn't speak for itself in the context of a corporation or consultancy. It has to be sold, often to skeptical or nervous buyers.
I think that to believe in a design that doesn't yet exist—that can't be actually used and experienced—we need to believe in the knowledge that went into making it. This means that the task of the designer is to teach while selling. As a teacher, my main tool is experiential learning. And if I can't create a context for experience, my next best tool is narrative and storytelling. Stories can impart knowledge, but in a softer guise than facts, because stories—at least good ones—capture attention. It's very hard for most of us to become fully, intellectually engaged during a lecture of facts. It's much easier during a good story.
To get stakeholders to believe in what we made, we need to persuade them. To persuade them and give them criteria to judge the work, they need the knowledge that we generated. And to get that knowledge, they need to have a learning experience. This may be through narrative, a storyboard, a demonstration, or an actual working product.
Design is a way to generate knowledge. This happens through iteration: making things makes us know about the thing we just made. This shifts our normal view of thinking—that it is something that happens in our head—to something that is also partially external. Making a mark is a stimulus for thought, and the mark-making-thought-mark-making-thought process is happening so fast that the delineation of the two is nearly impossible to discern. There's a caveat: to work that quickly means having an intuitive and reflexive ability with the medium. If I'm judging the execution of my drawing, I'm not learning from the knowledge I've made.
The design-as-knowledge-generation begins to highlight the implications of hiring decisions. If we hire junior designers with an attempt to help them grow, this comes with more baggage than just "they need mentorship" and "they need to improve through experience." It actually means that what they are making will be "bad knowledge." If it's used without check to improve a further set of iterations, that knowledge will be the base for poor understanding. If we believe the world is flat, and base all of our future assumptions on this "knowledge," the rest of our worldview will be a house of cards. To work with junior talent requires a constant set of knowledge-redirections: more than once a day, and perhaps more than once an hour.
It also means we need to stop speaking of design as a split between interaction design and visual design, or between flow and aesthetics, or between "UX" and "UI". While it's a reality that designers have a predilection to one set of skills over the other, if the knowledge for how things work and how things look is produced separately, the end result will be internally illogical. This doesn't mean all designers must be experts in all things. It does mean that the processes need to happen concurrently, and through an organic mixture of experience-based collaborative sketching and critique.
And, if design creates knowledge, it means that we need experiential persuasion to gain buy-in. We need to tell stories, and bring ideas to life, in order to recreate the knowledge that is now, for us, tacit. Our work cannot speak for itself, and we can't just show it. We need to teach it.