Design has, for a very long time, been in an identity crisis. The proliferation of job titles, its mixed history with art and artists, and the mystery that surrounds the non-linear, difficult-to-codify nature of the process means that we’ve all struggled to explain what we do to others; not just to someone from outside the industry, like my mum and dad, but to those within it.
Because of the difficulty associated with capturing what Design is, it feels safer to further abstract our explanations of our job until we’re left with phrases like, “Problem Solver”. Generic and understandable.
But, the problem with the label, problem solver, is that it makes obvious a bias that we’ve all been guilty of – a designer sees the world as a bunch of problems needing a solution instead of a complex world that’s simply difficult to understand and predict.
If there’s a problem, I’ll solve it
Stuff annoys me all the time. I hate the way I need to consult the user manual of my air-conditioner unit every time I need to re-program it because it makes no intuitive sense to me at all. I hate the stack of dishes in the company kitchen that sit right in front of the sign that says “Please put your dishes away”. I hate Instagram and Twitter for holding my attention against my will. I hate that the world is broken – climate change, war, genocide etc – the list is endless.
And so the optimistic capitalist within me says, “Great, so many problems, let’s turn them into opportunities!” And so we do, we whack a “How might we” in front each problem statement:
- How might we allow people to program the air conditioner easily?
- How might we ensure people to keep the company kitchen tidy?
- How might we get our attention back from Twitter and Instagram?
We follow this prescribed pattern and ‘ideate’ until we’ve reached the highest order of problems (the most complex ones): How might we fix climate change, stop war, prevent genocide?
Wait. Really?
Sure, the world is imperfect and, as we bumble our way through evolution, some problems will go away and others will take their place. There will, without a doubt, always be problems. Some will be simple ones and others will be more complex. Thank goodness we’ve got designers, nay, wait, Problem Solvers, to help us squash them as they emerge. Right?
The intent to solve vs the intent to intervene
If designers continue to inhabit the title of Problem Solver, what we end up with is creating an identity and culture with a default intent to solve – to identify the problem, hone it, invent solutions to it, and take action. And sure, most of the time, the problem goes away. But, inevitably, another (or more often than not, other(s)) comes along and replaces it. So, which problems do we choose to solve? Which ones can be solved?
This action-oriented mindset – taking action and changing something in our environment – in combination with biasing towards ‘simple’ problems gives us feelings of progress & achievement. It feels really good to change something. We’ve proactively applied our intellect, which manifests in, hang on a minute… candy crush? The air-fryer? This cup printer?
Because simple problems are easier to ‘solve’, we seem to be focussing more and more on the inane optimisations of already wealthy, comfortable lives instead of using our incredible deductive and inventive capacities for something more important. Or, worse, we try to apply formulaic processes and methods that are successful in solving simple problems to complex ones and that’s where we run into trouble. But, hold that thought for a moment, let’s discuss medicine.
How the health sector ‘solves’ problems
In health, we’ve already recognised and use a different method of ‘problem-solving’. In health, there are no solutions, only interventions. There is a culture of understanding that drugs and therapies for humans aren’t ‘solutions’. There is an understanding that what may fix one thing for someone might do more harm to the individual, someone else, or a whole community. Because of this, we’ve developed the clinical trials system – a rigorous (not perfect) method for understanding how a health ‘solution’ may impact one or more human lives.
Clinical trials have various stages, from non-human to human. From small scale to large scale. It tries its best to do things like double-blind testing to remove bias from the process so that the understanding of the intervention is as ‘true’ as it could be for any given time. Again, this isn’t a perfect system, some interventions cause the need for other interventions and so on, but it’s the ‘safest’ one we’ve got right now. It’s an acknowledgement of the perpetual tweaking and change that is baked into the culture of improving healthcare. It’s the sort of process that’s robust enough to deliver the world a vaccine in a pandemic and save millions of lives.
The language we use shapes the culture we create.
This sort of process or mindset doesn’t exist in software culture. But what if it did? What if software culture had the process of a clinical trial – one that measured the holistic impact it had on humans and non-humans, at different scales over time before it was released en masse. What if it wasn’t just focussed on user acquisition and company growth? What if the way we thought about problems wasn’t scoped by what the shareholders are looking for next quarter? And why don’t we see protesting in the streets when a software platform like Tik Tok goes viral – scaling to billions of users in just a few weeks, but we seem to have a problem with a vaccine? What if software culture started to think of things not as ‘solutions’ to problems, but interventions to them?
The intent to intervene, not solve
Providing a solution implies an end to something – once a solution exists, the problem doesn’t. Often, the list of problems we started with is so long that after one is solved we just pick a problem off the old list and start solving that next.
But, if we start to think of ourselves not as problem solvers, but ‘interveners’, a few things happen (well, they happen in me, anyway):
- I start to sound a bit annoying and arrogant, and less like a ‘hero’. What gives me, a ‘professional’ designer, the right to intervene in anyone’s life in the first place? Who asked for my crappy opinion or ‘hunch’ on something? How do I know how to intervene with tools or services in the lives of people I don’t understand? Changing one word helps me see more clearly and returns me to the human-to-human relationship that exists between designer and user; to intervene in anyone’s life, we must understand them and their community, deeply, and also receive their permission to mess about with that, don’t we?
- It provides a level of responsibility for the unintended consequences of our interventions. When we’re building and releasing tools and services, we are the ones who decided how and why to intervene in someone (or a population’s) life. In any system where humans are involved, we are working with complex adaptive problems, no matter how small the change. Health already understands this. Tweak a human’s environment in one way and, sure enough, humans will use that tool or service in ways no one could imagine. By acknowledging to ourselves that what we’re doing is ‘intervening’, not solving, we’re admitting to ourselves that there will always be an effect (positive and negative) caused by our intervention. Because of this, I’m likely to be a little more careful in how I propose that we intervene and to what extent. Perhaps we’d start to change the scale of how we release our interventions, catching any harm earlier rather than after we’ve changed the brains and neurology of millions of people?
- There is no “done”. While it might feel good to address a problem by intervening in a person’s life in some way, the very nature of intervention is that nothing is done – in fact, by intervening to solve one problem, history shows we’re just creating more and different ones. In some sick way, the ‘solution’ mindset is keeping our industry alive and growing. We’re creating problems, not reducing them, so we need more ‘problem solvers’ to help solve them, right? Another unintended consequence I suppose? Who benefits from this mindset, then?
Quite simply, by using intervention terminology over solution terminology, it keeps the mind open and the ears and eyes more aware of our actions; both short and long term. By recognising that what we’re doing is intervening, not solving, perhaps we’re more likely to adopt a listening-first culture, one that moves slower and fixes things; just like it is in the Health sector.
If we’re more aware of the systems and lives in which we’re trying to intervene (because let’s be clear, most of the time, no one asked us to do that except someone who sees a way to make a profit from a community), we may approach problems with more empathy, understanding, time and consideration for the lives which we impact.
If this all sounds a bit dramatic, let me illustrate the importance with a case study.
Case study: Mosquito nets in Africa to ‘solve’ malaria
A smart cookie wants to prevent death from mosquito-borne malaria in Africa. There’s a very cost-effective and easy solution to this – mosquito nets. And so, they are deployed to those who need it most. A truly simple life-saving device. Problem gone. Or is it? Because now people are using those nets for fishing. They are infused with insecticide and the holes are much smaller than regular fishing nets. This means not only are they poisoning their food supply, but they’re also destroying the ecosystem on which they depend by pulling in fish and biodiversity that ordinarily wouldn’t be caught by ‘regular’ fishing nets. They’re also being used for chicken coops, football goals, and wedding veils. The problem now is how to stop the problems we’ve created by setting out to solve a different one.
Could calling these nets an intervention changed these outcomes? Might we have thought a little more broadly about the consequences of giving such a versatile tool to a human? Might we have rolled it out differently – first at a smaller scale to learn, more quickly, about the positive and inevitable unintended consequences?
So, what’s Design for?
My instinct, when I hear the unintended consequences of the mosquito story, is to solve it. What if they did X instead? What if the process was more like Y? That could have easily been avoided if… and so on. It takes considerable effort for me to stop. And think. Yes, this is an obvious problem to solve, but I need to take more time to understand it. What’s the cause and effect here, in this community, for these people? How do systems of food security, biodiversity, health, and education intersect or overlap – that’s a lifetime’s work and the system will keep changing as soon as we begin to understand or interact with it.
The truth is, I, like many other designers I know, are chomping at the bit to change stuff. I also don’t know a single designer whose actively set out to do damage to anyone. All we’re trying to do is help, we say. But, in the big scheme of things, our lives are short. And because our lives are short, we haven’t got a lot of time to make the fulfilling impact we’d like to make. Because of this, we bias toward action over consideration, of solving rather than understanding. People pay us to solve. They don’t pay us to tell everyone to stop, re-consider, take a little longer, try something small and see. At the end of the day, we gotta eat just like everyone else and if company X won’t ‘solve this problem’, company Y probably will. Won’t they?
I often wonder if designers could work together toward something bigger; something more… intergenerational. What if I spent my time understanding a system, and shared that understanding with another? Set someone else up for success? What if we watched and documented, together, across generations, over a much longer time horizon? What if designers helped to create a human organisational memory – a way to visualise the world and its complexity – the interconnectedness of all things? How might I intervene in my own life and community so that we can nudge us, the problem solvers, in a different direction?
What’s next in Design?
Should we have a clinical trials-like process for software products and services? Software products are fast becoming the primary tools and utilities of our time. Safety features are required in cars and other physical tools and services that intervene in our lives at scale every day; maybe it should be the same with software?
The downside of course is that regulation and systemic change of any kind takes a really long time. And, it’s often opposed vehemently until there are enough deaths or enough destruction for governments or other regulatory bodies to take action. We don’t have that sort of time. We’re also not measuring the non-death impacts of thoughtless or unconsidered software (i.e. think mental health at a micro level, democracy at a macro one).
Perhaps the simpler thing to do is to change our culture, one small behaviour change at a time. If language does truly shape culture, then the “How might we fix, solve, remove, address…” style of question – that ‘absolute’ and ‘finite’ terminology we’ve become accustomed to using as provided by ‘thought leaders’ like Google Sprints and Lean Startup books all over – might be better phrased as, “How might we intervene in
The curious thing about “How might we intervene?” is that it provokes a simpler and more important question for any problem we’re staring down – “Should we intervene here at all?” We may just find that doing nothing, in many cases, is the best intervention, and this might free up some space in our brains to find what is likely – that there are more important fish to air-fry after all?