This article was written by Tiffany Hale and originally published on Built In.
Failure is more than a rite of passage when working in technology — it’s a guarantee. The failure designers and developers are comfortable with, however, usually falls into the cozy iteration cycle where it’s “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 ship, code is live, and things don’t go as expected.





window.jwLibrary = "chM58Ml7";


When the straightforward application of design thinking techniques lead to unexpected or undesirable outcomes, it may be time to ask yourself: Are you designing for a productor a service?
What is service design anyway?
To truly understand how to answer this, we need to take a closer look at the relationship between product design and service design. Product design, according to the Interaction Design Foundation, is the process of synthesizing user’s needs with business goals to create “consistently successful products.” Often, when thinking of such products, we look to wildly successful examples like the iPhone.
However, technology need not be at the heart of a successful product design. The patent for the product we know as a paperclip was filed in 1899, and we can argue that it’s still successfully meeting people’s needs over a century later.
Service design is different from — but also often inclusive of — product design. The Nielsen Norman Group describes service design as “the activity of planning and organizing a business’ resources (people, props, and processes) in order to (1) directly improve the employee’s experience, and (2) indirectly, the customer’s experience.”
For an example of what service design looks like, let’s examine the process of buying a cup of coffee for mobile pick-up. The mobile ordering app is often what we think of as the product design — everything from the in-app payment experience to the little ping on your phone when your drink is ready for pick-up to the digital receipt you flash at the barista to pick up your order. All this falls into the bucket of user experience design.
Where does service design come in? Service design applies to the point-of-sale (POS) system that alerts baristas to new orders. It’s the layout of the prep counter where the barista creates your drink. It’s the markers on the floor that help you understand where to go for a mobile pick-up order, and the stanchions that separate you from the walk-in customers, and even the little alert that asks you to review your experience after you’ve picked up your order. The success of service design and product design working in unison leads to the satisfaction of that first sip of coffee.
Discord between the two, however, can lead to some baffling trends in user behaviors, which can signal you may need to focus on the design of the service more than the direct design of the product.
Red flags on the road to retention
When it comes to identifying conflicts between a product design and the larger needs of a service design, data can offer big hints into an underlying problem. Glowing reviews of a product or application paired with high churn can signal larger issues at play in the experience.
How would this play out in our coffee pick-up example?
Let’s imagine, instead of a streamlined, beautiful POS system that notifies the baristas of new orders, there’s an antiquated printed receipt system that silently spits out a stream of new orders. The customer’s experience would change drastically. The customer would receive an alert indicating the order is ready based on estimated completion timelines. The baristas, however, often get caught up in the hubbub of in-store orders, and mobile orders fall by the wayside.
The customer now has to wait several minutes for their drink, sometimes doubling the expected pick-up time. While the app itself (the product) has a steady stream of new users and great reviews on the app stores for its slick interface, customers would still end up buying from a competitor and abandoning usage of the app.
To remedy this experience, user journey mapping is a must. Journey mapping in product design may focus on a single portion of a customer’s experience. Journey mapping from a service design perspective extends this focus to all touchpoints that make the customer’s experience possible. This holistic view often uncovers frustrations that live well outside of an app user’s locus of control.
It’s important to remember that, even if a process inhibitor isn’t directly reported by the customer, it affects their experience, perception, and usage of any singular product they interact with.
In our coffee pick-up example, users may complain about long wait times, but the root of the problem lies with insufficient notification and tracking with the barista’s POS. Improvements to the POS system, which clients never see, would cause downstream upticks in customer satisfaction and repeated app usage as drinks are delivered in a timely manner. Customers don’t need to have full knowledge of the problem in order to reap the benefits of a great solution.
Discover why
Another trend that could signify a need for service design engagement is low completion rates in tandem with an uptick in support inquiries. High engagement at the start of a process — like a healthy number of hits on the start button of a process flow — is a great indicator that your team has zeroed in on something your users truly desire.
If, however, those same users hit barriers in the process, it’s often easier for them to rely on your client representatives to achieve their goals. This trend can be particularly time-consuming to customers, who now have to seek out support to meet their needs, and to service representatives, who are now unintentionally providing production support for a feature.
The “nine whys” exercise is a great strategy to tease out the origin of these kinds of problems. It’s not enough to ask why users didn’t complete the process in your current product or system. Continual curiosity will help you identify their true preferences and the benefits they experience by circumventing the existing process. Lean on your user research partner or objective colleagues to facilitate neutral sessions with users and service teams alike. Be sure to listen to the user’s answers in the depth of the interview for innovative ideas that could inspire a unique fix to the current issues.
Follow the paper trail
One of the biggest red flags of the need for service design can be summarized 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 aren’t evil or stubborn — they’re in need. Any time a user deviates from a solution to create their own external process, it’s an opportunity to expand the analytical scope.
Field studies, specifically direct observation, are fantastic tools for understanding precisely where these workarounds come from. When you see your users relying on unofficial information sources, especially paper guides or sticky notes, that’s a call to action. Record that information and find meaningful ways to bring it into the experience you’re designing for them.
The realities of remote work needn’t eliminate this kind of research. Simply focus on meeting users where they are now. Shorter sessions with screen sharing and requesting photographs of workstations can still bring you close to your users while staying socially distanced.
Take a hint from improv
Chances are, your experience is playing a part 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 into which it fits. It may not be appropriate, or possible, for your team to take on everything. If the root causes should be addressed by other product teams, or fall into another department entirely, it can feel like moving a mountain to envision change.
Instead of fretting about the limitations — take a note from improvisation. Corporate boundaries or organizational limitations are simply information, and should not end collaborative conversations. Yes, the scope of your project has definitive boundaries, and that means it’s a perfect opportunity to bust some silos and work in deeply collaborative ways. Yes, you only own so much of the code, and that means you can harness the knowledge of not one, but two teams of highly competent and creative tech experts to address the problem.
And yes, it can be tricky to draw the line between product design and service design. And that means it’s vital to employ strategies of both to deliver the greatest experience to your users today.

Source: The Next Web

Powered by NewsAPI.org