The joys of co-design

There was a time when design studios would present clients with three proposals. At least, that was how things worked in the studios where we worked when we were younger. A was the corporate one, B was simple and clean, C was a little wild, just to prove we could be daring too. The client would look at them, think for a bit and end up asking for a combination of all three. And so proposal D was born, also known as Frankenstein, which nobody really felt was theirs. Not even the client, in the end.

Naturally, it was their fault. They hadn't understood the project, didn't know what they wanted, had no appreciation of design. All rather convenient explanations, because they allowed us to carry on believing we'd done everything right.

We had, after all, grown up with a fairly heroic view of the profession. The designer who solves problems, who designs everything from a spoon to a city, who finds solutions where everyone else sees difficulties. Practically a saviour, just missing the cape. In this version of events, other people mainly turn up to approve the design. Or ruin it by asking for a bigger logo.

The trouble is, when a client asks for a bigger logo, perhaps they don't actually want a bigger logo. Perhaps they want the brand to be more visible, and making it bigger is the only solution they know. Instead of trying to understand the need, we would start arguing about the solution. And might well end up making the logo bigger, after spending half an hour explaining why we shouldn't.

Looking back, proposal D had less to do with the client's inability to choose than with our inability to build a shared understanding of the problem. We'd presented three answers before making sure we'd understood the question.

We all speak the same language. Sadly, no.

Over the years, we've started thinking of co-design primarily as a matter of relationships. There are methods, tools, workshops and, of course, Post-it notes, without which designing together apparently isn't possible any more. But then there are the people who are supposed to use them to understand one another. And that's where things get complicated.

Every working group is a small ecosystem. There are designers, developers, researchers, partners, clients and the people who will use whatever we're designing. Everyone sees the project from a different perspective, and there's no reason to assume we all share the same priorities. Some people take part out of passion, others out of professional responsibility, others because they have to. Sometimes we use the same words to mean different things; sometimes we spend hours arguing before discovering we were saying more or less the same thing. Much to everyone's delight.

The problem, then, isn't just finding a solution we can agree on. It's working out whether we're talking about the same problem.

In this context, the designer can become a kind of source of friction. Not because they need to create conflict, which generally manages perfectly well on its own, but because they can make differences visible that would otherwise remain unspoken. And try to turn them into something we can work on together, rather than another proposal D.

This also means accepting that criticism can come from anyone involved in the project, not just those with expertise in the particular subject. Preferably at the right moment. We've often been brought in as designers only at the end of a process, though. So we know how frustrating it is to realise something should have been thought through differently when it's already too late.

So we prefer to involve people from the beginning, even when it makes the discussions more complicated. Avoiding the conversation doesn't make misunderstandings disappear: it just means they arrive later, when they cost a lot more.

Of course, for someone to question an idea without the meeting falling apart, you need a little trust. Which is often built by doing fairly unspectacular things: not using a mistake to put a partner on the spot, not turning criticism into a contest over who's right, not confusing the value of a proposal with the worth of the person who made it.

That last one is particularly difficult. Especially when the person is us.

We understood each other. More or less.

The lovely thing is that, even when we finally decide to talk things through, we can still misunderstand the very tools we've chosen to help us understand each other.

While working on MAXXI AI, for example, we used user stories: little scripts describing people, situations and possible interactions with a system. For us, these were hypotheses to discuss, a way of exploring possibilities without immediately committing to building them.

We realised fairly quickly that not everyone interpreted them in the same way. What some saw as a provisional scenario, others took as a design decision that had already been made. Within minutes, we were debating the details of an interface nobody had yet decided to build.

We'd assumed we shared an understanding of the tool we were using to understand each other. Which is a fairly efficient way of not understanding each other at all.

It wasn't a question of good or bad intentions. Everyone was simply interpreting what they saw through their own expertise and responsibilities. The same document could be an experiment to one person and a promise to be kept to another.

Really, it wasn't so different from the old proposal D. There too, we'd thought we were all looking at the same thing, only to discover too late that everyone saw something different in it.

Taking things away is the hard part

When different people take part in a project, different ideas inevitably come with them. And this, in theory, is one of the great advantages of co-design.

In practice, every idea has someone attached to it.

During MAXXI AI we explored several possibilities, some of which looked particularly promising. To help visitors find their way around the museum, for example, we'd proposed a system based on beacons. MAXXI had warned us that a similar solution had already been tried without success. We thought that, several years on, it was worth another go. The first tests, however, weren't exactly thrilling: the complexity of the building would have required far more devices than we'd expected.

Meanwhile, other features kept coming up, from scanning artwork labels to using NFC. Interesting ideas, at least individually, which together risked making an application designed to simplify the museum experience increasingly complicated.

At some point we started taking things away rather than adding them. Not because the ideas were necessarily wrong, but because the project needed a direction, not a collection of good intentions.

And this is where co-design becomes particularly interesting, and occasionally irritating. Because listening to other people's ideas isn't enough: you also have to be willing to let go of your own.

That doesn't mean every opinion carries the same weight or every decision has to be unanimous. It means recognising that nobody, on their own, has all the information needed to work out what will work. Not even whoever had the idea first, however fond they may be of their original insight.

Perhaps this is what separates co-design from collecting suggestions: the conversation can actually change the project, even when we don't particularly like the change.

The joys, then

Put like this, co-design might sound like a sequence of meetings, misunderstandings, failed experiments and discarded ideas. And sometimes it is. Not exactly the sort of description you find in workshop brochures.

And yet this is precisely what interests us: the possibility that the project might change while we're trying to understand it together. That someone's question might challenge an assumption we'd taken for granted, or that an idea we were attached to might turn out to be less useful than we'd thought.

It doesn't happen automatically, and calling a process participatory doesn't make it so. Getting people around a table is relatively simple. Creating the conditions for them to disagree, change their minds and make decisions together is another job altogether.

After more than twenty years of work, we're not particularly sure we've figured out how to co-design. But we have learned to be a little more suspicious of our certainties, especially when they seem obvious, and to see misunderstandings not just as accidents to avoid, but also as signs of something we haven't understood yet.

Perhaps that's the difference from those three proposals all those years ago. It isn't about turning up to a meeting with three solutions and hoping someone picks the right one. It's about building enough trust and mutual understanding to question even the question we started with.

Preferably before we get to proposal D.