Enabling a Career Shift from User Experience to Service Design
Published: June 23, 2014
Having managed UX professionals at various levels for many years, I find that, after five to seven years working in user experience, they often ask, “What’s next?” in their career. Some become managers of UX groups, while others, who continue to enjoy doing the work, advance to the most senior level of their current role.
But there’s one group of UX professionals whose path is less obvious. They’ve likely been working in a UX Architect or Information Architect role, doing a mix of user research and design activities. These people often reach a point where they’re feeling less challenged—and that the work they’re doing is the same, day in and day out. Even the discovery of new ideas, concepts, and methods that is part of working in user experience—for example, responsive Web design or Lean UX—and would previously have ignited their interest or presented new challenges has ceased to do so. They have likely gained strong leadership skills and, when working on projects, tend to think more broadly than the user-interface design solution currently at hand. If this sounds like you, you may be suited to a career in service design.
In my first Service Design column for UXmatters in 2011, “Why UX Professionals Should Care About Service Design,” I defined service design and began to explain how it’s conceptually different from user experience. As a reminder, services function effectively only when an organization orchestrates all elements of the service—including the people, communications, processes, time, technologies, space, objects, and information—holistically. A core difference between digital UX design and service design is that great service experiences acknowledge the equality of the service provider and the service recipient—or customer—so service design looks at the service as a system of elements with equal weight rather than a single channel that has priority.
Since I wrote my first column, many UX professionals have expressed interest in knowing more about the differences between digital UX design and service design in the hope of understanding how they can begin to shift their own careers. Thus, in this column, I’ll outline how UX professionals can evolve the way they think, how they engage in projects, and what work they must do to have more strategic outcomes—and, ultimately, define their own career path.
Shifting the Questions That You Ask
To shift from doing digital UX design to doing service design, you need to be unremorsefully analytical and inquisitive. Questioning the value and the context of what you’re doing represents a great first step toward broadening the scope of your work.
For example, let’s say you’re about to start a project for a human resources (HR) portal. The portal will consolidate all of an organization’s currently separate and antiquated HR-related systems—including timesheets, time-off requests, benefits, and insurance—into one cohesive, self-service Web site experience. On a digital UX design project, you would focus primarily on how to create the best portal experience and would likely consider some related aspects of the experience such as email messages, mobile access, and intra-site links.
Your questions regarding the optimal user experience for the portal and its related digital elements remain important, but to create the best experience possible, you must also have a broader understanding of the overall employee service experience because that’s an employee’s context of use for the portal. What if an employee uses the portal for some aspects of HR services, but decides to call the HR call center for others? What if an employee is new and isn’t aware of what he or she needs to do to make a request? When you’re thinking about designing this new portal, think of it as more than just a Web site. Think of it as a centralized, self-service HR experience with broader strategic considerations that are important to creating the best experience:
- What other channels exist to fulfill the same requests? Call center? In-person support center? Local HR representative?
- Why would an employee choose the self-service, online channel versus some other channel?
- Would employees go back and forth across channels for a single service request?
- What should the overall service delivery experience look like?
- Are there services that employees can get only online or only offline?
- What feedback can employees provide about their current service experience—both online and offline?
- Are the stakeholders for the portal the same as those for the offline channels?
- What else does HR do to support employees beyond the current online services that won’t be part of the portal? How do employees access those? Are they related to the proposed services for the portal? What do employees think about that?
- How would a new hire experience the portal differently from a long-term employee?
- What would be the most effective way of changing employees’ behaviors—getting them to go from to the existing sites to the new portal?
These are the types of questions that UX professionals who are evolving to take on a more strategic role should begin to ask on their projects.
Shifting Your Engagement
Equally important to the questions that you ask are the circumstances in which you ask them. You should ask stakeholders to involve you in project discussions earlier—prior to scoping—so you can influence what the project ultimately becomes. Early involvement is key because, when you’re designing a service experience rather than just a digital user experience, your decisions relating to the end-to-end experience have a broader impact.
Returning to the HR service experience example, let’s say you discover that, while employees are likely to use the HR portal for most service requests, when issues become complicated, they’ll call the HR call center or visit the in-person support center. Through more discovery, you realize that HR representatives follow scripts for various types of calls that they receive at the call center and the applications that they use need to support that script. After even more digging, you realize that the current experience is broken where the HR representatives’ scripts and applications don’t sync with the information that employees have. These insights impact the requirements for not only the new HR portal, but also for the current call center tools and scripts. Only through early involvement on a project can you influence its scope to include design decisions that deliver the best service experience across all channels.
Realistically, you may not currently be involved in making early decisions about project scope. Gaining the early access that lets you influence such project decisions can take time. Nevertheless, even if you’re involved later on, you can and should ask similar questions to show that you’re thinking about the more strategic aspects of the project. How you phrase your questions and statements is key. For example:
- “I know you want to take this design approach and that’s certainly an option, but I’m wondering whether another approach might solve the same issues and be better for employees?”
- “It’s important that I understand what else employees are doing before and after using the software. Can you tell me what they’re doing before and after?”
- “I know the team has already solidified the requirements, but I’m wondering how this would be different from the existing solution?”
What might happen?
- Sometimes you’ll actually get to change small aspects of your current project for the better–with minimal impact on timing or budget.
- Often you’ll create opportunities for longer-term or later-phase work—whether relating to the design itself or to relevant change management or training activities.
- Your broader team and client stakeholders will realize that you ask hard, but valuable and important questions. They’ll begin to see you as more than someone who just “does UX design”—as a strategic partner who wants to do the right thing for them and the organization.
- You’ll become more confident about asking questions—and more importantly, know the best time to ask them and who you should ask.
When you do all of this on your current projects, your earlier involvement and greater influence on projects will become stronger possibilities over time.
Shifting Your Approach to Up-front Research
As you begin to ask these broader questions and gain earlier access to projects, you’ll need to shift your up-front insight gathering techniques to answer them. One of the first adjustments you’ll have to make as you take on more strategic work is to include more diverse stakeholders in your discovery activities.
For example, in the HR portal example, when thinking about the end-to-end service relationship between employees and HR, in addition to speaking to the people responsible for HR services who are accountable for the digital versions of those services, you would need access to the stakeholders who are responsible for the call center, in-person support center, training, change management, and communications. And, as you involve more people across the HR department, touching multiple aspects of HR, you’ll likely need greater visibility to and buy-in from the head of HR, under whom all of these groups reside.
Another adjustment you’ll need to make involves your up-front research with users, customers, and employees. Early insight gathering on a digital UX project would have the following characteristics:
focused—The topics that you cover in any research sessions focus on outcomes that impact user interface design decisions such as navigation and content. While you can certainly ask users about the broader context of the experience, the focus of your discussion is on the user interface.
targeted—When gathering user needs for a UX project, you can strategically identify and recruit the participants with whom you conduct your research, so you can ensure that you include the most relevant participants in the process.
simulative—Research often simulates what someone may do in a user interface. While it’s usually based on realistic scenarios with which you know users are familiar, you’ll typically ask participants to simulate situations that they may have encountered in the past or may likely meet in the future.
planned—You plan your research sessions and, accordingly, prepare a discussion guide to ensure that your conversations are productive and result in actionable outcomes.
In contrast, more service-oriented research has the following characteristics:
natural—Often research captures the actual use of a live service—for example, listening to calls to the HR call center—so you can see how people interact with the service naturally. It’s not planned, and callers may not even know they’re part of a research study.
open—Up-front research tends to be open ended, with the intent of discovering how people experience services today and what they would find valuable in the future. While you can certainly plan general categories for your observations, you’re just noting what people do and how they do it.
complex—Because of how broad a service can be, you likely need a few research approaches so you can triangulate the results and get a full view of the current and ideal service experiences. In the HR example, you may need to conduct more structured and formal interviews with employees, then complement those insights with your observations of HR representatives in the call center and in-person support center.
flexible—Because of how open and broad service-oriented research is, you must go into your research without any real assumptions, be able to start deducing insights in the middle of your research, and be prepared to shift your approach on the fly. For example, you may start out observing people using a service, then decide that you need to ask them a few questions to probe for more information on issues that you noticed during your observations.
Shifting Your Design Deliverables
It’s not surprising that, if your questions and early insight-gathering methods broaden in scope, so do your deliverables. For the sake of simplicity, I’ll focus on three core digital UX deliverables—personas, prototypes, and scenarios—and illustrate how their counterparts in service design are, at their core, the same.
Personas illustrate who will interact with your designs. Whether for a digital user interface or an end-to-end service, they show the needs, preferences, behaviors, and attitudes of your target audience. Throughout a project, they serve as a consistent beacon against which to validate your thinking and keep you realistic about the value you’re providing. They also help to illustrate opportunities, ideas, and ways of designing that, without going through the exercise of creating the personas, you might not have considered.
The primary difference between digital UX design and service design with regard to personas is simple: the quantity of data and the number of personas. When defining a service, you’ll just naturally have more content to shape your personas. For our example HR service experience, personas would show behaviors relating to all channels, with no single channel—for example, digital—as the assumed focus of a persona.
In addition to your gathering more content for each persona, you’ll create more personas. Remember, you’re not designing this experience just for the employees, you’re equally considering the needs of the HR representatives who are providing the services. Therefore, you may have three to five personas representing employees and another three to five personas representing HR workers.
Not so simply, prototypes visualize the space in which our personas move. In UX design, prototypes could be static wireframes or clickable, high-fidelity user interfaces. Regardless, their intent is to communicate how users or customers can interact with a digital space. In service design, service prototypes are often three-dimensional, physical environments that illustrate the various service channels and types of users who are involved in the service. This means learning to use new tools like Lego Work Play or creating physical paper prototypes.
Scenarios articulate the linear process in which our personas move through space. They show the steps that people take in going through the experience. Similar to personas, the exercise of creating scenarios helps uncover potential problems, as well as opportunities. The primary difference between scenarios for UX design and service design is their scale and scope. UX scenarios focus on illustrating a single persona’s steps through the relevant digital interfaces. Service design scenarios, often referred to as service blueprints, capture the service as a system, noting handoffs and interactions between service recipients and service providers across all channels.
Shifting Your Approach to Validation Research
When getting feedback on your in-progress design concepts, the differences between UX design and service design are similar to the differences characteristic of up-front research. In UX research, you might conduct a usability test whose focus is on getting feedback on the interaction design for a digital user interface from a sample of the target audience. Service design research is more complex and, as I mentioned in my original 2011 article, more theatrical.
First, you need to simulate the interactions between provider and recipient in the new service experience. Therefore, research would include samples of people in both types of roles, and participants need to act out the experience. In UX research, people may already feel awkward because they feel that they’re being tested, and it’s our role to make them feel comfortable. In service design research, the potential for people feeling awkward is even more pronounced. This means you may need to set the expectation that it’s going to be fun and interactive. So, rather than creating a discussion guide for your research, you’ll actually create a script for participants to follow, stopping at appropriate points to allow them to give feedback.
Second, because of the potential breadth of a service—across various channels and touchpoints—it can be very difficult to simulate a future experience realistically. While you may have a digital prototype that you can test, you’ll also need various props and even sets—such as those paper prototypes I mentioned earlier—for the participants to interact with.
Third, services often happen across a longer time period than a user’s interactions with a digital user experience. During a usability test, you can ascertain whether the time it takes to do certain tasks is reasonable for participants. But during service design validation research, it’s difficult to simulate time because it could extend over many hours, days, weeks, or even longer. In the HR example, consider how long it takes to get your insurance ID card after going through your HR’s benefits enrollment. How can you best understand whether that’s a reasonable timeframe? The truth is that, for some discovery objectives, you simply won’t be able to get any observable feedback—and will have to simply rely on asking whether the timeframe for or between interactions is reasonable.
As I mentioned earlier, the design of digital user experiences and service design are not mutually exclusive. As I have hopefully illustrated, significant overlap exists between the two disciplines, with the only difference often being a question of scale or quantity.
UX design and service design are essentially two practices on the spectrum of experience design, not wholly separate practices. What this means is that UX professionals who are no longer feeling challenged by or content with the work that they’re currently doing and who aspire to do more are perfectly suited to designing great service experiences. If you want to move on to service design, all you need to do is expand your existing skillsets that you use in designing digital experiences.