A quick guide to mapping complex systems without going insane

As part of the work we are doing with mental health services in Lambeth, Irma and myself have been trying to visually represent the system in place to support people experiencing acute distress. And as often when it comes to mapping systems, whether it is a care pathway for users, a commissioning and funding process or the communication flows through different services, we found out that there is no single answer.

We spoke to a number of people who all hold their own view of how the system works, simply because they sit in different parts of the system. Say your role is to manage a department of a medical institution. The likelihood is you will have a very different understanding of what support services are available than if you were running a housing trust. And you will also use a very different language to describe the same things. And you will choose which information to share based on what you feel is valuable. And what you feel is valuable will depend on a variety of factors, from the effort it would take to mine that particular piece of data, to the degree of your mildly delusional belief in the success and failures of the service you run.

So, actually, even if everyone we talked to shared a common and agreed view of the system, we still would have ended up with diverging perspectives, simply because we are all humans.

And in our deepest (lowest) moment of confusion (despair), we wondered: “how come humans always seem to end up designing systems that are too big for them to comprehend?”

Due to the restricted timescale we had to work to, we didn’t expand on the philosophical considerations linked to this question, and quickly accepted that we had no choice but to try and make sense of a number of fragmented views, and that fragmentation in itself is an insight on the system.

We also accepted that systems are people, and that system maps are a product of the friction between objective truth (ha!) and subjective values. Knowing that there is no way to get an objective picture of a fragmented system is in fact quite liberating, because the question then becomes, not “what is the most accurate?” but “what is the most helpful for us to map?”

We are neither information designers nor data analysts, and we’ve learned a lot during the process. So here are 4 quick tips to make that daunting task a bit more pleasurable.

1. Know what the added value is

What are you mapping? Is it a pathway? Is it a landscape of all available services? Is it the relationships between different parts of the system? Is it the impact that different services are having against how much they cost? Having a key enquiry question will save you a few headaches. What do you not already know that would really bring clarity to the whole project? Also, try to define the perspective from which you will need to tell the story. Even if your objective is to have a cross-sector view of the system, you will have to make choices; understanding the whole system through the eyes of a commissioner will call for different visual representations than of a service user.

2. Have a clear functionality agenda

Asking yourself all these questions will only be useful if you know how you are going to use the map. Unless it is defined with the client as a deliverable of the project, a system map will only reach its full potential if it is treated as a living document that can inform the whole project, and not as an end in itself. Is it a visual aid aimed at supporting the design process internally? Is it an evolving template, which the team can use to synthetize what has been learned at the end of each phase? Is it a facilitation tool that will be used actively during workshops to engage participants on a particular issue? Is it a dynamic system that enables you to simulate changes inparameters and ask "what if?"

Setting early on what function the map will serve throughout the project should alleviate any anxieties about not having the time to draw an accurate enough picture.

3. Engage two different brains

One thing we have noticed is that system mapping requires two very different attitudes to gather and interpret data. The first one is questioning and the second one processing. The Questioner is not afraid of asking questions and challenging information, and spotting data gaps. The Processor is comfortable with not knowing the answer and leaves space for insights to emerge. In working together, the two approaches can balance each other well as long as each communicates their concerns and perspectives clearly to one another.

4. Make the best of interviews

Don’t assume that people at the top know everything. People at the top are great to engage as gate keepers, but frontline workers can have more direct knowledge of the services and processes that they are working in. This is particularly true for identifying challenges and spotting opportunities for change.

At the beginning of interviews it is useful to find out whether any efforts to map the system have been previously made. We found that often work in this area has been completed – but usually only from a limited perspective. It is our job to pull these strands together to form a more coherent and complete ‘systemic’ whole. But starting with what is there is prudent and makes for a good basis for asking questions and probing beneath the surface.

Finally, try to constantly get feedback. Take your drafts to interviews and get people to draw their view of the system with you, rather than describing it through words only. And if you are using the map during workshops, encourage people to challenge its structure and add on information to it.