Service design by town planning

Ross Breadmore
4 min readJan 2, 2018

--

Welcome 2 Pasville

In service design we talk a lot about blueprinting — large collaborative documents that are great for flushing out detail, aligning stakeholders and identifying areas for innovation. What blueprints are not great at is capturing huge and diverse areas of service, as they either get too complicated to be understood, or too high-level to be useful.

This was a challenge facing me last year while I was service design lead on a large transformation programme within the bank. We had 14 separate service transformations happening under one banner, all interlinked in a number of ways. From a bank perspective each was distinct with a product owner, feature teams and a huge amount of complexity, but from a customer perspective they simply made our overall service better.

I needed a way for teams to be able to discuss and connect different elements, and also something that helped those outside of the programme quickly understood how their particular part of the world connected with ours. After melting my own brain with huge blueprints and byzantine spreadsheets, I grabbed a large bit of paper, a few colleagues and a book that I’d been obsessing over for a few weeks. We started sketching tube maps but this became too complicated as we fixated on making the connections work above all else.

What if we made a town in which each element of the service is a building?

Once we had the town idea, the whole process switched from being laborious to being fun and creative, and most importantly it became a conversation about what each service meant for a customer. Some buildings were obvious, while others took long debate or required other stakeholders.

Before long we our town started shaping up. Our buildings all had meaning and they started to make sense collectively. We had messy whiteboard sketches but nothing we could effectively communicate to others in the team. As a massive eboy fan I suggested using their isometric pixel style to bring the town to life, so spent a few early morning and late nights experimenting with it.

From a process point-of-view it was relatively simple and not too different from constructing a blueprint or other design artefact; once I had the basic shapes created there was a lot of copy-and-paste. What was different was the level of thinking it required about the specifics of each service, and the discussion created when I started sharing parts of the town with people in the team. Displaying a service as a building forced colleagues out of their bank perspective and got them thinking as customers.

Once complete, I had the whole thing printed super big and stuck it up in the office. Some found it fascinating and wanted to discuss, often to build on the town or suggest specific additions/improvements. There were some great suggestions about what other layers could be added, such as subway systems denoting technical connections, or weather systems to denote the current health of a particular service. And there was also some indifference — for many the format was too distracting and/or the value not clear.

Learnings

The town plan is something that I want to do more of as it helped myself and others step away from the detail and think differently about the work. It created debate, healthy disagreement and a lot of energy. However it was also divisive; some didn’t see the value or worse saw it as an indulgent exercise. To help counter this, when doing it next time I’ll make sure I:

  • Make the early ideation/sketching as open as possible.
  • Make the format more easily editable by the whole team (creating the whole thing in Lego was one idea but hugely expensive).
  • Make the thing more usable by a wider set of stakeholders — having powerpoint-friendly parts, worksheets and other pick-up-and-play elements would definitely help.

Any feedback welcomed.

--

--

Ross Breadmore
Ross Breadmore

Written by Ross Breadmore

Mum asked for a baby, dad asked for a transformer - I was the compromise. Design director at JP Morgan Chase.

Responses (1)