A note before we begin
About the project
This case study represents an experience design project at a Fortune-ranked financial services firm. I have abstracted certain details about the project while retaining the nuances that speak to the nature of the design research effort and the quality of actionable insights that are synthesized.
About my role
My role is that of a Lead Researcher and Designer for an Agent Platform. In close collaboration with my Product partner, we generated the research plan, discussion guide, and participant recruitment criteria before we interviewed a total of 6 back-stage agents, 12 front-stage agents, and 8 business customers. We then mapped the experience to synthesize actionable insights that have far-reaching implications on the design of our Agent Platform and our data strategy in the future.
Getting to the truth of the situation
This is a story about how mapping the lived experience of various actors in a multi-layered service delivery system led to the identification of leverage points. These are key moments in the experience where the right intervention can result in strategic gains for all actors involved.
I captured the interactions between the business customer, frontstage agents, and backstage agents in one experience map. To illustrate the dialogue that takes place between each layer, I used conversation quotes that capture each actor’s sentiment at that point in the experience.
The experience map visualizes the breaking of trust between actors in the service delivery layers, and ultimately the service recipients.
The moments where trust is broken turned out to be the key moments where the right intervention can create strategic gains in the long-term, and tactical pain-relievers in the short-term.
I’ll spend the rest of this case study to explain how I got here.
Method
Context
An approval process where problems were discovered after the approval was issued became a chronic source of frustration for our business customers. The communication and resolution processes were so painful that many customers chose to part ways with the company as a result. And so my product partner and I were tasked to get to the bottom of this painful process.
What we want to learn
We hypothesized that the problem resolution process is difficult because customers lack the right information to take action. We also hypothesized that communicating the information digitally will bring transparency to the process and alleviate the pain. To test these hypotheses, we prepared 2 things to bring to our interviews:
First, a discusssion guide consisting of generative questions designed to draw out stories of the customers’ best and worst experiences with the approval process. In particular, we are looking for their inner thinking, emotional reactions, and guiding principles.
Second, a prototype that visualizes our best thinking around what information is needed to make the problem-resolution process painless. Our intent is to get the customer to react to the prototype and co-design the ideal solution with us.
How to get the learnings
With such an ambiguous problem space, we knew we needed to empathize and gather diverse perspectives of the service delivery experience.
Because the customer experiences we are seeking to understand are the culmination of outputs by several actors in the system, we chose to interview representatives from the front-stage agent teams and back-stage agent teams, in addition to our business customers.
We observed 6 types of back-stage agents go through their processes, and interviewed 12 front-stage agents.
We talked to a lot more front-stage agents because we found that they often go outside of their core functions to help both the back-stage agents and the business customers. We then identified the best future-leaning front-stage agents and partnered heavily with them to develop our prototype.
With the prototype further developed, we proceeded to interview 8 business-customers, who are the primary recipients of the service rendered.
We chose to interview customers who held key decision making roles. We found that their perspectives help us get to their durable purposes and what they care about most. In the past, we interviewed customers who hold the performer roles, and it usually yielded operational details that do not get to the root cause of the problem.
Experience Maps
Capturing the learning
We synthesized the interaction between the business customer, frontstage agent, and backstage agents in one experience map. To illustrate the dialogue that takes place between each layer, I used conversation quotes that capture each actor’s sentiment at that point in the experience.
Visualizing the experience map allowed us to see 3 major experience phases: the business-as-usual phase, the trust-breaking phase, and the damage-control phase.
Here is a snapshot of the entire map:
Insights
Synthesizing insights for action
Our initial hypothesis about how the lack of information is the reason for the pain, turned out to be a symptom of the real problem. What follows are the actionable insights we gleaned from finding patterns and making sense of many complex inputs from various actors. We would not have gotten to these insights without visualizing each actor’s interactions in the system.
Insight 1
“Offense and defense are not aligned to play the game.”
We saw what it looked like for actors to distrust other actors. Below is a diagram of how actors in one service layer are checking the output of the actors from the service layer before it. For instance, the front-stage agents are dipping down from their highest-value activities to double-check the work of back-stage agents.
To take the metaphor of a sports team, it’s as if the front-stage agents are offense players, while the back-stage agents are the defense players. Today, offense cannot capture more ground because they do not trust that defense has got their back.
Insight 2
Fundamentally, we have an explainability and accuracy problem.
We learned that our business customers do not trust the information provided because of 2 things: the confusing way by which the information is communicated, and the inaccuracy present in the information.
Unless the accuracy and explainability problems are addressed, communicating over a digital channel will not stop front-stage agents from double-checking the work of back-stage agents. However, addressing accuracy and explainability will only alleviate the lack of trust in the environment in the short term.
Insight 3
The strategic problem is the existence of an after-the-fact denial.
If we were present at the founding of the company, we would never intentionally build an after-the-fact denial into our business plan. By upleveling to the customer’s point of view, we saw how our business customers viewed the after-the-fact denial as the breaking of a promise.
This insight came when we examined why the resolution process existed in the first place. Our customers expected our company to verify that everything is in order by the time they receive an approval to proceed. When our company informs them that a problem is discovered, and that our company must retract the approval terms that were previously agreed-upon—that is the ultimate breaking of trust with our customers.
Design Implications
Design Implication 1
Having accurate data to find problems before the approval process will eliminate after-the-fact denials.
If our company is able to get the approval decision right the first time, and never retract the approval after it is given, then there won’t be any trust-breaking events. Agents will no longer spend precious time on damage-control activities.
The implication is that our team must determine the right type of data that are needed to make an approval decision correctly on the first try. Then, we will need to plan how to obtain access to those data before an approval is made.
Design Implication 2
To honor the company value proposition, agent teams need to shift from reactive to proactive problem-identification.
The problem-identification process that happens AFTER the approval is made, needs to happen BEFORE the approval is made.
This means that the problem-identification process will need to happen in a much shorter timeframe. The implication is that the Agent Platform needs to augment agents with technology in order to dramatically increase the speed by which a problem is identified.