I was part of a team that was designing and implementing a ticketing system that would replace the existing system to track changes in a manufacturing process. The users did not have an effective way to search their tickets in the system they were currently using, so I implemented a search feature to help improve their workflow.
When I joined this team and was introduced to the tool that was being created, I quickly realized the task at hand was a far greater challenge than it first appeared. The team was designing a replacement tool for an application that had been in use since 2000. This application takes changes on the product that we build and tracks them throughout their different stages in the process. In a broad sense, you could think of this as to-do, doing, and complete as steps in this process.
Prior to my joining the team, they found that this naturally led to a Kanban-style tool that would track tickets throughout the system.
At the point in which I joined the team, the need had arisen for the user to be able to search among all of the tickets in the system. The dashboards would quickly become cluttered with cards as there were constant tickets being submitted into the system.
I took the lead on creating the first search function for the application.
I started the process by creating a script to ask the users of our application how they would use the search function. I observed them in their current jobs using the legacy application. I documented what types of things they searched for, the times when they needed to search for something and their pain points with the current tool.
I then began relentlessly researching the best practices on this feature. I looked at e-commerce websites like Amazon and Target. I closely scrutinized Google’s main search functions by diving into how they approach advanced search. I read articles on Medium and searched Dribbble (observing their features along the way) for inspiration.
I started to realize that search was a pretty commonly recognized feature and that we could probably just follow the standards in the industry.
After exhausting the internet of all content related to designing search, I needed to determine the best way to approach this for our users. The way their current application works is that they know the field or fields they need to search for and they find it on a massive list of those options and fill in what they need. While observing their interactions I noticed that, even with years of experience using this tool, they spent precious time scanning the screen for the field they needed. This is where I saw the biggest opportunity for change.
My first idea was to give them the moon and allow them to search for any information on any field that was listed on any ticket. This would function like Google. At this point, I began to look more deeply at the personas that would be using our application. They are blue-collar workers, don’t go home and spend tons of time on a computer, probably only log in to their computers to use this tool and sign their time and in general just weren’t as computer-savvy as an IT professional would be. I decided this approach would be too disruptive to their current workflow as the endless possibilities would actually take them longer to know what to search for. By looking for ways to improve on their current process without completely overhauling it, we would be much less disruptive to their current jobs and see greater success.
After some conversations about feasibility with the developers and product manager, I decided that we could use this as a future improvement.
This conversation led to a design studio with the team and what emerged from there were two distinct options: A - giving them a layout similar to what they already had in displaying all fields at once or B - giving them the ability to select the fields they needed from a dropdown. Option A was an attempt to give them essentially the same thing they already had to be less disruptive while Option B was seen as our assumption on how we could speed up their process.
I hypothesized that our users would see Option B as too confusing and Option A would be the best option for now. However, I was convinced that Option B was the more efficient way so I did not want to give up on it. We settled on some A-B testing.
From here, the fun began. I got to create TWO prototypes.
I used the knowledge I gathered earlier from the industry to place the search bar in the upper righthand corner. This was true for both Option A and Option B. I then set up each prototype and we scheduled interviews alternating A and B.
I got through about 10 interviews and began to notice some trends:
1. Option B was FAR EXCEEDING our expectations for it. Users were locating the fields they needed much faster than they were in Option A. They were also not struggling with the new way of thinking about search. This was a huge win for me as I hoped focusing just on what they need would be far more efficient for them.
2. Unfortunately, an unforeseen problem popped up: less than half the users were able to find the search bar without help from us. I needed to rethink how we were approaching this.
I was particularly humbled each time the user could not see the beautiful search bar I had painstakingly crafted. I did so much research that I was not ready to admit defeat.
I needed to empathize with our users. What was I missing? Do they just not understand? Surely if they knew how much time I spent on this they would feel bad, right? Right?!
After a giant slice of humble pie, I began a dialogue with my co-designer on how we could fix this. The biggest problem was that they simply could not see it. Whether it was too grey or they did not know that a bar with a magnifying glass would allow them to search, I did not know. But I did know that I needed to alter the design.
I looked back at our user testing sessions and noticed that the majority of users, like most people, were reading the page in a Z pattern like we expected them to. When they got to the right-hand side, they just would breeze past the search bar, even if their mouse was sitting on top of it. When I asked them to try and search for a ticket, I noticed they just wanted to look in the top left. For whatever reason this is where they expected the ability to search.
In an effort to make it more noticeable, I switched the bar to a button and changed it to our primary color to make it stand out more. This was a very simple change that came directly from observing the users.
It turned out to be a great change as from then on out not a single user had issues finding that search button.
The application is still being developed but I have moved to a new team. Our search feature utilizing Option B and the repositioned Search Button was implemented shortly after I left and the users are responding positively to it.
This simple victory taught me a gigantic lesson that was not real to me until it directly happened: if I design a tool for myself, it will not be effective for the users.
I love to make things look beautiful, its part of my mantra. But if that comes at the expense of the users, I’ve failed.