Service Design: Pushing Us Beyond the Familiar

Thanks to Marco Dini for the Italian translation to this article.

On this day, everything was different. Well, not everything. In fact, almost nothing. But almost nothing can seem incredibly dramatic, especially when you’re a trained observer.

The day before, our user had no trouble with the software application. While we were watching, he used it for hours exactly as the developers had intended.

Here we were, replicating all the conditions from the previous day, yet the way he used the software was completely different. His behavior had, literally, changed overnight.

Our study participant was the owner of an auto repair shop that specializes in mufflers, brakes, batteries, and tires. The application he was using was the customer tracking software, which followed each customer through their visit, tracked his shop’s inventory, and estimated and invoiced every customer work order. It practically handled everything.

Baseline: Friday

The day before had been a Friday. For this shop, Fridays are like most weekdays. Customers come into the store at a regular pace. There’s often a small rush first thing in the morning, and most of those customers have appointments and are already in the system.

On that Friday, we watched the shop owner process new customers. He’d get their name, the make, model, and year of their car, and the symptoms of their problem. He’d carefully and deliberately enter the proper information into the system, which in return, provided a proper estimate of the work.

Most of the time, this estimate turns out to be what the work actually cost, a fact the owner was proud of. Even more frequently, the estimate was lower than his direct competitor, whose shop was on the opposite corner. Another fact that made the owner proud.

The shop owner wasn’t a particularly fast typist. But on this Friday, he didn’t need to be. There were never more than two customers in the shop. He could enter all the data with his two index fingers, just like he usually did.

In between customers, he showed us how he loved the data the system tracked. He could tell that there were seasonal patterns to the types of repairs customers needed. Mufflers came in the spring, tires came in the fall, batteries in the winter. He could predict his inventory and make sure he had everything.

This application made his life easier, he proudly told us. It should. It cost a lot. (He told us that too.)

Chaos: Saturday

When we showed up on Saturday, there was already a line in the parking lot. These folks were new customers, coming to get an estimate on new work.

That’s when the application failed him. Instead of the shop owner poking the data into the application, he’d take a blank from and fill it out by hand. And instead of getting the information the application needed, he’d jot down the bare minimum from each customer.

Within 20 minutes, the waiting room was filled with new customers, all looking for an estimate. To move as fast as he could, the shop owner had to abandon his much loved application. If he didn’t help these folks, they’d go across the street and do business there. He couldn’t afford that and wasn’t letting a piece of software get in his way.

On Saturday, the software application he had praised just the day before was now his enemy. It was preventing him from getting his job done. He was inventing workarounds to bypass it.

Stumbling into Service Design

Unbeknownst to us, we had stumbled into a service design problem. Between Friday and Saturday, the application hadn’t changed. The user was the same user. What had changed was the context of use. Suddenly, something that was previously helpful was now an impediment to the business.

Because all this was more than 20 years ago, we had, at the time, never heard of service design. (In those days, we never used the term “user experience” either. That took a decade to catch on.) Because our work in those days focused on the design of software applications, that’s where we focused our energy.

Yet we couldn’t ignore this bigger picture thing happening to our user. And we didn’t know what to do about it.

Today, we’d know what to do about it. What we’d seen was a classic service design problem, and we now have oodles of techniques and tricks to find great solutions.

Now, many user experience professionals accidentally find themselves working in service design. They stumble into it, just the way we did more than two decades ago.

Service Design Is an Extension of Digital UX Design

Most of today’s user experience work is done on some sort of digital device. It involves an application or web site. Solutions involve moving bits around on a display.

However, that isn’t the “total experience” a user has. Our shop owner didn’t only type data into a computer and produce reports. For him, the digital experience was only a piece of a total customer service experience.

If we’re going to truly create better user experiences, we need to know how to create better non-digital user experiences. We need tools and techniques for doing that, just like the ones we have mastered for our digital user experiences.

Service Design Pushes Us Beyond the Familiar

In digital user experience design, we think about a lot of things. We conduct user research. We work on the visual design, the interaction design, and the information architecture. We focus on the written copy and put together a content strategy to manage it.

In service design, all those things still exist. We still need to learn about who is involved in the service scenario, understanding what their goals are and how we’ll tell what success looks like. We need to ensure the experience looks good, feels right, and has everything the service participants need. And we need a process that gets the right information into the right hands at the right moment.

Think of an online chat capability for an e-commerce site—a tool customers use to ask about product details.

In a conventional UX approach, we’d focus on the bits. What does the chat window look like? How are messages displayed? What’s the noise or vibration it makes when a new message comes in? All of this is designed. All of it is intentional on our part.

Service design extends this scenario. When we push beyond conventional UX into service design, we now want to think about the experience of what is said in that chat window. How will the customer indicate which product they’re interested in? What will the customer service rep say in return? Is it scripted? Is there a research tool for the rep?

These details of the conversation go beyond conventional UX work, but are the centerpiece of service design work. That shift changes everything. Deep down, it’s the same interaction: using the chat window to find out info about a product. But our scope of design has extended into the service.

Extending UX Practices

Let’s look at user research: Today, many organizations conduct usability tests as their primary user research activity. They put their users in front of their digital designs and watch what happens. From this, they learn what works and what doesn’t, giving them insight in how to make the design better.

In service design, user research is still about learning what works and what doesn’t. Teams practicing service design still glean insight on how to make the design better from their user research. User research goals in service design are familiar to anyone practicing conventional user experience work.

However, to achieve these goals, we must extend our user research practices. Usability tests won’t work, because we’re not watching someone interact with a screen. They’re interacting with others. The simulated laboratory of the usability test won’t tell us the difference between a Friday and a Saturday at the auto repair shop.

For that, we need to go into the field. We need to use a full toolkit of ethnographic techniques. We may want to employ a Day In The Life study, or mobile ethnography. We’ll look beyond just the customer and explore the experiences of all the participants, including stakeholders and ancillary service personnel, such as a wholesale product buyer.

User research isn’t the only aspect of digital UX practice that we need to change when we start doing service design work. We need to look at how we prototype services, how we think about the information organized in the service delivery, how the service looks, and what behaviors we want each party to have when interacting in our designed experience.

It sounds like a lot. It is. But it’s not difficult to master. First, we learn the terminology and tools. Then, we practice them. With enough practice, it will feel natural.

Service Design is Unavoidable Today

Just like 20 years ago when our team visited the auto repair shop, teams today will get pulled into non-digital service design. It’s unavoidable.

As digital technology becomes more integrated into our overall experiences, we’ll need to start thinking about how our customers and employees flow from one area to another. We’re no longer in a world when we can design for just a single isolated online interaction, not thinking about what happened before that interaction or what happens after. And, we’re no longer in a world where we believe that every before-interaction and every after-interaction only happened online.

We’re now in a world where digital and non-digital are merging. And we need to be prepared to design in that overall experience.

Service design is no longer a “nice-to-know, someday we might do this” kind of thing. It’s become a “today, this is how we compete and produce the best damn experience for our customer” kind of thing.

As UX professionals, we need the skills and techniques of service design in our toolkit. Acquiring them will push us beyond what’s familiar to us. And that’s a good thing.