Design Sprint: Visual Routing Designer
How to best allow contact center admins to configure the routing experience for callers and agents.
Design Sprint
A Design Sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers. Over the span of one business week, we gathered and worked together on how to solve a specific problem from a variety of angles. Who was involved:
- Product (2)
- Engineering (2)
- Design (2)
- Customer Success (2)
- Agile practices (1)
The Problem
Call routing is core to Talkdesk, and currently it’s defined through a series of settings. Our customers encounter a variety of problems today from finding it hard to visualize and test their settings, troubleshoot what went wrong on a call, or understand what settings to change to improve their metrics.
The Goal: Empower admins /supervisors to personalize their customer experience.
Monday: Make a map and choose a target
What we know from speaking with customers is that a call center is like a microclimate. It has its own seasons, its ebbs and flows, high tides and low tides. To be able to manage a call center, supervisors must have insight into the volumes and patterns of their callers. This allows them to determine appropriate staffing, which in turn allows them to configure appropriate routing. Not only determine, but test and measure to optimize for their KPIs.
Design sprints are great for rapid ideation and testing, but not great for testing large systems. So part of the process of a design sprint is to choose a “target”, or prototype-able section of a map. For this sprint, we choose to focus on Configure & Validate because without it none of the other steps would make much sense.
“How Might We” Questions
HMWs are probably one of my favorite tools in the UX toolbox. They’re a great way to quickly scope and/or frame a problem without being confrontational to existing perspectives. HMWs position observations, problems, or concerns as questions that describe the general mise-en-scène, but doesn’t prescribe a solution. Examples of HMWs from our session:
- HMW: Collect as much information about a caller without creating friction?
- HWM: We route calls based on context about the caller?
- HMW: Arm agents with the information they need at the correct time?
- HMW: Visualize complicated flow logic in a simple, understandable way?
- HWM: Reduce fear associate with changing the flow?
Tuesday: Sketch Competing Solutions
The first half of the day everyone spends finding inspiration from other industries, prints it out, and takes a few minutes to present to the group. For us there were a few examples of Sankey diagrams, existing IVR tree designs, as well as some interesting script related solutions. We all take notes as the others present, and then spend the rest of the day on low fidelity sketches — boxes, wireframes, stick figures, etc.
Wednesday: Vote & Storyboard
- Art Museum: Put the solution sketches on the wall with masking tape.
- Heat Map: Look at all the solutions in silence, and use dot stickers to mark interesting parts.
- Speed Critique: Quickly discuss the highlights of each solution, and use sticky notes to capture big ideas.
- Straw Poll: Each person gets to choose one solution, and votet for it with a dot sticker.
- Supervote: The decider makes the final decision, with more stickers.
- Storyboard: We take the winning scenes from our sketches and weave them into a storyboard: a step-by-step plan for our prototype.
Use Case: Connect contact with their case owner
To make testing easier, we decided to design for a very common use case that would be familiar to most admin/supervisor personas. If you’re familiar with the contact center space you’ll understand the terms used here. Contact in this context refers to a caller who may or may not be recognized in the CMS of record — which can differ from customer to customer. In this case we are using Salesforce. A case owner is a representative who is responsible for the case, which here is likely a support request since the call is coming in from the Lisbon Support Line. So the challenge is to set up a flow that will automatically route the caller to the correct corresponding case owner, if one exists. If one does not exist, or cannot be found, then define where the call should be routed.
Thursday: Prototype
Now its elbow grease time. Today day we turn that storyboard into a prototype. We decided to go with a click-through prototype using InVision, since all we want is a realistic façade to test with customers. We’ll also make sure everything is ready for Friday’s test by confirming the schedule, reviewing the prototype, and writing an interview script. Since having too many cooks in the kitchen can slow things down at this point, we assign roles. My infinitely talented designer Daniel Chae was given the role of Maker — aka pixel pusher, vector jockey, hey you, etc. I took Asset Collector as well as Advisor, which I shared with the ever gracious Diana Tobey, who also interviewed customers.
Friday: User Testing
For this day we lined up 5 of our customers who had expressed some interest or concern in the way they wanted to handle call flows. We set this up through google hangouts where the customer would only be able to see the interviewer, but the rest of the team could watch and listen through screen share. There was a set script, and clearly a flow we had in mind, but we made sure to lead or direct the customer as little as possible. While this was going on everyone on the team was writing down notes about the experience.
Below you can see a linear view of the flow we built. As you might notice, the admin starts of with a pre-existing flow with three basic components: Trigger, Context, and Outcome. Without being given any direction, the user is encouraged to audibly describe what they are looking at as they explore the UI. They are then given the goal to change the flow so that context about the caller (case number in this example) can be gathered automatically, before reaching the agent.
“…change the flow so that context about the caller (case number in this example) can be gathered automatically, before reaching the agent.”
Results and Learnings
No matter how much you might think you know about your hypothesis and your customers, it is always illuminating to observe them together naturally. In the image below we have collected and collated all the notes taken during the interviews. Notes with green ink are positive, black ink neutral, and red ink negative or friction causing. As you can see, there is a lot of red.
Prototype fidelity
One of the biggest and most obvious friction points had to do with the level of prototype fidelity and the flow we chose. Users were dropped off in the middle of an editor which is very much not linear — there are many different things you might be able to do at once. But because of the limitations of the click-through prototype, users could only click where we had designed the flow to allow. This created a cognitive disconnect; because some things were clickable but others that looked clickable were not, our users stopped using the mouse cursor to explore the designs. Hence, even when something was apparent to them they wouldn’t advance to the next screen without our input.
In the future I would probably use a prototyping tool that allows for more live and dynamic interactions. At the time of this writing, I really like Principle.
Roleplaying
One of the other unexpected problems we ran into was that our customers had a hard time thinking outside their own, specific use cases. That is, when they were asked generic questions like “What would you do here?”, they would answer by explaining something that was outside the scope of the prototype. One of the challenges with enterprise software is that your customer’s needs are specific and often vastly different from one another. We attempted to address this with a use case we thought would be a common denominator, but even then they would often ignore the goals they were given and revert to their own situational problems.
Keep it simple(r)
During the storyboarding process we added in some advanced “optional” functionality. Rather than simply allowing admins to craft the call flow from their own experience, we added in “recommendations” from our little AI bot. We thought this would make the experience more seamless, but when admins didn’t like the recommendation (again because of specific use cases), there was no way for them to continue without selecting it.
I think in the future, if we have time to include things like recommendations we should do so as a completely optional parallel track. This way we don’t put a wall for those whose needs are different from what we expected. But really, if we did have that extra time I think it would be better spent making the prototype more interactive than varied in flow.
