Designing whole services part 4 - Taking Action
Published on
The fourth and final post from a series of service design talks at UK Governments Services Week.
Published on
The fourth and final post from a series of service design talks at UK Governments Services Week.
Published on
The first Government project I worked on was a licensing service, as part of the project, licence numbers were updated. That change stopped users from being able to log into a related service where they recorded their activity. In summary, our ‘service’ had broken someone else’s ‘service’.
I’ve seen loads of examples of similar issues over the years. Usually the result of only designing parts of services or single interactions within a service in isolation.
The solution? To design whole services as the end user would define them. To see the whole picture and to design and deliver a service that meets the needs of internal and external users, supporting them to achieve their desired outcome.
I have spoken at the last 4 Government Services Week events discussing my journey towards this goal. Each of the 4 talks started with this quote...
If your business was making chairs, you’d hire a furniture designer - government needs service designers to design the services it provides
It’s a good quote, and that’s why when I was head of design at the Department for the Environment, Food, and Rural Affairs (Defra) the first thing I did was try to hire a bunch of service designers.
That was the basis for the first talk A space for service design which was about defining the role of Service Designers in a way that helped to differentiate the profession from more established practices like Interaction Design, Content Design, User Research and Business Analysis.
The biggest thing I learned in that year was that hiring service designers and then putting them into existing teams and structures doesn't change the things we’re designing or building and it wont help us to do that either.
So the second talk Designing whole services was about stepping back a bit instead of trying to grow the service design team, the focus was on defining what we mean by a service, using that to define what service designers do, and then defining what type of projects or spaces service designers should work in.
That worked to an extent, and got me the support I needed to create new Principal Service Design roles to sit across whole services or portfolios within the Data, Digital, and Technology directorate (DDaT) .
However it was all based on theory, the third talk Is this Service Design? was about putting that theory into practice on some of Defra’s biggest and most complex services.
For me that year was about understanding the service I was working on as it currently existed, understanding who was using the services, and what they were trying to achieve, and then creating the right conditions for a whole service approach.
One of the biggest reflections from that year was that most of the work was about trying to incrementally improve existing services, products and processes.
This is valuable work, but can only ever go so far at some point we will need to take a fresh approach, change our ways of working and start to actually re-design or for the first time design those services and processes. I ended that talk by saying that when or if this happens is usually out of our control which looking back is quite a depressing reality.
That was the starting point for talk 4, taking control or taking action. If you have done the work to understand your users and to understand the whole service and workflows within the team, you probably have a body of evidence for change.
My first attempt at this was back in year two hiring Service Designers to sit across each portfolio area. Doing this, I thought would give oversight of the whole service and an ability to impact decision making, I was wrong.
In reality I was sitting inside a DDaT bubble with no real knowledge of the wider ecosystem we were part of.
To truly have oversight of the service a role would need to exist that cuts across multiple organisations or team structures, a service owner type role.
The second thing I tried was hiring a small team to work with the portfolio I was part of. My thinking was that we could take ownership of the user experience across the divides and influence outwards. The problem there was that the space was too big, with no clear way of defining boundaries. That small team struggled to have any impact or to be noticed at all. We were spread too thin and as a result achieved relatively little.
I would like to say that attempt three was more considered and in places it definitely was, but a large part of it was a chance meeting with a like minded person from another directorate in my portfolio area. By working on things collaboratively we were able to achieve much more and influence beyond our own reporting lines.
Our first step was to use the evidence we had collected to pitch a different way of working to senior leaders in our respective directorates. Having this senior level sponsorship gave our plans credibility and paved the way for getting support form wider teams. We each presented the same message independently to our directors, largely so we could craft the message in a way that would resonate best with that person.
Our presentations covered the following 4 areas:
The key part of the message was about being more efficient in how we were working and delivering better outcomes by changing what we delivered. We used data and evidence from the service to back up each point we made. We avoided catch all or common terms like ‘agile’ and ‘user experience’ instead focusing on things we could more easily ‘point to’ like cost of delivery, error or failure rates, and risk.
We started by framing the size of the problem, to create the need for urgent change.
The problems we articulated were…
These issues lead to:
One of the best pieces of advice I have been given is ‘come to me with solutions not problems’, so the second part of our presentation was how we thought we could solve these issues.
As part of that we wanted to set out that the commitment to deliver the 2025 strategy wouldn't change or be impacted. But that we needed to change how we went about delevering the strategy taking a user centred and iterative approach to make sure we achieved the desired outcomes.
This was important to try to remove the myth or assumption that because users don’t want to apply for permits for certificates we don't need to do user research. It’s a little bit like going back to basics and talking about user needs not user wants, but that is a message that still needs to be said. We also emphasised that working in this way would enable us to quickly surface things that might trip us up further down the line and reduce our spending on the wrong ideas or solutions.
We broke the solution down into 5 areas:
All 5 of these things can seem quite daunting or hard to implement, so we broke each one down into 3 stages:
We did this to make sure we would deliver value for investment and build trust in the short term, and to make sure we didn't get stuck in a loop of trying to tackle big or complex pieces of work.
As an example for creating a responsive delivery approach, moving to a model where we had outcome focussed teams empowered to own decision making was a long term aim to remove duplication of effort and competing delivery teams.
In the short term we could introduce feedback loops and then create smaller lighthouse teams to pilot working in this way whilst keeping existing team structures in the interim.
We started the section on next steps with the sentence ‘This needs to happen now!’ This part sounded quite threatening but the point was there is never a good time to make this kind of shift, we wanted to avoid being told to wait until after the next wave of regulations had been implemented or the next funding year.
We finished up with actions for the Directors we were presenting too to make sure we got buy in and approval to start straight away.
The things we asked for where:
The feedback was actually pretty positive, it was mostly, OK what team do you need and what work will you pick up? Which was both exciting and daunting in equal measure.
One thing that stood out from the response was the phrase “Don't be the cool kids in the corner”. Which was important because we didn’t want this to be seen as us off working away in a corner doing something different whilst everybody else gets on with the ‘real’ or ‘hard’ work.
To move things on we put together a quick 1-pager to explain the work or problem space we would pick up and how we would operate. We opted for a small enabling team, a list of senior sponsors, and 2 pilot Discovery teams. The enabling team would be responsible for protecting the Discovery team's time, dealing with any ‘Why are you doing this’ questions so the teams could get on with doing the work.
Our approach was to start small and scale as we built up maturity and trust.
Revisiting the ‘don’t be the cool kids in the corner’ comment we needed to pick a significant piece of work, something that was key to delivering the new legislation, but also one that we could realistically impact before the delivery deadline. We were looking for a nice mix of tactical and strategic so we could show results where things really mattered.
We chose our pilot project for a few reasons:
You can watch a video from one of our pilot teams Alpha phases for more detail on the work they did and how they went about it, Outputs over Process: Designing in Alpha.
For the enabling team the whole experience was quite a journey, and is by no means over but making these small changes has opened the door for transformative change.
The biggest change has been introducing multidisciplinary teams much earlier in the process shifting design and research away from testing a solution towards defining and solving problems.
Doing this has helped us to make more informed and more cost effective decisions, in places opting to change internal or operational processes instead of building or buying a new digital service.
It also helped us to reduce duplication of effort by focusing on outcomes instead of rival solutions.
By working together at the start, we can minimise duplication of effort further downstream
Firstly, it was hard work! Getting the leadership team on board was one thing, but there were so many other people to talk to and convince along the way. You also have to keep telling and re-telling the story’ we had to go through why we were doing this and the benefits to delivery multiple times with multiple teams and people.
Building trust with other parts of an organisation was also difficult, especially given we didn't have shared accountability or power when it came to decision making. Digital was still not seen as being responsible for delivering the policy intent which makes it difficult to be seen as a partner.
Another interesting area was budgets and finance, creating teams to work across boundaries is one thing, working out who pays for what, when and how is a whole different ball game.
On a positive note starting with small changes was a good way to keep people on the journey with us. A lot of the steps we took felt small or slow but if you aren’t familiar with service delivery, or don’t sit in a Digital team it can be a strange world and a big change. By making small changes and taking people along with us, we built trust and confidence over time which should enable us to tackle some of the harder stuff in future.
These are webmentions via the IndieWeb and webmention.io.