Service design is a fancy term in business for when no one knows how else to 'fix it'. I say this only half in jest. Don’t get me wrong — this is a wonderful way to achieve results and guidance on a project that is perhaps struggling or languishing. My issue with the term and the concept is how high-brow it seems to have become; from talking with and listening to experts in service design I’ve come to realize that with the right mindset and training, any intelligent person with a high enough level of emotional intelligence can be taught how to do this. Mainly, though, it takes time, patience, empathy, and active listening.
The big deliverable that everyone wants out of a service design engagement is an experience map or journey map, but this doesn’t need to be a five foot long, four-color poster. Smaller series of deliverables along the way, such as updated personas and persona mapping against user stories and cases will greatly aide your cause. When it comes time, after three, six, nine months or more, to deliver the five year roadmap, your logic is transparent and your suggestions are more easily accepted as the best solutions.
Sometimes, in order to deliver the best, most accurate suggestions possible, it is necessary to take 'extreme' measures in researching your users — you may just need to become one. This is what I call undercover service design — you literally become (or as close as possible, using prosthetics and intentional barriers as needed) one of your own users. For me, this has proved to be the most successful way to deliver the richest set of suggestions back to my client for their product or service. This does mean, in most cases, taking on a 'new job' for several weeks if not months to live the experience you are designing for.
The outcome-driven design map is a great example of a powerful deliverable that won't require undercover service design. This is a simple one-sheet that really doesn't need to be shown graphically at all, but it can be a powerful way to present a reframing of an existing product or service. Traditionally, and many teams maintain working like this, a product or service will have a business analyst who acts as the subject matter expert and that person crafts the use cases, which in turn feed the feature and this dev roadmaps. However, what if we were to simply reframe the scenarios as outcomes to be achieved? This slight reframing of the feature as a promise to the user and scenario as outcome to be achieved can be a powerful launching point for the whole team in determining and designing solutions.
The example above is for a new Uber feature - the driverless Uber ride. I've framed the feature as a promise to the customer and then shown the typical scenarios one might use here. But look at the outcome statements at the bottom - these are much more human, making it easier to solve, design, and delight than when the team is faced with a list of (sometimes unpleasant-sounding) scenarios. The additional benefits of beginning with outcomes instead of scenarios are solid and measurable. Starting with outcomes makes people focus on the things that create the benefits instead of focusing on the problem itself. Ideally, you can bring customers, as well as internal business, technology, and design teams physically into the same room to create the outcomes and prioritize them, as a group. Working this way allows bridges to organically grow between customer asks and what your team needs to design and deliver.
A service design engagement is definitely most easily achieved by 'non-pros' when designing for enterprise or internal partners rather than consumer or external individuals, but the idea that anyone can flex their empathy muscles to achieve a quality service design engagement is true — it just takes empathy and time.