Your service maps don't need to look the same

Having worked across many large organisations we’ve often encountered this question. Should there be a uniform style for our blueprints? Typically it’s a thing you see with new designers coming in. Or when people are thinking about design ops.

From experience. The reality is, it’s probably the least important thing you can worry about.

Rarely is the visual consistency or uniformity between maps and teams the thing that holds a map back.

Much of mapping holds its value in individuals and teams working out things and understanding. The question of whether that’s using the brand colours, shapes or icons doesn’t impact that learning. It’s nice to have.

Visual similarity can also blur and make things harder to focus on. If you have lots of things looking the same, the detail can be lost. Particularly if you’re confronted with multiple journeys at once.

Good maps and journeys find the right visual language for the thing they are trying to express. Or the model they’re exploring.

As such it’s important to find the colours, shapes and icons that help explain the immediate idea.

This isn’t to say you shouldn’t pay attention to the visual treatment of our maps. There are definitely times to think about your visual language.

For example you might want to align when showing your bit fitting inside a coherent whole or aligning so multiple teams can show how things fit together.

Similarly you want to lean on existing things so that you can:

  • Borrow phases and structures that are well understood
  • Empower and support teams to get on with mapping instead of visual treatments or debates about the visual style to take
  • Make it easier to communicate what you want to by borrowing what works elsewhere

So, no you shouldn’t force uniformity. But there are times when choosing patterns helps. Such as:

  • Where teams are showing the detail of “their bit” but want it to be coherent or easy to fit within master or higher level maps
  • Where language or phases are well understood and some consistency helps
  • To stop needless creativity on what are internal specs
  • To empower and support teams to get on with mapping instead of visual treatments
  • When you have varying levels of skills with the tools or techniques. Or having experience with tools that work differently
  • Where you or teams have tried something and it didn’t work and that’s worth sharing

But rather than force teams to fit within a style that may or may not actually help model something, try working on how to share and make being consistent easy.

To do that. Work on how often and early teams share their models and blueprints. And where and how easy it is to find and work from other people’s things.

At we’ve got a crude starter set of components and patterns as well as a treasure trove of things we’ve done before. Mostly it’s about visual treatments that helped communicate a certain thing or approaches to show user journeys, comments, issues or logic in a pathway that’s clear but not overwhelming.

Don’t force your teams to align visually. But do make it easier to do the right thing. And show what standards or approaches are expected.

Make it easy to start with tried and tested approaches. And get teams mapping and exploring things rather than focusing on unnecessary brand alignment.

And ultimately make it easy to share back what they’ve found and do. So others can learn from them. Be that access to their maps, a set of starter templates or a more comprehensive library of approaches.