Why do my service design projects fail?
My least successful projects have 4 things in common.
Over the last 5 years I’ve worked on lots of different service design projects. Some of my projects have resulted in meaningful changes to an organisation, which have improved people’s experiences of using their services. But there have been plenty of projects that never became services that people actually use.
This is the first time I’ve stopped to analyse the failed attempts. This seems just as important as celebrating the successes. I want to build capability in organisations to improve services. I want all my future work to reach people. Lack of implementation is a service design industry wide issue. I’m not blaming these fails on anyone in particular. I’m reflecting on my work to look at how I can maximise chances of success in the future.
1. Lack of clarity on outcomes
When I left art school I worked on a young people’s alcohol awareness project for a large health organisation. We were trying to raise awareness of the dangers of drinking. The team wasn’t clear exactly what the client wanted to get out of the project. We spent a lot of time prototyping ways to target young people. Before I started, the rest of the team had made a newspaper on the issue with young people. Co-design from the start, with young people’s voices included. We prototyped and tested lots of ideas: alcohol free pub quizzes, targeting young people at freshers fairs, even on-the-street interventions at heavy drinking times.
But the intended outcome wasn’t clear, we didn’t define the effect we wanted to have on young people’s drinking. We didn’t decide how we would measure our success. As a result the client was unsure how the judge the work and the project was not continued past that prototyping stage.
Since then I’ve put more time and energy into understanding what success would look like for the project from the start.
2. No dedicated role to run the service when live
If you’re developing a new service, it’ll probably need a new role to run it when live. This isn’t such an issue when improving an existing service, which is already staffed. We often sell service design on the basis that it will make processes more efficient, and save money. But in the short-term, it’ll cost money.
The project that I’m working on now supports teams to better evaluate digital health products. We made the case to our finance team that it was going to save them money: the health system would end up with better evaluated digital health products and could decommission the ineffective ones. This was a little ambitious. Now we may need to convince that same finance team to spend money hiring an evaluation expert to train product teams in evaluation and run the service. Even digital services need upkeep, continuous improvement, and people working in the back-end processes.
In future, I’ll make it clear in those first conversations that although we can improve the user experience and reach more people through digital, we might have to spend money on a new role.
3. Death by committee
I’ve learned that it’s not fair to expect a working group, advisory board or steering group to be responsible for the implementation of a service. With 10 people in a room who have power and passion in an area, the service has a better chance of success. But who is responsible in the working group? Everyone and noone. I’ve had this issue on 3 projects, in 3 different organisations. I’ll tell you about 2.
One of the projects I worked on as a student, working in a team-of-one with a humanitarian organisation on their hospital handover process. When I finished the research and prototyping phases of the project, I left the ideas and report with a working group I had assembled on the topic. Everyone in the working group recognised that hospital handover was an issue. But it was hard to put a single person in charge of implementing the changes. In 6 months it was possible to design the user experience of better hospital handover, but hard to work with the necessary people to implement the change. Eventually we did implement some of the necessary changes, although it’s hard to say whether hospital handover has had a measurable improvement. The working group provided advice on implementation, rather than actually making the change.
Another project was around promoting best practice in drug treatment work. There is a working group of people responsible for implementing best practice in drug treatment. A member of this group reached out to another designer and I. Together we carried out user research with drug treatment workers. We used new concepts as provocations for addressing the issues. Then engagement from our advisory group member dropped off. As we were in the same organisation, this project didn’t have budget allocated to it. We’d written a brief and had meetings about it, but we didn’t have a formal agreement with them or the group about piloting the ideas further. Through this I’ve learned the importance of making it clear to one person that they are responsible for making decisions about the project, along with clear milestones.
On the flip-side I’ve worked with amazing individual service owners, who didn’t always have experience of service design or digital before we started. Here I’m defining the ‘service owner’ as a person who has decision making power over the service, not necessarily the person who runs the service. A service owner needs to be responsible for implementing changes to a service or running a new service. Service owners who want to improve a service they’re in charge of can be real advocates. I’ve found that projects work best when we have a clear service owner, and an advisory group that only provides advice. With an ‘advisory group’ rather than a ‘working group’ or ‘steering group’, we understand that their role is to give advice rather than implement change.
4. The stakes are too low
If you want to understand a government’s priorities, look at where they’re spending their money. A politician will claim that education is their main priority, when their defence budget is 10 times the spending on schools. The same is true in organisations looking to improve their services or design new ones. As a freelancer I joined a small team, which included 2 experts, who were working for an organisation who wanted to improve outbreak reporting. During disease outbreak (like Ebola) doctors in the region Whatsapp each other information. That information gets lost in the chat, epidemiologists can’t analyse it or use it to contain the outbreak. A life and death problem. But the budget wasn’t big enough to properly test prototypes in the field. This small budget meant that if the project was unsuccessful, it wouldn’t matter too much to the organisation.
Next time I’ll ask more questions about how much this problem was costing the organisation, and how much value they placed on fixing it. We didn’t get past the prototyping stage and real-time outbreak reporting is still an issue.
Cultivating the conditions needed to improve services
At this stage analysing failure feels just as important as celebrating success, so in this blog post I’ve highlighted the lessons I’ve learned. They have led me to conclude that:
1. Clear outcomes should be defined from the beginning.
2. If the service is completely new, it needs a new role to run it. If it’s an existing service being improved, the roles of the current staff may evolve.
3. Advisory groups should be used purely for advice.
4. The project budget should reflect the task in hand.
These things feel obvious. It’s easy to carry out research to understand what people need, prototype and test new ideas, and develop a convincing-looking service. It’s difficult to navigate organisational politics, find funding and new roles to run new services. That stuff at the end I’d call ‘implementation’. I want to get the second bit right, and spend a lot of time honing it. This messy implementation bit is a team effort, and I want to better understand who should be in that team, and what kinds of support they may need.
