Playground: posters, illustrations, games and notes

I used to think that the first step in design was to define the problem.

Find out what is wrong.
Understand the user.
Write a problem statement.
Then start looking for solutions.

The more I study systems design, the less convinced I am that this works for every kind of problem.

Some problems don't have a clear beginning. They don't have a single cause. And they certainly don't have a moment where someone can say, “Yes, this is the correct solution.”

These are what Rittel and Webber describe as wicked problems: problems where defining the problem is itself part of the challenge, where different stakeholders can have different ideas of what a good solution looks like, and where every intervention can create consequences elsewhere in the system.

For these problems, I have started thinking about design differently.

I don't begin by asking:

How do I solve this?

I begin by asking:

What is actually happening here?

Start by watching

The first thing I want to do is slow down.

Before trying to improve something, I want to see how it behaves.

This is something I took away strongly from Donella Meadows' Dancing with Systems. Her advice is to first “get the beat”: watch how the system behaves, understand its history, and look at what is actually happening instead of immediately fitting the situation into our favourite explanation.

I find this particularly relevant to design because we are trained to look for problems.

We see friction and want to remove it.
We see inefficiency and want to optimise it.
We see a bad experience and want to redesign it.

But sometimes what looks like friction is actually a symptom of something deeper.

So before asking “How can I make this better?”, I try to ask:

“Why does this work this way?”

Then I try to see the whole system

Once I start understanding the situation, I try to put everything on the table.

I map them.

Not because I believe a map can perfectly represent a system. It can't.

I map because visualising the mess helps me think about the mess.

This is one of the ideas behind Gigamapping in Systems Oriented Design. The Gigamap is described not simply as something to present to others, but as a process tool for visual thinking, something that helps designers work with large amounts of information, connect seemingly disconnected elements and move between the wider system and its smaller details.

The map is therefore not the answer.

It is a way of asking better questions.

I might notice that two actors who seemed unrelated actually depend on each other.

I might notice that information disappears between two stages.

I might notice that a decision made at the organisational level creates a problem for someone at the frontline.

The more I map, the less the problem looks like a single problem.

It starts looking like a web of relationships.

I try to look at relationships, not just things

This has probably been one of the biggest shifts in my thinking.

As designers, we naturally focus on things.

But systems are not simply collections of things.

They are made up of relationships between things.

Systems Oriented Design talks about developing the ability to uncover and work with these interconnections, looking at flows, bottlenecks and dependencies rather than only the individual entities.

That changes the questions I ask.

The problem moves from being located inside a person or product to being located between things.

And that is often where the interesting design opportunities are.

I don't trust my first problem statement

There is a strange thing that happens when you write a problem statement.

I think this is dangerous.

Rittel and Webber argue that with wicked problems, understanding the problem and developing a solution are intertwined. There is no simple point where you completely understand the problem and can then move on to solving it.

So I try to treat my problem statement as temporary.

It is a hypothesis.

Something I am currently believing based on what I know.

And therefore something I should be willing to change.

I keep asking:

• Is this actually the problem?
• Whose problem is it?
• What happens before it?
• What happens after it?
• Who benefits from the way the system currently works?
• Who carries the burden?

And sometimes the answer changes the entire direction of the project.

I don't see that as a failure of the research.

I see it as the research doing its job.

Find a place to zoom in

Once the system starts becoming clearer, I don't try to solve everything.

That would be impossible.

Instead, I look for places worth investigating more deeply.

This is where the ZIP analysis from Systems Oriented Design becomes useful.

ZIP identifies three kinds of points:

Z

Zoom: somewhere that needs more depth or resolution.

P

Problem / Potential: something problematic or something that could offer an opportunity.

I

Intervention / Idea / Innovation: a possible place for action.

I like this because it gives me permission to say:

“I don't know what the answer is yet, but something important is happening here.”

That is a much more honest position than forcing a solution too early.

The intervention is part of the system

Eventually, of course, I have to act.

But this is where designing for a wicked problem becomes uncomfortable.

Because once I intervene, I become part of the system.

My design changes something.

And that change can create another change somewhere else.

Rittel and Webber point out that wicked-problem solutions can have consequences that continue over time, making their full effects difficult to anticipate.

So I don't only ask whether an intervention solves the immediate problem.

I ask:

• What does this intervention change?
• Who does it help?
• Who might it burden?
• What new behaviour does it create?
• What dependency does it introduce?
• What happens elsewhere because I changed something here?

Sometimes the opportunity isn't a new product at all.

It might be a new relationship.
A better flow of information.
A change in responsibility.
A different workflow.
A new feedback mechanism.

Or simply connecting two parts of the system that currently operate in isolation.

Prototype to learn, not just to validate

This also changes the way I think about prototyping.

I don't want every prototype to be an attempt to prove that I am right.

Sometimes I want the prototype to prove that I am wrong.

I make something.
I put it into the situation.
I observe what happens.
And then I learn.

This fits closely with Systems Oriented Design's idea that complex issues cannot be fully understood from a single perspective. Instead, designers can intervene, observe how the system reacts and continue iterating from what they learn.

The process becomes less like:

ResearchProblemSolutionValidation

and more like:

ObserveMapQuestionInterveneLearnReframe

Then repeat.

I have to accept that I won't understand everything

This might be the hardest part.

When I work on a complex problem, there is always more to know.

Another stakeholder.
Another dependency.
Another historical reason.
Another unintended consequence.
Another perspective I haven't considered.

And at some point, I have to stop researching and make a decision.

Rittel and Webber describe this lack of a clear stopping rule as one of the characteristics of wicked problems. There is always the possibility that more investigation could reveal something else.

So the goal can't be complete understanding.

Instead, I need enough understanding to make a responsible intervention.

That distinction matters.

Maybe we don't solve wicked problems

This is where Donella Meadows' idea of “dancing with systems” makes sense to me.

Systems cannot simply be controlled. We can observe them, intervene, listen to their responses and adapt.

And perhaps that is a better metaphor for system design than “problem solving.”

You don't fight the system.
You don't assume you can completely predict it.
You don't pretend your first model is the truth.

You pay attention.
You move.
You respond.
You learn.
And you move again.

So, when I approach a wicked problem today, my process is roughly:

WatchMapConnectQuestionZoomReframeInterveneObserveLearn

It isn't linear.

Sometimes I go back three steps.
Sometimes one conversation completely changes the map.
Sometimes the intervention reveals a problem I didn't even know existed.

And that's okay.

Because I am beginning to see that the mess isn't something I need to eliminate before I can design.

The mess is the thing I need to design with.

Maybe that is what makes system design different.

I am not simply designing a better object inside a system.

I am asking:

What relationship, behaviour, flow or condition could change the system for the better?

And then I try something.
I watch what happens.
And I learn.

Maybe the goal isn't to solve the wicked problem.
Maybe the goal is to become better at dancing with it.