How to design for customer experience: Part two

At Pega, designers use design thinking methodologies for Microjourneys™ not only to create an efficient and user-friendly flow, but also to streamline how we collaborate and build experiences as a team. 
 
In part one of this series, we detailed several mapping exercises to help you better understand your user personas, including: 

• Defining user personas 
  • Understanding a user’s personal experience, expertise, and situation from the perspective of their role
     
• Job Mapping
  • Understanding what needs to be accomplished, in what order, and how various personas play into completing the jobs-to-be-done (JTBD)
     
• Using empathy as driver
  • Considering the context of the work that is being done, and how that might provide an opportunity to improve the user experience
  • Understanding the approach each user takes to complete a job 

In this article, we’ll discuss how to take design thinking further – and use the results to create user-driven software (and help you do the same for your users and customers).  

Use Job Mapping to define the work done by users 

One crucial aspect to designing Microjourneys for customer service is considering how our steps, fields, and data structure can be used by our two different personas: CSRs (customer service reps) and end customers. We use our clearly written job stories to paint the picture of what exactly needs to be done by/for each persona. 
 
The goal is to create a common experience that caters to both personas, and, in turn, supports customers – whether they are:  

• Doing the work alone
   
• Stopping halfway through the work and calling in for help
   
• Needing the assistance of a CSR from start to finish 

Once we have identified a common set of steps in our Job Mapping exercise, we can determine the data and fields required to do the work. This understanding allows us to find the common language used in our step names, headers, and field labels, among numerous other things. The case and data structure supporting the Microjourney can then be used across channels, allowing a variety of personas to benefit.  

For example, in the File a Claim use case, a customer may need to input some information about the other driver, (name, phone, address, insurance info, etc.) and will need fields in the form to do so. The CSR may have two options: 1. Search for the other responsible party in their list of customers, or 2. if the other driver is not a customer, include the data fields. This structure helps us define the flow for completing work, and the logical progression of the job up until its completion, even if work is being handed off and completed by different personas.

Once you define the structured flow, you can translate the flow into UI and data requirements 

Once we have outlined the case and data structure, we can start creating initial mockups with more confidence and fewer unanswered questions. The pre-design research phase creates a more efficient process by asking business and tech stakeholders about data needs, required processes, and competitive approaches to a common business problem. Since we have done the deep planning work at the beginning of the project, we can now focus on how to collect the information we need from users rather than what information needs to be collected.  

Next, we use a technique called defining the question protocol to review industry standards and regulations around data collection and usage. This allows us to trim down the experience to just what is necessary without adding fields or steps that are not useful or aligned to the industry standard. We can also determine what data we already know about our customers on their customer record to further reduce the amount of input required from our users.  

Then we use “How might we” statements to identify opportunities to simplify the experiences and make the jobs easier to be done. For example, “How might we reduce the amount of information a customer needs to input at the site of an accident?” This prompts us to consider what information we may already have (customer data, vehicles owned, etc.) and then focus on what is immediately required to file an insurance claim. We can then split the data collection up between the File a Claim Microjourney, and the potential follow-up Microjourney a claims investigator will work on. 
 
If we have data already, we shouldn’t require users to put in extra effort when our system and processes can do it for them instead – because no one wants to fill out a long form while they are standing at the side of the road!

Draw on Pega’s power to cater to the customer

Here’s a real-life example: we know that an insurance customer is calling to submit an auto claim on one of their policies. Here's how we would approach this:  

• We use Job Mapping to identify that a customer service center might only process one of their many policy types (auto, home, life, etc. All have different call center numbers).
   
• The customer verifies the policy they are calling about during the first step in the interaction (customer verification); so, we would not require an additional step in the File a Claim Microjourney.  

This insight not only makes implementation easier, but it also creates a more streamlined experience for the CSR working in the interaction portal. The customer simply needs to focus on the easy-to-use form to collect the details we don’t yet have about them and their situation. 

Expected or common use cases are other insights we often find through our Job Mapping exercise: 

• If the default fields assume common use cases, we can reduce work for our users by using what we already know in our data model.
   
• Do we already have data objects containing the customer’s contact information or preferences? Then we should use this in the data collection process and reduce work as much as possible.  

A customer may want to receive future communications related to the Microjourney – so in the form field, we may show their preferred communications method and address from their existing customer record. This reduces the number of required inputs and simply requires a verbal confirmation from the customer that, yes, they would like us to text them on their default phone number.

Rely on design thinking to help with scaling and consistency 

The design thinking process also allows us to identify the core features of a Microjourney and understand how it overlaps with other case types and applications. If we identify granular design patterns, or even large portions of a flow (such as filing an insurance claim), we can research to determine how each vertical industry may take advantage of it. This allows us to ensure consistency across applications and reduces future development cost. 

We also find that the design thinking and Job Mapping approach allows us to identify additional features that we may expect our clients to need in the future, either through extension points or through future Pega releases. 
 
For example, here are additional opportunities that we might discover from a File a Claim Microjourney: 

Version one: File a Claim 

• Pull up list of automobiles on file
• Incident form
• File upload for proof 

Version two: File a Claim 

• Integration with towing service
• Rideshare vouchers automatically sent to customers
• Etc.

Design thinking facilitates the end-to-end project 

Design thinking does not end at creating UI or a great user experience; it also helps cross-functional teammates create a great product, helping tie technical and business requirements, personas, and expected outcomes into a cohesive outline. Design thinking also allows us to work in an agile manner and react to unforeseen issues, such as technical challenges or business reprioritization. 
 
By going through the process of understanding the users, their contexts, and how they have interacted with our systems, we obtain a clear roadmap that translates directly into what we build in App Studio. We can understand all the case types, personas, data objects, and other Pega elements we need before we even start development. The artifacts created from the work act as a touchstone for the entire project and are often referenced late into development (and often afterwards during future work).  

If future questions arise, the teams involved will have a strong foundation for finding answers – thanks to our extensive investigation into users’ needs. Design thinking also enables all stakeholders to contribute to the scope of the work, and oftentimes allows us to view the Microjourneys from a more strategic lens, spanning multiple releases.

Embrace design thinking to improve your process – and your organization

 Design thinking is a fundamental part of Pega’s product design process. We encourage designers and developers working with Pega to embrace it in their organizations – because when you identify who you’re designing for, what their goals are, and how you can meet those goals, you’ll be using resources more efficiently, connecting better with your users, and making your application stronger and easier to enhance in the future. No matter who your customer is or how complex your data is, embracing design thinking during the design and development process distinguishes your product and contributes to your organization’s design maturity.

Recommended resources:

• Review Part one of our series on designing for customer experience.

• Learn how to conceptualize, plan, and prototype designs for a Pega application.

• Explore the Cosmos design system.

Don’t forget 

JOIN THE CONVERSATION on Collaboration Center  
FOLLOW @PegaDeveloper on Twitter  
SUBSCRIBE to the Pega Developer Podcast on Spotify or via RSS