Our client, a transportation provider, wanted to improve their customer experience by updating their travel reservation system for both customers and employees. My team focused on improving the employee experience.
In redesigning the employee-facing travel reservation system, we need a team that can:
- Help employees understand who the customers are
- Reduce training time needed for employees to use the system
- Create an experience consistent with customer-facing channels
Timeline: 1.5 years, May 2015 – December 2016
Sprints: 25 3-week sprints
Lead UX Designer
I was the Lead UX Designer for the employee-facing portion of the project. My days consisted of three main activities: designing, leading, and managing. I led a team of 3 UX designers with an eye toward consistency. I tracked down answers to questions we had, planned our design sprints, and kept in touch with the customer-facing UX team to ensure that we were designing a consistent experience. I also was responsible for designing and owning my own features. I worked with FE engineers and visual designers to provide visual and UX QA to ensure that the UX visions were being realized.
This project was ambitious, complex and challenging. We faced a number of huge challenges:
The current system used by employees is a text-based Windows application. Employees learn codes and keyboard shortcuts, enter those codes and shortcuts into the system, and receive text-based responses in a window. It takes employees 6 months to learn how to use the system, but they love it. Many of them are veterans at the organization and are experts at what they do. Despite the steep learning curve, these employees are extremely fast at using the system.
We needed to be able to reduce training time, make sense of all of the codes, and have a system that allowed the employees to still quickly perform their duties.
Digging into what the application should be and what the bounds of our design task was was an interesting process. Just when you thought you knew what you needed to know, you uncovered a whole new set of information that needed to be accounted for. This happened many times and kept us on our toes. Our client’s business is very complex and it’s complexity became very clear once you started to scratch away the surface. This made tackling design challenging, since so many different variables needed to be considered.
A 3-month period of discovery research was conducted before I rolled on the project. During that period, designers and product managers interviewed customers, employees and stakeholders. They traveled around the country to understand how the organization worked and their key pain points. The results of this effort were user goals, journey maps, and personas that the design team would leverage to reimagine the customer experience.
We were dealing with a system that had a lot of overlapping things. An employee’s ability to see a lot of information at once was really important. We didn’t call it that at the time, but we used an object-oriented approach to designing the system. We had customers, reservations, schedules, and so on. Each of these related to the other. Each of these objects also had a number of sub-objects, like credit cards, vouchers, and other things. One of our first actions in rolling onto the project was to figure out what the object ecosystem looked like. We got out stickies and created a document that we would be able to reference throughout the design process.
We had customers, reservations, schedules, and so on. Each of these related to the other. Each of these objects also had a number of sub-objects, like credit cards, vouchers, and other things. One of our first actions in rolling onto the project was to figure out what the object ecosystem looked like. We got out stickies and created a document that we would be able to reference throughout the design process.
Employees needed to be able to do a number of the things with the tool. We took the use goals and the user journeys that were developed during the discovery period and mapped different tasks that we knew would need to be accomplished with the system to the journey. This helped us to visualize what we were going to be building. Consistency is key in our system. We wanted to use repeatable patterns that employees would come to expect. One they know how to move forward with one task, they should know how to move forward with the next task. Our application is designed so that repeatable elements can be used throughout. Modules fit in pages and pages fit in flows. Different combinations of modules
Tasks Mapped to Journey
Pages, Modules & Flows
Employees needed to be able to do a number of the things with the tool. We took the use goals and the user journeys that were developed during the discovery period and mapped different tasks that we knew would need to be accomplished with the system to the journey. This helped us to visualize what we were going to be building.
Consistency is key in our system. We wanted to use repeatable patterns that employees would come to expect. One they know how to move forward with one task, they should know how to move forward with the next task. Our application is designed so that repeatable elements can be used throughout. Modules fit in pages and pages fit in flows. Different combinations of modules
We mostly worked in Axure to develop our wireframes. In addition to the interactive prototype wireframes, we relied on a couple of tools to communicate our designs to developers and stakeholders.
For a number of pages and sections in the application, a number of different variables determined what would need to display on the page. In order to account for all of the variations that could exist, we developed framework pages that broke down the page by element. For each element, we identified the various states that could exist and the conditions for when those states would exist. These framework pages would then be consumed by the development team to ensure that all states and logic in the interface were accounted for.
The prototype for our application ended up exceeding 300 pages! Each page packed a lot of detail and we often needed to represent the same page multiple times to account for different variations. In order to show the bird’s eye view of the application, we developed wireflows to show how each page related to the others. Our wireflows consisted of mini wireframes that depicted the high level details of the page. We then used arrows and other indicators to show how the different components lead to other pages.
Usability Testing for Expert Users
One of the most rewarding aspect of the project was being able to conduct usability testing with current employees.
We conducted 6 rounds of testing in 6 months between July 2015 – April 2016.
We conducted testing in contact centers and physical locations across the country.
We had over 50 employee testing participants with a couple of repeat testers.
Tailoring Our Approach
One of the most interesting things about conducting usability testing was that we weren’t testing with what would become casual users. We were testing with people who were going to be experts in the system. Since we were testing people who would be experts, we were not as concerned about people being able to use the application immediately. Instead, we were more interested in figuring out if the application fit with the employees’ mental model and whether it was something that would make sense once someone has been trained.
We experimented during one session with introducing “fast track training” with a couple of participants to see if we were able to see any differences and gain additional insights by providing training prior to conducting the session. We felt this allowed us to focus more on getting feedback about how the system worked rather having to answer questions.
Although we did encounter some resistance (which is expected) from some testing participants, we overall had good reviews. One of the most memorable participants spend about 10 minutes talking about how much they loved their current system and didn’t think that it needed to be improved before we were able to start our walkthrough. Once this participant saw what we were building, their tune changed entirely. They proclaimed “Oh my God. Oh my God. This is wonderful!”
It’s moments like those that really brighten your day as a designer!
The project is not live and is covered by an NDA, so it is difficult to share results here. In the end, we created a prototype that included over 300 pages. We developed a design system that will be able to be used for future products (see my other case study for additional details). We worked with stakeholders and employees to make sure that our designs met both business and employee needs. Once it goes live, I’m confident it will help solve some of the major issues that we set out to address.