Selling service design to not just stakeholders
The team has to be on board too
Tuesday 17th July was the first day of the first Internation Design in Government conference held in London, in the lovely surroundings of Mary Ward House, West London.
It was a chance for service designers, user researchers, content people and other digital people across government and from around the world to come together and take part in workshops and hear talks from people from all corners of the globe.
The first of 3 sessions I attended was from Vimla Appadoo from FutureGov on the service design lifecycle, selling service design to senior stakeholders. It was a good insight in how to sell service design, but also refreshingly honest in that Vimla shared her 3 biggest mistakes. Which I, and probably many others, can hold our hands up to doing.
The reason I chose this session over the others, was two-fold. I wanted to get some ideas to do exactly what the title suggested but also to sell it to the team I work in.
Err... what now?
Yes, sell service design to my own team.
The organisation I work in, although nearly 11 years in existence has a bit of an internal identity crisis when it comes to ways of working. The last 12 months has seen a dramatic shift within some teams and the shift to more “agile” ways of working has been significant.
I put agile in quotes as its not agile in the methodological sense, teams have become quicker to adapt to change, tried and adopted different approaches and becoming more open to sharing what they are doing.
Within our team, our ways of working has seen us make use of wall space for a Kanban board, become more focused on delivering continuous improvement and data-driven change.
However, not everyone is on board with service design thinking and practices.
A quote from Madeline Albright perfectly frames how I feel we work sometimes.
We are taking 21st century challenges,
evaluating them with 20th century ideas
and responding with 19th century tools.
A horse in a field of llamas
Mistake #2 that Vim shared was about being the voice of change and getting people on board with a new way of working at the wrong time, or too quickly or even focusing on the wrong people.
When people you are working with see the change you are trying to make as a negative, or a threat, then you stand out like a horse in a field of llamas, a sore thumb if you will.
I think this is the one thing that hit home with me. I want to push forward a better way of building services and bring the skills into the team so we can prototype early, get things on walls, show people things, do user research and build what users need, not, as in the past, build what the organisation wants.
Its this challenge which honestly, drives me up the wall sometimes. A few people ‘get it’ (a few being 2 or 3 — count me in that!) some won’t take the time to understand or get involved or just say “oh it’s just another GDS thing from London — here we go, lets get the post-its and the sharpies out” or “why we bothering with this, why don’t we just build it” or “why am I here if you’ve already prototyped it”
There are a few old-school attitudes and thoughts to project delivery, and these approaches are the reason we have some poorly performing services, user dissatisfaction and information overload. It’s approaching these attitudes with a tried, tested and proven approach that I want to instil across the team and organisation.
But it’s hard. The resistance on more than once occasion has made me apply for other jobs, go to 2 interviews and write 1 resignation letter which sat on my desk for a week before I realised that actually, I should be trying to change things for the better, it’s the right thing to do and I don’t see anyone else stepping up to the plate.
Well, this is where I find Vim’s honesty and openness refreshing, quite frankly, don't focus your time and energy on the people who don’t want to listen, its not worth it. Instead focus on the people who want to listen, and that's what I need to do. They need to become my allies.
Allies help build momentum
I was thinking who my allies might be, the team I work in has a couple, but I think even then, this won’t prove out until we deliver something that goes through the service design process and shows that it delivers real benefits.
Within our organisation, there are again, a few people who have seen the benefits of prototyping, for example, we built a prototype with some content which we understood and thought the users would understand. Our first research session fell flat almost immediately as the user didn’t have a clue what we were asking of them.
This was a service which was built from business requirements, without the user’s input in the early stages. An obvious sign that this is the wrong approach.
We took a step back, and asked the user what terminology they would use and how they work, this led to us building a new, very different prototype. This immediately tested better and with a few design iterations from further feedback, went live.
I’ve digressed
I have started to appreciate that I need to focus my efforts on the right people and make sure that I don’t just ram service design down peoples throats. However, I won’t change being a driving force for service design, I’ll just take a different tack.
A current project has the scope to do this, there is some real benefit to what we are doing, but there is a lot of work to do on the people front, I just feel like I am always going to be the horse in a field of llamas.
