Service design advent calendar, St. Nicholas day
In the spirit of giving and sharing of my name sake and the season that is upon us, there are just so many things I’d love to share. Then again I often assume people know so much already, service designers tend to be quite broad and good at flexing. Though one has to be careful about assuming.
As part of my role as guild lead for a merry bunch of some 35 service designers at a Very Large Bank, I also evangelize to the rest of the bank about Useful Stuff. One quite useful thing that somehow doesn’t seem to have made it into most people’s practical toolkit is Cynefin, conceived by Dave Snowden in 1989.
Image credits: A sketch, by Edwin Stoop of Sketching Maniacs, of the Cynefin framework, a decision-making tool used in management consultancy.
Cynefin is a conceptual framework to aid decision making and sense making, something we (should) do a lot of as an important part of service design I think. One of the key areas of usefulness for me is that people think they operate in different domains, and if you’re aware of the misalignment you can save yourself some frustration and help teams manoeuvre more productively. It also helps understand what kind of learning is most appropriate, and I worked with some of our agile coaches years ago to devise learning strategies based on all this.
There are five contexts or domains, which build on the strength of relationships between cause & effect.
In simple (which has been renamed obvious / clear by Snowden but I still prefer simple), there is clear cause & effect, we know Y will happen if we do X, and it is repeatable and reliable. You need to learn something, just read the hm-hm manual.
In complicated you need some analysis or expertise to apply judgement, like a lawyer or engineer. Learning is best done by listening to and asking others who can coach and guide you.
In complex contexts, like corporate culture or ecosystems, cause and effect are only understood in retrospect, you need to experiment rather than take a reductionist approach. Learning is done by test & learn, this is experiential on-the-job learning that no-one will teach you (like most of service design, you want to learn it- just do it).
As for chaos, things are unclear and confusing, you need to do things just to stay afloat, and try to transform your situation towards complexity. Learning is by little steps that gradually make some kind of sense.
Disorder is the darkness where we have no idea which of the domains apply, and different stakeholders may compete for their specific view on the world.
Back to my point on misalignment of perspectives, the classic case (in my humble experience) is where managers of large organisations insist on thinking they are in simple when in reality in a best case scenario they are in complex… and therefore apply the wrong methods to everything from change to learning to… long list and lots of waste go here. One of the overall intentions behind the model is to try to move towards the bottom right domain.
Snowden has also done some interesting subsequent work on liminal spaces, the fuzzy lines between the different domains, but more on that another day (or google is your friend).
This all also aligns neatly with Eddie Obeng’s model of project types (don’t you just love it when that happens), which often helps explain it quicker to people:
Paint by numbers (Simple); it’s clear what you need to do and how to do it, just get on with it.
Making a movie (Complicated); you know the tech, you know the crew you need, you have an idea of the process to get there, but it’s starting to require some skill and craft.
On a quest (Complex); you have a good idea (hopefully) of your mission, but you’re exploring in foreign territory and have to iterate your way back & forth.
Walking in a fog (Chaos); your project is operating in a VUCA (volatile, uncertain, complex & ambiguous) context, with scarce clarity on where you are or where you are going - keep communicating.
In more day-to-day design terms, that can help you organise your thoughts and doings to get on with stuff, I like to talk about Fix-Flex-Fluid.
As an example, I currently work in risk management (yes it’s ripe for service design and intellectually a marvellous challenge…) looking at services and what design patterns and clever technologies to apply in different mix & match combinations;
a fixed mostly automated straight-through-processing data based model without manual intervention;
a more flexible model with assisted analytics and providing quality near time information supporting employees to make better judgements;
or a fluid service ecosystem more about connecting the right people at the right time to have the right conversations.
You may ask yourself, which domain do you think you’re in? And what would your product owner or senior business sponsor answer to the same question…?
Have fun designing those services.
