Design bias in ‘service blueprints’
It is useful to reflect on unintended impacts or biases of the processes or tools we use as service and UCD professionals.
This post in response to observations of increased procedural use of ‘service blueprints’. Often becoming a required output regardless of if it is the right tool to use for the situation.
It is important to always reflect on the frameworks and tools we use to make sure they are the right ones for the job, this can prevent unintended design bias. Something I observed happening in complex, integrated and cyclic service design (See my post on cyclic and repeating services here).
In these types of services if ‘service blueprints’ are used incorrectly they can obscure the complexity and hide essential repeating use behaviours — due to the tool rather than our intention. This can create a positivity bias that skews towards the easy, simple and happy path design. In the long term, if this goes unidentified, it can result in risky gaps in design consideration and potential failures in service.
A ‘service blueprint’ is a great tool to clearly show linear (‘end-to-end’) service structure. They demonstrate depth (how things happen) within a ‘singular’ path. But… as with any tool we need to make sure we are using it the right way for the right job to get outcomes we expect.
If we work on something more networked or cyclic is it still the right method of visualising?
Questions to ask
How are you going to use this tool? What is the stage and type of problem you are solving?
Is the service linear, cyclic or repeating? If so how often is it used by people?
How integrated and networked is it? How many other organisations are involved in concluding?
Does the way we have presented our service design as a ‘map’ or diagram imply a realistic level of simplicity and certainty? Are we hiding or obscuring anything important by showing it in this way?
How might this be misinterpreted in any way? Is there anything we should do to ensure its clearer?
Run through these and ask yourself if it feels like the right tool. Doe you need to adapt what you have done to clarify any gaps or hidden complexity? Are there other methods that might serve this problem better?
A recommendation
In previous work, I have often used user-centred service system maps to explain the service. I have used these as artefacts, rather than instructions.
I have found this approach useful in complex connected physical to digital services, especially in research phases.
It can give a better sense of the scale of knowns, unknowns and complexity in cyclic or complex service design. Rather than not showing these things where they don’t fit into a blue print structure we intentionally expose them.
