Filter and Search Reimagined
Overview
An OMS (operating management system) is an essential product used by businesses to manage their daily operations and make informed decisions. It helps streamline processes, increase efficiency, and reduce costs. MasonHub is a third-party logistics (3PL) SaaS company that focuses on optimizing order management and fulfillment for its clients.
The Filter and Search tool lets MasonHub's staff and clients locate orders, fulfillments, and shipments through the Orders and Shipments page in real-time. At its core, this project is about redesigning the current orders and shipments experience so that users can locate their past and existing orders and shipments easily and fast.
My Role
As the sole designer, I led the design of the order and shipment experience and collaborated with the product manager and the head of product on the Filter and Search experience. The team and I also focused on reimagining how the data would display in the search results section.
The redesigned experience was launched in July 2022.
The Goal
The goal for this project was to redesign the current orders and shipments page to a user-friendly orders and shipments locating tool located in the OMS. This would benefit the users as they would be able to easily filter and search for any order or shipment on any day. In turn, this would help the company to better manage its operations and as result improve its bottom line.
MasonHub prefers to take the iterative approach (agile) when it comes to tackling products like the Orders and Shipments page. It was very important to differentiate between the user's needs and wants and the business's needs and wants when thinking through the MVP of this project.
The Challenge
The existing user interface was not suited for our heavy users (those that use it daily). Many users even admitted they had no previous knowledge of built-in features like saving the search in their browser even existed.
This project was a 3 step process:
- Redesign the user experience to a more user-centric experience
- Have the front-end (FE) system converted to React
- Company was scaling at this point and moving over to elastic search
This was my first project with MasonHub therefore a design system hasn't been established yet. My team and I had to reimagine the end product as a whole. This meant, we had to improve the search tool and ensure the way the result data displayed was clear and also take into account the future of filtering and searching on many MasonHubs other products.
UX/UI Goals
Account managers with complex search criteria need to search for a large amount of information in the order list. However, users with simpler data models do not need all of the search and filter options displayed on the orders page. For those users, specific search and filter functionalities are more relevant.
By decluttering the page and making it more customizable we can accommodate those two different usage patterns. This allows account managers and data-heavy users to filter and search for complex search criteria while displaying only what's relevant to our average users.
Discovery
At the very start of the discovery work it was clear that this page wasn't very user friendly and improvements should be made.
Some pain points discovered during my early findings included:
- Hierarchy was very poor
- Redundant information
- There was no design framework
- Many results were very unclear
- Pagination was poorly executed
- There were red alerts but the meaning was unclear
- Some search fields were larger than others
- For the most part, colors weren't used for representation or indication
User Research
To begin the project, we conducted user research to understand the needs and pain points of the company's employees. We conducted interviews with employees from various departments, including account management, sales, and operations. We also observed employees at work to understand how they currently managed their tasks and identified areas of inefficiency.
When conducting user testing on our end-users, we noticed that the end-users rarely used more than one filter criteria and only used this page to search for specific orders using specific search criteria unique to their roles.
While observing and interviewing our users we were able to discover that users memorized how to use this tool and they would get frustrated if a feature was changed or added.
A few other observations made were:
- The results were hard to understand so users would export results to find data in excel spreadsheets
- There wasn't a search result count and existing pagination just led to more confusion as our end-users couldn't tell how many pages there were
- Search fields didn't have drop downs or clear indicators that there was a selection of data. In result the end-users had to click into the field to learn that it's a drop-down with many options to select from
- Users would accidentally click on the reset button instead of the search button and were forced to restart their search again
Design
After several iterations of rapid sketching, we had a good idea of where to start to refine and expand on our design process.
Low-fidelity
Drawing up the wireframes helped us realize that some of the fields can be concatenated (merged) to eliminate unnecessary search fields or combine similar search fields. There is always a fine line between what should and what should not be concatenated so we had to keep that in mind.
That said, we focused on simplifying the user interface and concatenated/eliminated fields that made sense. We backed up our theories by interviewing heavy product users and researching existing use case data.
I was surprised to find the number of fields that could be concatenated as the use case was an "either/or" search and not an "and".
Iteration
The team met often during the iteration process. In the image above, the team discussed elastic search and the affect it can have on our search and data sorting systems. This is where I also presented the first iteration of the high-fidelity design to the team (Head of Product, Director of Engineering, OMS Product Manager, and WMS Product Manager).
High-fidelity
The most important change we introduced involved completely removing all the search fields except for one. The user has the ability to add more search fields as needed. Since the majority of our users come to this product to find a specific order, searching by order ID or fulfillment ID, the decision was to let them do just that.
By default, the order ID and fulfillment ID search are selected when users come to the orders and shipments section. The remaining search options are alphabetically sorted.
We took away all the fluff, which in return allowed the users breathing room due to the simplicity of the new experience and the new interface. Users can find orders without even having to think or look for the correct search fields.
What about the heavy users?
We gave our heavy users full freedom to customize their search. End-users now have the ability to search or filter by any criteria they need.
We gave them the freedom to add additional filter/search criteria.
Too many filter/search criteria added? Well, we also gave users the ability to delete the extras without having to reset or restart their search. The trash icon is hidden if there is only one search row left on the interface.
Users now have the ability to search by date or by a range of dates.
When filter/search criteria has multiple options, they are displayed in a "pill" form for clarity and a way for users to easily delete them as needed.
What about displaying the results?
When thinking through the table and the data shown, it was a lot of data with no easy way to read it. To make it easier for our end-users to understand - we broke down the search/filter results into 3 sections:
- Orders
- Fulfillments
- Shipments
Since the fulfillment and shipment results are secondary information our users come to this page for, we made those results collapsible with only the most important data showing - the status for each of those categories.
To further separate those categories, we made a horizontal line break in between each category in our UI so it's easier for users to read and separate.
We made the status easier to read and understand by writing out the status code next to a color indicator.
The pagination now displays the sum of search/filter results produced. Users can now add additional rows as well which in result improved the experience and made it easier to understand.
MVP
As much as we would have wanted to have everything shipped for development, that was not the case. We decided that the “save search feature” and “column sorting feature” should come at a later iteration, post MVP due to the low use-case.
We had ideated on potentially giving users an option to lock columns when they scroll horizontally, but the stakeholders decided that was unnecessary at this point.
Validating the design
We then created prototypes to test the functionality and usability of the product using maze. We conducted usability testing with employees from different departments and a handful of selected MasonHub clients to gather feedback and make any necessary improvements.
The tests were quantitative, we looked for the length of time it took users to figure out the product and looked at heat maps to see where users may have gotten stuck. The issue that we kept seeing the most from the heat maps was the users were stuck in the top tabs between all results and backorder results.
So to solve this issue, we removed the backorders tab from the screen altogether and added it to the search options under status since this wasn't something that was used a lot. This gave users the flexibility to filter and search through backorders, and because the product allows users to add as many filter criteria as they needed, users did not lose any functionality.
Another observation we made was that some users found it hard to locate the "add filter" button, so we changed the color of that button from grey to the MasonHub brand green and we also increased the size of the button. That resolved the issue.
After several rounds of testing and iteration, we arrived at a final design that met the needs of the company and was easy to understand and use for employees and a selected few of MasonHubs clients. It was then shipped out for development!
Outcome
After launching the beta mode with the internal team and a few selected clients we observed an issue. When we concatenated the address field, we learned that a few of our users have no way to differentiate California the state, California the street, and Baja California for example.
We quickly redesigned (un-concatenated) the address fields and released the design in our next update. Luckily this wasn't a heavy use case for us but regardless it was a good learning experience. This is why the iterative process is good and issues can be fixed fast.
Conclusion
The search and filter designed for the orders and shipments page greatly improved operations and decreased searching time.
By conducting user research, designing a user-friendly interface, and testing with employees, we were able to create a product that met the needs of the company and was easy for MasonHub and more importantly their clients to use.
The new search and filter experience helped the company to increase efficiency, and reduce costs, resulting in a better bottom line and increased customer satisfaction.
