Is your product affected by service design points? Here is tips on how to discover out
this article was written by Tiffany Hale and originally published on Built-in.
Failure is more than a rite of passage at work in technology – it is a guarantee. However, the bug designers and developers they are familiar with typically fall into the leisurely iteration cycle of being “OK” to fail. Do users hate your proposed process flow? (No big deal, it was just a wireframe!) But the stakes are a little different when products are shipping, code is live, and things don’t go as expected.
When the straightforward application of Design Thinking techniques produces unexpected or undesirable results, it may be time to ask yourself: Are you designing for a product or service?
What is service design anyway?
To really understand how to answer this, we need to take a closer look at the relationship between product design and service design. According to the Interaction Design Foundation, product design is the process of combining user needs with business goals to create “consistently successful products”. When we think of such products, we often look at extremely successful examples like the iPhone.
However, technology doesn’t have to be at the heart of successful product design. The patent for the product we know as a paper clip was filed in 1899, and we can argue that over a century later it is still successfully serving people’s needs.
Service design is different from product design, but often includes it. The Nielsen Norman Group describes service design as “the planning and organization of a company’s resources (people, props and processes) to (1) improve the employee’s experience directly and (2) indirectly improve the customer’s experience.”
An example of what service design looks like is buying a cup of coffee for mobile collection. The mobile ordering app is often what we consider product design – from the in-app payment experience to the little ping on your phone when your drink is ready to be picked up, to the digital receipt you flash at the barista to pick it up let up your order. All of this falls into the area of user experience design.
Where does service design come from? The service design applies to the point-of-sale (POS) system that alerts baristas to new orders. It is the prep counter layout where the barista will make your drink. It’s the markings on the floor that help you understand where to go for a mobile pickup, and the stanchions that separate you from the walk-in customers, and even the little warning that prompts you to share your experience after the Verifying purchase has picked up your order. The success of service design and product design in harmony leads to satisfaction with that first sip of coffee.
However, discord between the two can create confusing trends in user behavior that can indicate that you may need to focus more on designing the service than directly designing the product.
Red flags on the way to retention
When it comes to identifying conflicts between a product design and the larger requirements of a service design, data can provide important clues as to an underlying problem. Bright reviews of a product or application associated with high churn can indicate major problems with the experience.
How would that affect coffee intake in our example?
Let’s imagine, instead of an optimized, beautiful checkout system that notifies the baristas of new orders, there is an antiquated printed receipt system that silently spits out a stream of new orders. The customer experience would change drastically. The customer would receive a notification stating that the order is ready based on the estimated completion dates. However, baristas often get caught up in the hustle and bustle of in-store orders and mobile orders fall by the wayside.
The customer now has to wait a few minutes for their drink, which sometimes doubles the expected pick-up time. While the app itself (the product) has a steady stream of new users and great reviews in the app stores for its clean user interface, customers would still buy from a competitor and give up using the app.
To remedy this experience, user journey mapping is a must. Journey mapping in product design can focus on a single part of the customer experience. Journey mapping from a service design perspective extends this focus to all touchpoints that enable the customer experience. This holistic view often exposes frustrations that are way beyond the control of an app user.
It is important to remember that even if a process inhibitor is not reported directly by the customer, it will affect their experience, perception, and use of an individual product with which they interact.
In our coffee pickup example, users might complain of long wait times. However, the root cause of the problem lies in insufficient notification and tracking at the barista’s POS. Improvements to the POS system that customers never see would lead to downstream improvements in customer satisfaction and repeated use of the app as drinks are delivered on time. Customers don’t need to fully understand the problem to take advantage of a great solution.
Find out why
Another trend that could indicate the need for commitment to service design is low completion rates combined with an increase in support cases. A high level of engagement at the start of a process – like a healthy number of hits on the start button of a process flow – is a good indicator that your team has focused on something that your users really want.
However, when the same users encounter obstacles in the process, it is often easier for them to rely on your customer representatives to help them achieve their goals. This trend can be particularly time consuming for customers who now need assistance to meet their needs and for service personnel who are now inadvertently providing production support for a function.
The “nine why” exercise is a great strategy for finding the source of these types of problems. It is not enough to ask why users did not complete the process in your current product or system. Continuous curiosity will help you identify their true preferences and the benefits they will experience by bypassing the existing process. Rely on your user research partner or your objective colleagues to enable neutral meetings with users and service teams. Make sure to listen to the user Answers in the depth of the interview to innovative ideas that could lead to a unique solution to the current problems.
Follow the paper trail
One of the biggest red flags for the need for service design can be summed up in one word: workarounds. Product, development and UX teams work tirelessly for months, often years, to bring certain products to life. Users who thwart systems to develop their own workarounds are not nasty or persistent – they are in need. Every time a user deviates from a solution to create their own external process, there is an opportunity to expand the scope of the analysis.
Field studies, especially face-to-face observation, are fantastic tools for understanding exactly where these workarounds are coming from. If you see your users relying on unofficial sources of information, especially paper manuals or sticky notes, it is a call to action. Record this information and find meaningful ways to translate it into the experience you are designing for it.
The realities of remote working need not eliminate this type of research. Just focus on meeting users where they are now. Shorter screen-sharing sessions and requesting photos from workstations can still get you close to your users while staying socially distant.
Take a note from improvising
Chances are, your experience plays a role in both the product design and service design worlds. As a UX designer, it’s important to understand the scope of a project and the larger service model it will fit into. It may not be appropriate or possible for your team to do everything. When the root causes are supposed to be addressed by other product teams, or fall entirely into a different department, it can feel like moving a mountain to envision change.
Instead of fretting about the limits, take note of the improvisation. Company boundaries or organizational restrictions are informational only and should not end joint discussions. Yes, the scope of your project has definite limits, and that means this is a perfect opportunity to break some silos and collaborate in profound ways. Yes, you only have that much code, and that means you can use the knowledge of not one but two teams of highly skilled and creative tech experts to tackle the problem.
And yes, it can be difficult to draw the line between product design and service design. And that means it is important to employ strategies from both in order to give your users the best experience possible today.
Published on December 30, 2020 – 11:00 UTC