High Level Timeline
  • Start date June 2016
  • GA Release November 2017
Key Goal

To decrease the amount of time a manager spends on call recordings to address the highest priority interactions.

Make of the Team

Lead UI/UX Designer, Product Manager, VP of Product Design, 6 Software Engineers, 5 R&D Engineers, 2 Scrummasters, Product Owner, CPO.

Product Status

brightness_1 GA Released

The Problem
The quality assurance manager wasted a lot of time listening to recordings that offered no insights for tracking agent performance in the contact center.

When a QA would select calls to listen to, there was no efficient way of knowing if it had any of the data they were looking for, such as information on empathy, compliance or politeness. This means it was quite common for this user to listen to a recording from start to finish which could be up to 2 hours long, only to find there was nothing that needed their attention.

My Role
I was the User Researcher, Interaction Designer, Visual Designer, Experience Designer and UI Developer.

I collaborated on the product strategy with the VP of product design and business marketing strategist in person and gathered competitive research from professional support services. I oversaw the first implementation with the Product Manager with the remote R&D team to apply a basic UI to their speech analytics engine.

I worked alongside the Product Manager with another remote group of engineers to refine the UI design. They had very little experience with design in CSS so, to help them, I coded a prototype in order to handoff pieces of final code. I would periodically present the work before the deadlines for buy-in from the CPO and VP of product design.

Product Constraints
I was a design team of 1 leading the product experience and collaboration with 2 remote teams in the UK.

Another interesting challenge was static images and interactive prototypes weren't enough information for back-end engineers that had little to no experience with CSS or finishing product design. The time difference made it difficult to make sure the teams had what they needed to keep the project moving.

Understanding the User
There were no defined personas at the time so I had to do a little more digging in a short amount of time.

I found out a QA manager spends hours listening to call recordings to gather data on how well they interact with the customer, handle conflict resolution, and where they could improve. At the time the process was to randomly select call recordings from an agent's call history list then listen to them from beginning to end. This was a very manual process that rarely provided enough results.

The QA manager was devoted to getting the right information to present to the supervisor and call center manager in order to know which agent was performing the best, who had potential if they were offered training, and who should be let go.


Breaking Down the Design Process
This end-to-end project presented raw call data to the user in a speech-to-text tool which worked with their own call analytics. The process was based on traditional product design steps of define, ideate, prototype, build, and analyze.
1
Define

In addition to researching the history of speech analytics tools online, I spoke with my advisory board of experts, the VP of product design and the product manager to really understand what made these products successful, what patterns a QA manager is used to, what we should prioritize, and what problems still weren't being addressed. This resulted in a lot of notes and a list of use cases.

2
Ideate

I took my research notes, use cases, and created user flows. I ran these by my stakeholders first, made necessary changes, then presented them to the team I'd be collaborating with. The team of engineers and the product manager provided insights on potential issues.

3
Prototype

Next the research gathered became the basis for wireframe prototypes, which were then tested through user interviews with my advisory board. After iterations were made then POC designs were handed off to the remote team to code a fully interactive POC to show at Dreamforce 2017.

Wireframes
POC Prototype for Dreamforce 2017
4
Build

Final designs were static images created in Illustrator and handed off specs to developers. We ran into some issues with the lack of information of interaction so I built an interactive prototype in UXPin to present to the team. The final designs came together in time to meet our Pilot deadline September 2017.

5
Analyze

After pilot I suggested to the CPO that creating an admin panel to set categories would make this product be ready to release. Even though this wasn't taken into consideration it became obvious from customer feedback that setting categories by JSON is not easy to do. The addition of an admin panel increased in our backlog priority immediately.

Product Release Results

We helped Six Pack Abs achieve a 500% growth in sales with the Conversation Analyzer at the core.

You guys killed it! The UI is awesome, it blew my mind. I really think this is going to help our business mitigate the risk but mostly to get insights on what our people are doing, what our behaviors are, what we are doing good, doing bad, and what we can do to improve. I think 1000% this is the best thing we’ve been delivered.

- Chase, CTO
Lessons Learned
With an upsell rate of 90%, it changed the outlook for the company. It showed the power of having a finished, well-designed and intuitive product is more important than just throwing out a basic MVP to the customers.

In this case having such a control over the usability and design of the product, through research, images, and code was only possible due to a product manager who championed UX in person to the team. The engineers stayed on track because they were being led by someone who had faith that design-driven production is the key to success.