Yeah, we know a great Experience Designer (XD) is essential. So let's just go ahead and make sure we all know how much benefit they can bring.

There's a big old world to Experience Design, so here we're focusing on Service Design, and what a great baseline a service blueprint can be for architecture, domain modeling, and event storming type activities.

Key takeaways

• If you're a technical leader, know the capabilities of your peers and where there's opportunity to bring their skills into play.
• Service blueprints are a great artifact in their own right, and only get better when used as a foundation for the technical processes.

What is a service blueprint?

You might have seen user journey maps, which will typically cover the front-end interactions to get from start to finish, sometimes talked about as 'user experience'. These are a super valuable starting point towards building the right thing by highlighting user actions.

Service design takes this deeper to look at who else is involved and how that experience happens. A great blueprint will have at least mapped out the user's actions, the frontstage interactions, backstage actions and support processes.

Backstage vs Backend, Frontstage vs Frontend

If you're coming to this as a pure engineer, there's a distinction to make on language. Service blueprints use the words backstage and frontstage. These don't map to back-end and frontend necessarily.

The distinction is the Actor involved. If you go to a fast food restaurant, your frontstage is an interaction with a person to order your food. The backstage is the staff member picking up your order and getting it done. Both sides might have their own frontend and backend systems to assist in the delivery of the service.

In a software system, the whole backstage might well be automated with no human interaction, but it's pulling away from that assumption where service design shines. You don't have to assume that a given process is best done in code, at least not at first, and it highlights the human interactions and opportunities to automate them and streamline those processes with a holistic view.

Head over to Nielsen Norman Group to read more about the definition of service design.

Informing the software

The blueprint starts us off with a less specific view of tech, which is a happy place to be. The human actions should be the starting point for asking 'what can, or should, we automate?'.

Kickstarting Ubiquitous Language

When we talk about Domain Driven Design, we care about aligning business language with domain language and forming a concrete, shared, ubiquitous language that helps us build software that more accurately reflects the behaviours we're aiming for with an automated solution.

The service blueprint has already kicked off this process for us. It's gotten people talking and the blueprint itself is going to contain some key concepts that will serve as ubiquitous language. Especially when this is something new, giving people time to sound it out in plain language, focus on the actions and behaviours needed to deliver it is a real boon.

Did we just event storm?

You might be thinking a service blueprint is event storming.

If the goal of event storming is to 'bring project stakeholders together (both developers and non-technical users) to explore complex business domains'[1], it's not all that far off. Event storming is its own process worth executing, but comes with a heavier technical weight underlying it.

Again the service blueprint serves a foundational function - that a blank event storming session can be a little challenging to get going and might feel a bit abstract plucking events out of thin air. The process of generating the blueprint has already revealed events, so you've got some starting points for free and it will have warmed people up to thinking and talking about what should happen.

Architecture

Picking out domains, subdomains, and bounded contexts is another useful outcome for a service blueprint.

You get a great overview of what can happen in the delivery of this new system you're working on. Seeing that end to end of who's involved in a given interaction gives a real feel for which parts of automation are isolated to one user type, which behaviours are shared or neighbour each other. So drawing those boundaries around parts of a system becomes much easier to reason about.

Challenging to do remotely

Service blueprints can end up... big. Especially on complex systems. This has proved a difficulty in a remote-first world. There's no shortage of infinite canvas tools, but how many of the people joining the call have big enough screens to take in enough of the diagram to be useful?

I've not arrived at a perfect solution to this personally, so curious to hear your techniques for delivering a great blueprint session remote first!

Wrap-up

Well, what do you think? Has this convinced you to try it out? The blueprint is really a fantastic artifact to have in its own right. It makes aligning stakeholders on what is being delivered that much easier. It's a handy reference to look back at for onboarding people too across any discipline.

Most of all give your nearest experience designer a call. They're always a greater ally than you might realise, when the technical becomes the hyperfocus and it gets a little too easy to slip into automate all the things mode, they can be there to pull back to the high level person-focused view.

References

List of references:

1. Lucidchart on event storming
2. Service Blueprints Definition
3. Customer / User Journey Maps