Should I make a process map?

Probably not.

When you’re building a big, complicated digital service, or overhauling an existing one, it’s a natural impulse to build one big map explaining everything.

You might show when data flows and how it’s stored, what admin and user actions are possible at each step in the process, what back-end databases you need to connect up, and so on.

Process maps generally look like flowcharts. User journey maps tend to go forward in time.

A false sense of security

The problem is that the process map can create a false sense of security—it helps us pretend we know more than we actually do.

I think this is the same urge that leads people to create Gantt charts that profess a level of precision and accuracy that just just isn’t there. Even if we think we know something for sure when the chart is created, that may (and should!) change over time.

For a digital project, a Gantt chart like this should inspire one reaction: yikes!

People come to rely on the chart: rather than having conversations with the other people involved in delivering a service, they just consult the chart.

Some say there’s nothing wrong with this. It’s easy to mandate at the start of a project that “everyone must keep the chart up to date”. Many projects I’ve worked on have done just that.

But that attitude causes problems:

• People spend more time updating charts and spreadsheets than doing proper work
• Eventually, the chart might be so complicated that people will need training to understand it.
• Teams get lazy, and don’t bother talking to other teams.
• If teams are tied to a chart, it’s much harder for them to respond to change.
• When something inevitably does change, everyone complains that the chart wasn’t stuck to, rather than thinking about whether the change was a good thing.

All these things are basically the death of agile working.

Okay, what should I use instead?

People often want a “single source of truth” to help them navigate their way through a complicated project. Often, they want this to be a a process map.

Instead, consider making this a user journey map or a service blueprint.

User journey maps can be simple, complicated or in between, but all they really need to show is what the user does, and how they feel about it.

The key difference is that these visual aids focus on the end user’s experience. They don’t have to include “backstage” processes at all if you don’t want them to.

User-centred visual aids force your teams to tie everything back to user needs. Print them out big and put them on a wall. Better yet, make them yourselves out of paper and sticky notes.

Like GDS says, do the hard work to make it simple. It should be on us as digital people to do whatever leads to the best user experience, rather than becoming slaves to process.

Sometimes you really do need a process map

When it comes time to implement, and your service is complicated enough, you will at some point need to map out backstage processes in detail. That’s okay!

These maps and charts should be ephemeral, created for a particular point in time, by technical specialists for technical specialists. If people start talking about them as a “source of truth” or if stakeholders get interested in it as a way of “managing” change, you’ve probably come to rely on them too heavily.

The process map should be one of your tools, not the other way around.

Agree? Disagree? Let’s talk on Twitter.