Any professor using our product began by creating a course, which itself began with textbook selection. Finding your textbook was a matter of selecting a subject from a dropdown menu that included over 300 options and then browsing through titles only six books at a time. It was needlessly time consuming and error prone.
Business Problem: The sales and customer support team were spending valuable time helping customers identify the correct textbook and, in a process that was even more time-consuming for them, correcting courses that had been set up with the wrong textbook. The problem was acute enough that it made an appearance in the list of top customer service issues and had been identified for mitigation.
Business Product Manager
Technical Product Manager
Quality Assurance Lead
UX and Visual Designer
Prototype for testing
This was a project where the solution was obvious: implement a search. Our main challenge followed: in a world where people expect search to work like Google, how do we use our limited resources to develop a search function that didn't disappoint?
I worked closely with a Business Product Manager, who represented the business stakeholders and had an understanding of the business landscape. I had my own bank of information built up from previous usability tests and interviews with professors. The scope of this project, as well as the close focus on search, led us to plan immediate design work, relying on best search design practices, and then check in with users once we had some wireframes—I thought of it as a hypotheses for a design solution that we would test.
Designing the interface for a search is relatively straightforward, since conventions for it are well established. I was able to design wireframes quickly and present them to the group.
Wireframes in hand, we went to our customer-facing colleagues—from the customer service, media operations, sales, and implementation groups—and to professors. The search was a welcome approach, and the interface was clear.
We moved on to discussing the implications of implementation. Lacking time and resources to install a packaged search, we wouldn’t be able to offer many of the search behaviors that internet users expect as a matter of course, like predictive searching or spell-correcting. On the other hand, we were working with a relatively small data set—only a few thousand titles—that was well structured and clean. In our case, the goal of the search was well-defined and served one purpose: finding a textbook. We therefore decided it was safe from a user experience standpoint to build our own search according to our own business rules. I found and consulted with a search and metadata specialist from another division of the company to help identify any "gotchas."
I revised the wireframes with input from the various conversations and added annotations, which would capture all the business rules we defined around the search.
Finally, I moved onto the visual designs, which was a matter of applying existing styles to the wireframes, filling in a few gaps.
I handed off the annotated wireframes and designs, and then was available to answer questions and to participate in design QA with an offshore development team.
This project was a rare opportunity at our company to make a meaningful usability improvement to a major flow in our application. It was also a hands-on opportunity for me to steer my colleagues through the particular questions that search raises for the user experience. In the end, we were able to work around the technical limitations to make a substantial improvement for customers. The customer service issues surrounding the textbook selection began to abate and the agents could spend their time on other issues.Next Project ›
Based in New York City