The Beginners Guide to Service Design

The Beginners Guide to Service Design

As I look at how the user experience design domain has evolved over the past few years, one thing has become very clear to me: Screens aren’t that important anymore.

In the early days of UX, screens was a primary focus of design efforts, if not THE focus… because that was the key design deliverable everyone could agree upon. Stakeholders needed screens to review and approve, developers needed wireframes to code from, and users needed screens to interact with. Now, with technology such as voice and Internet of Things becoming more prevalent (and UI design conventions and standards maturing) a focus on screen design has been reduced.

What has become more pronounced and important is what I call “pure experience design”: The definition of what users do and how they engage with the technology that empowers their lives. The best example of this type of “pure” design is the approach named Service Design.

Here’s what I wrote a few years ago on Service Design:

The service design discipline is about organizing people, processes, and technology to make sure the interaction between a company and its customers are as efficient and “positive” as possible. It is more than process design, in that it takes a user-centric look at everyone involved in the equation – the customers and the employees who are engaging them.

Seeing the increased importance and value of this approach, I decided a quick “primer” on service design may be useful: Hence, this article. So here’s a beginners guide to service design:

Clearly detail and document a “mission statement”

Before you begin, make sure that the team is all in agreement around what the goals and vision of the net new experience is. In most instances it will be a refactoring or improvement of an existing process, but in some cases it may be a “blue sky/green field” project. Having this type of “mission statement” helps reduce ambiguity and put a “box” around the scope. For this primer let’s look at it from the perspective of improving an existing process.

A good example: “Streamline the experience of selecting and picking up a rental vehicle from our company for high-value customers, to ensure that these customers have an experience that rewards their loyalty.”

Document the existing process and technology

This involves user research and observation, as well as an analysis of all current process documentation and technology to understand all activities that take place. This informs the creation of service design blueprints (aka journey maps or experience maps).

Service design blueprints detail all process steps and this information is grouped in to two areas: “Front stage” or visible elements and activities, and “Back stage” or background activities and elements.

Carrying forward from our previous example/mission statement, you can look at all the interactions the customer has with the online system as well as support personnel at the car rental place as “front stage” and the back end databases and services (as well as the process of cleaning and refueling rental cars) as “back stage.”

Here are the key details that a Service design blueprint should contain:
• Personas (or roles)
• Tasks/Activities
• Supporting processes
• Supporting materials (or job aids)
• Technology used (Devices and applications)
• Activity time/Time on Task (when available)

Identify the pain-points and areas of improvement

Now that you have a holistic document that details all the “moving parts” that is in the experience, you can look at the service design blueprint from the perspective of opportunity areas and pain-points. What tasks are redundant or can be improved through technology? What interactions can be “plussed” to make them more effective and provide a better experience to the user? Finally, what infrastructure changes can be made to improve the experience from both the customer and the employee’s point of view?

As you can probably figure out, this is not about creating a new or different application but optimizing and improving the whole experience, for all involved. And by having this “big picture” perspective, you can start getting a good sense of the level of effort and potential cost of whatever change you come up with.

You may identify an idea such as a hand-written note to a customer with their 100th rental, and a gift. How would that be identified? How would the gift be delivered? Again, a good idea at this stage can be weighed against the total “bearing cost” of the idea, so that you can decide if it is worth the investment in tech and process changes. You can also “beta test” a new experience through user research and usability testing, to get a qualitative view of the change.

Document the change and scope

After validating the changes with stakeholders and users, you then revise the service design blueprint to reflect the new “desired” state. This new blueprint can then be an approval point with stakeholders and then will inform detailed requirements and documentation. And you have defined a “new baseline” for the experience – one that can be revisited and tuned as new technology comes to market months or years later.

Again, this is only a basic intro – for more details I recommend the great book This is Design Thinking. More details on this work is here: http://thisisservicedesignthinking.com