At West Midlands Combined Authority (WMCA), we provide over 80 services for public transport, for example, getting an older person’s free travel pass or planning a journey.
In 2018, we had the opportunity to create an agile delivery team to redesign some of our services. We adopted the Service Standard and embedded DDaT roles into our team. This includes the organisation’s first service designer – me!
In service design we work with several people from different backgrounds. Usually we call these people stakeholders. Some live and breathe service design, others find what we do confusing.
As service designers, we help people to explore the problem space by looking at end-to-end and front-to-back journeys.
Lou Downe, the former Head of Design at GDS, says “the biggest barrier to making good services is to get them to think of things as services in the first place”.
We need stakeholders to understand what we’re doing and why we need to do it.
What is the language gap?
Several parts of service design are technical. We get caught up in design jargon and find ourselves making complicated processes.
Sometimes, it’s the simplest words that create barriers to people understanding services.
For example, the word ‘user’. We find this term can be confusing to stakeholders. Their words for users are more emotive:
- Customers
- Citizens
- Residents
- Passengers
- Staff
At WMCA, we use these words interchangeably. It helps stakeholders to get on board as they understand what you mean.
We have a slide that explains this when we first engage with them before a discovery:
How we identified the gap
At the start of a recent project, we asked our stakeholders to answer a survey. The survey asked them whether they understood terms and ideas about agile, user-centred design and service design. For example:
- Discovery
- Show and tell
- User story
- Assumption
We ran the survey to understand our stakeholders. How much knowledge and experience do they have?
We also asked stakeholders to tick statements they agreed with, for example:
- I am not the user
- Failure can be a good outcome
- The problem might not always be as first thought
- The solution will never be completely finished
- Today’s user needs might not be tomorrow’s user needs
The results showed that we had a gap in understanding around:
- stakeholders believing they are ‘the’ user - they may be ‘a’ user
- the word ‘ceremony’
- continuous improvement – a project is ‘done’ and in the past
We also found that a quarter of stakeholders:
- would not be comfortable defending a digital project
- do not believe that failure is ever a good outcome
- do not understand a backlog and prioritised delivery approach to projects
How we bridged the gap
We were now mindful that although we have a strong team culture, we were only a small part of each stakeholders’ work life.
Simplifying our language and processes helps stakeholders to understand what we do. We call this onboarding stakeholders. It’s not dumbing down, it’s opening up.
We used our simple language to encourage people to get involved. We did this in three ways:
Opening up discovery
This is a great time to get people on board with your approach. It sets the scene for your process and starts to build trust. We use case studies to show how service design can make services better.
Once we have introduced the approach, we workshop to create:
- a vision for discovery - when do we know we’re done?
- a reframed problem statement - using GDS’ problem reframing tool
- the scope for our service - when do we know where to stop when we zoom out?
This workshop creates a common set of objectives that everyone has signed up to. We also learn our stakeholder’s language and team culture.
We invite everyone to get involved in research and contribute to the discovery.
Educating through show and tells
Our show and tells are open to anyone in our organisation and the public sector.
In our show and tells, we started to explain ourselves and processes more. Repeating definitions helps people to learn our approaches and terminology.
We built bridges with people across the organisation who can help when we start to redesign services in future.
Persuading through stakeholder newsletters
Every fortnight we update stakeholders about the project through an email. We send this every fortnight during the first week of our sprint.
This helps stakeholders to stay up to date with the project and summarises what we are up to. We did this to build trust.
We also showed real-world examples from colleagues across government by:
- showcasing posts from the Services in Government blog
- linking to other public sector show and tells
- platforming blogs from consultancies and thought leaders
We chose to send our newsletters at 1pm on a Friday afternoon. We hoped it would give stakeholders an interesting distraction as the weekend approached.
Has this been successful?
Since we adopted this approach, we have noticed there is more trust for our team to get on with busting through the backlog.
As we have redesigned more services, we have worked with several more departments. It has become easier to have user-centred conversations and we are trusted by senior stakeholders.
Being flexible to our stakeholder’s language and experience has resulted in better public services for our users. For us, that’s success.
What language barriers have you experienced when designing or transforming your service? How did you overcome them? What helped you communicate better with your stakeholders? Please share your experience in the comments.
3 comments
Comment by Rozanne Kidd posted on
thanks for sharing. a good insight and helpful questions to explore in my new role
Comment by Martin Price posted on
Great to hear, let me know how you get on 🙂
Comment by Dom Billington posted on
Thanks for sharing! We've also been mindful of using agile jargon when communicating with our stakeholders.
I'd be really interested to learn if and how you've applied this approach to naming your services and products?