Nutrition Ranking Tool
Exploration of data table designs with filters for multiple criteria.
This project was a deep dive into providing filters on complex data tables. Although the scope of the project was limited to redesigning this specific tool, the table design and filter behavior pioneered here were added to larger MFD design system.
The nutrition ranking tool consists of two different landing pages that provide similar, but not exactly the same, information. Together they have a high volume of traffic with a very high 86% drop off rate. Users frequently skim through the data provided and leave the site. After diving deeper into the problem space, we defined the following challenges to tackle with a new design for this tool:
How might we filter for multiple criteria while keeping the tool usable?
How might we make it easier for users to compare nutrient data across searches?
How might we provide qualitative details about entries that may serve as a larger on-ramp to the rest of the site?
DATA TABLE & FILTERING FOR MULTIPLE CRITERIA
Challenge: The current design has two pages that filter respectively for one and two nutrients. This not only limits the number of nutrients to filter to a maximum of two, but it is more challenging to discover the presence of the other page. We wanted to expand the tool to an arbitrary number of nutrient filters while also making it simpler for users to analyze foods.
Solution: Single, filterable, data table
The current design shows the search results as a list of cards, making it difficult for comparisons between nutrient values. By moving to a table format, we help users view and compare nutrient information in a desktop-purposed format.
To accommodate both sorting and filtering functionality, the new design distinguishes between two different filter criteria: nutrients and metadata (e.g. serving size, data source). The nutrient criteria is differentiated since arbitrary numbers of filters can be added there, which changes the structure of the output table. The metadata criteria act purely as filters which do not change the structure of the table.
The default table sort is based on a composite score we created specifically for sorting foods based on how well they match each individual criterion selected.
SECONDARY VIEW WITH HOVER STATE
Challenge: Data table interfaces are naturally very dense, so we wanted to avoid overcharging the UI with buttons and other elements.
Solution: Hover interactions for desktop
We opportunistically display the right interactions only as necessary. These hover actions allow users to view detailed nutrition data on individual food items on the sidebar, and multi-select items and perform bulk actions.
View detail nutrition data
Challenge: Tables are difficult to view on mobile, and require different sets of design elements to reflect the specific user intent.
Solution: Scrollable, easily filterable table view
The mobile experience of a data table is suboptimal, but since mobile access to this specific page seems to indicate a quick look-up intent, we concluded that the benefit of providing a passable mobile experience outweighed trying to completely redesign the experience between platforms.
Viewing data table on mobile
Viewing nutrition details
Our next steps include:
Designing for different states (error, no result, etc)
Designing the flow to the Comparison tool and other pages
1. Tradeoffs for table and filter designs
This project was a great opportunity to explore the tradeoffs made by using table views - especially when compared to lists. In depth exploration of filter options has also yielded insights into analytics dashboard designs prevalent in common tools elsewhere. This ended up being very enjoyable - looking at artifacts that I am used to interacting with as a user from a design perspective.
2. Using states to improve usability
As data tables are information dense, I explored using different states to display the right interactions as they are needed. The limitation here is the additional cost of a widely divergent mobile design.