Large Project Case Study

The project

A large power utility with 80% market share in its state has an extensive automated phone system. The documentation of this system is just over 2000 pages long, including design, development, and grammar requirements.

I was the lead designer for this project for more than 2 years. My charter was to unify the tone and persona across this immense project, all while building usable and elegant conversational functionality.

The team

The size of my team varied between 1 and 6 designers. The modular nature of the project provided an ideal environment for new designers and interns to learn the processes involved, with the opportunity to build functionality from start to finish.

Additionally, the customer wanted to use their own internal designers, so I supervised their training and design work as well.

The result

In addition to completing a best-in-class automated system, the customer was thrilled with the quality of work and organization of our team. The designers under me went on to lead successful projects of their own. They brought innovative ideas to the design practice, and their techniques were integrated into the process.

Usability Case Study

The product

The product is a proprietary metrics analysis tool, specially designed to analyze logs from inbound phone systems. It’s a GUI over a database.

Defining and recruiting the user archetypes

We determined a range of users, from the non-technical director who only wants the bottom line, to the experienced Speech Scientist who is trying to solve a deep data problem. Then, we found each of these users incarnate.

Designing the test

It was important to us to test a range of skill sets, so we designed a range of problems with varying difficulty. Some of the tests were just to evaluate discoverability, while others were to complete specific filtering tasks. The last scenario was incredibly generic, but typical of real life: People are having problems. There's no specific complaint. What can you find that might be making people complain?

Moderating the test

I worked with the participants over a 2-day period, monitoring their behavior from the adjacent viewing room and taking detailed notes on their behavior. When they got stuck, or otherwise reached an unrecoverable point, I would regroup with them to get feedback. We found everything from major bugs to an unfortunate kerning problem.

Writing up the recommendations

It became immediately clear what needed to be fixed, and in what priority. I categorized my notes into a deliverable that made it easy to track the progress and disposition of each item.

Fraud Case Study

The problem

My large utilities customer had an issue with callers attempting to make check payments using fraudulent routing numbers. This needed to be fixed immediately. The customer provided a list of the routing numbers that needed to be blocked. They also needed a sternly worded message played when the fraud attempt was detected.

The team

We scrambled all the needed skill sets: a UI designer, a Spanish localization specialist, a developer, a QA lead, a speech scientist, and the recording studio. Very quickly, we identified all the details of the solution, laid out a plan for rapid design, implementation, testing, and deployment.

The solution

We added logic to the existing routing number collection to check the given routing number against the list of fraudulent numbers. We worked with the customer’s legal department to finalize the stern warning. We added logic to allow the caller another try to provide a valid routing number. We had all the prompts localized into Spanish, and had all the new prompts professionally recorded.

View fullsize

The outcome

The turnaround time from reporting the problem to our team to the deployment of the solution, was 36 hours including all the change control restrictions on the customer side. The customer reports that there are no longer any instances of this type of fraud occurring on their automated system.

Life Insurance Case Study

The Problem

The customer, a large, well-known life insurance company, needed a complete overhaul of their antique automated phone system. They didn’t know where to begin.

Where to begin

I met with the stakeholders and we made a list of all the functionality they wanted, all their business rules around those functions, as well as details of the back-end values that were available for use. The customer had already a persona defined, as well as user archetypes. They also had a voice talent already contracted.

Whiteboard the design structure

Using the inherent structure of their business, we worked out a plan for the high level flow that would fit with the persona. Authentication determines the policy type, and each policy type has a unique subset of functionality. The idea was to build reusable functions that would be called when chosen from a given menu. After discussion and refinement, the business agreed on the approach.

Sample conversations

I put together sample conversations so the customer could get a feel for the overall experience. This allows the customer to see how their business rules would be implemented. This also gave us a chance to verify that the back-end variables were mapping to the right fields.

View fullsize

Complete the specification

Now that the customer liked the samples, the detailed specification could be written. While writing, I worked closely with the development team to ensure back-end accuracy, and with the QA team to ensure that all the use cases would be covered. The resulting documentation, including all the error handling and global behavior, was handed off to the development team.

Deployment

Because of the close communication between design and development, the project deployed without any major defects. The SIT and UAT passed without any problems. The first round of metrics showed that the containment rate doubled, reducing their call center expenses by several million dollars in the first year alone.