My favorite way to think about the work of a designer.
The phrase may feel fuzzy and ambiguous at first, but it smuggles in a lot of information when you stop and reflect.
This process of reflection in action built upon knowing in action is what is crucial to professional knowledge. In fact, it’s crucial to any practical competence. It is what enables us to deal effectively and well when we do so in situations of uncertainty, uniqueness, and conflict.
Something is resonating here...
I like this. A lot.
It’s from a wonderful lecture by Donald Schön.
Donald claims that every profession is confronting a dilemma of rigor or relevance. On the “high ground” the problems are trivial. In “the swamp” below you can work on the important social and technological problems of the age, but you don’t know how to be rigorous in any way that you can name.
This difficulty to describe what these professionals are doing comes from what he calls indeterminate zones of practice.
I can’t remember working in an environment where I wasn’t in at least one of these zones. This makes me uneasy, as Donald explains, because I am unable to explain what I do while I’m in these zones.
I make progress. I struggle to describe how I do it.
I have competency. I struggle to describe what it is.
I don’t know if this makes me feel better or worse. Although, I’m grateful that I now have language to for this troublesome sensation I’ve felt all my career.
Conceding research as a separate function from practice may be the greatest failure of modern creative industries. When I first began doing research I would have fought this perspective with every argument I could muster. Now, reluctantly, I tend to agree.
Rigorous research is incompatible with practice. You can't do rigorous research in a practice situation which is notoriously shifting, uncertain, and uncontrolled. The scientific method can only be applied in the laboratory or if you're able to look at large amounts of data reflecting past experience.
But technical rationality cannot take account of uncertainty, uniqueness, and conflict. And these zones of practice have become central and salient over the past 20 years.
One of the questions Donald asks should be the core concern of research activities. It flips the situation from separating yourself from the concern while gathering information, to participating in the process to better understand the conditions and consequences.
When people do things well, what kind of knowledge do they reveal?
The philosopher Micheal Polanyi calls this tacit knowing, more commonly referred to as tacit knowledge, when he asserted “we can know more than we can tell.” Donald’s intuition, for which I emphatically agree, believes tacit knowing accounts for well over 90% of what we, and the people we study, know.
You must actually do it in order to discover it, then you must observe yourself, reflect on what you observe, and construct a description of what you do in order to come out with a statement of what you know.
As a researcher, this is what should be under investigation. What are people doing well when they struggling to explain what they do?
I, now, believe this is where nearly all knowledge to build better software lies.
Sometimes we’re surprised when the tacit knowledge we rely on to do our jobs doesn’t work. In those situations we improvise. We’re, to the best of our abilities, making sense of what we’re experiencing and responding with experiments. Experimenting in ways where we believe failure of the experiment will not lead to failure of the work itself. Success of the experiment will not lead to success of the work, but give us clues.
We have a capacity, which I call reflection in action. It is the ability to think about what we are doing while doing it. It is the ability to turn thought both on the doing and the thing before us. It is something we can do with or without words.
This is getting close to what I experience while designing interfaces, interactions, and (visible) architectures of a software system. A folding of expected behavior across a series of interfaces while continually critiquing its fitness to purpose. Where small changes consistently and unpredictably cascade across a series of interfaces.
Sometimes this process can be frustrating when it interferes with my team’s plan. Other times it can feel like play. This is likely one of the biggest reasons why I enjoy my job — I get to play. I’m getting chances to safely practice applying different approaches to see what matches my judgement, and the collective judgement of my team, to the situation.
All practice, I would argue, is design-like. Indeterminate zones of activity — uncertainty and uniqueness and conflict where you cannot apply the rules, or treat problems as examples of a pre-existing theory. This design-like activity is exactly what you want to learn.
I couldn’t agree more!
Much like an engineer exploring the technical implications and declaring something to be feasible — that it can be built. A designer needs to “practice” inside and around the problem to understand if it can be solved at all.
A designer frames the problem, conducts a web of moves, discovers consequences and implications to see whether he has set a problem he can solve.
The ways we intend to change an environment will always have consequences. Many are unintended and interact with areas outside the intended scope of work. A few add value in ways we didn’t expect, others create more problems. We rarely can see these in advance, no matter the amount of research performed.
This design “practice” is a crucial component of problem setting and solving.
Without incorporating this design practice into problem definition we are skipping the most impactful and valuable contributions a designer can make. And likely externalizing all the negative consequences onto other teams and our users.
Designers — and everyone adjacent to designers — go watch this lecture. The last half is full of examples and illustrations for everything above.
Plus, he discusses the value of experience and how to use it in these indeterminate zones of practice. A topic for another day.
The goal shouldn’t be to have all design decisions be made by people with the word “designer” in their title. The goal is to make sure every design choice is made with rigor. With skin in the game.
The suggestion to “make simple interfaces” can be laughed away as overly simplistic. Or, it could be an idealized standard that’s impossible to achieve. It all depends on your interpretation.