Written by Failure may seem like a strange place to start when writing about service design, but if you know why something failed, you can improve it.
That could potentially be more insightful than a digital product that is released without knowing whether it has failed or not.
If you type ‘what is digital service design’ into Google, over four billion results come up. There are even master’s degrees that can be taken. At its core, digital service design is about creating a digital experience (usually by developing a product) that delivers a service that users need to help them do something. This could be an existing service that needs improvement, or a new offering to users.
Finding ways to improve service delivery design is vitally important, whether it’s for improving efficiency, effectiveness or reach. Many in the charity sector have started to cotton on to this, and it was centre of discussion at the recent CharityComms Heads of Digital meetup.
What action can charities take?
For charities to take a digital approach to service design, thinking needs to change – not just in digital teams, but across organisations. Having an open mind to new ideas, and a forum to generate and discuss them, is vitally important.
Teams that may traditionally have been siloed will create better solutions by coming together to solve problems. The culture needs to be that ‘no idea is a bad idea’ to encourage this, while also ensuring that the right people are in the right meetings and discussions at the right time. There is no point in creating a new digital product as a group of individuals who work with the users of that service, without involving the creative and technical teams to design and develop it as well and vice versa.
However, the most important people to involve are the users. This means involving them not only when the product is ready to test, but right at the start when you are working out what problems need solving. You should know what services are being delivered but unless you are speaking to the people who use those services, you will only ever have an internal, organisational view of what is happening.
It may seem hard to test with real users on small budgets, but there are a number of ways this can be made easier. Firstly, find them face-to-face at the physical point of service delivery. This might be your head office, but more likely to be in the local community. Second, invite them into sessions where you are sketching out solutions. Users will often find it easier to comment on something that doesn’t look totally finished, rather than a finalised, fully working product. Numerous prototyping tools exist now for rapidly getting something that looks like it is working, but actually is just a mock up. These include inVision, MarvelApp, and Invocable for voice skills. Finally, charities can help each other with cross-collaboration and sharing users – a bigger pool of people will provide a better test sample to get more accurate results. It may also be that charities can share insights with each other, as already happens at CharityComms events.
Why is failure important?
Bringing it back to the original question, how can failed prototypes help charities? If you develop a product or digital service based on preconceptions, release it to the real world and it isn’t used, a lot of time, effort and money has gone to waste. However, with an emphasis on prototyping, continual testing and being open to unforeseen and perhaps in many ways unpredictable results, the preconceptions are very likely to be proved wrong. A failed prototype, with measured reasons for why it failed, is much more useful than an untested real product. Those learnings can then go into making a better product that users will actually want to use.
To make changes to taking a digital approach to product development and service design, the following key points should always be kept in mind:
- Failure is OK, as long as you know why it failed and what needs to be improved, against measurable targets
- Flexibility is the best way to develop a product rather than having a totally fixed plan and specification at the start
- Always get users involved wherever possible and accept their comments may be different to preconceived ideas
- Creating a culture of openness and cross team collaboration is hard but doable
- Once released for real users to use, make sure you set measurable targets and are prepared to change and improve elements based on testing