Context
At Slavic401k, many functions in the current product use filters to let users screen out the data they need. It maximized the flexibility of the database to fulfill different user needs and let users know what they can control and how we categorize the information.
Problems
The filter is a valuable element. However, when more and more products are built, the UI becomes more complicated and inconsistent across different functions. It created confusion and difficulties to follow for both designers and front-end developers.
Outcomes
All filters were divided into five groups by the number of categories and whether they contained single-selection or multiple selections. Later, I standardized the design style and created a design guideline in considering various scenarios and responsive design.
Problems
Slavic401k's core business is to support PEOs, employers, and participants to manage their 401k assets. Many functions require a filter to help users narrow down the number of displayed items to complete their tasks. However, when more functions were built in the past year, we ran into some issues. I approached it by understanding the problems and limitations.
Understand problems
- Understand every project and the purpose of each filter
- Understand the original reasons for every design decision of various filters
Limitations
- Follow the original design style
- The new design can still assist users in completing their tasks (Otherwise, we need to maintain two sets of filters for different products)
What are the problems?
After my research, the filter had two main problems.
- Inconsistent UI
- Different interactions for the same task
Inconsistent UI
#1: Title style
Type 1: Center aligned without icon
- Older design
- Less content, no description
Type 2: Left aligned with icon
- New design
- More content with description for more complex scenarios
#2: Filter button type
Type 1: Dropdown
- When to use: one category, single select
- Default state: Display the category e.g., All Distribution types
- Active state: Display the option e.g., Hardship
Type 2: Button - multi-select
- When to use: one category, multi-select
- Default state: Display the filter title e.g., Select category
- Active state: brief description e.g., 2 distribution types
- The icons used here vary without consistency
Type 3: Button - multiple categories
- When to use: multiple categories
- Default state: Display the filter title e.g., Select date (the left one in the picture)
- Active state: Filtered with close icon (conveniently reset) (the right one in the picture)
Type 4: Multiple filters in responsive design
- Separate from other filters on larger screen resolutions
- Combine with other filters when lack of space
Different Interaction
#1: Clear All
Type 2: Multiple categories
- Has multi-select → has button
- Only has single select → no button
#2: Toggle
When to use: Has multiple categories and has both single- and multi-select in one modal. There are two ways to display the default (no filter applied) for single-select. The result will be the same as ‘Apply All.’
Type 1: Provide an ‘All’ option
- But it would be inconsistent with the multi-select, in which ‘All’ is redundant because it is the same as selecting every option
Type 2: Use toggle
- Meet both requirements, consistency and displaying default (toggle off)
But we don’t use toggle in other cases because it’s inconvenient and unnecessary. Instead, we use All when it only has one filter, and it is single select.
#3: "All" option on single selection only
Inefficient Scanning on Mobile
- In order to save space, we stacked options horizontally and also used an outlined style to divide options.
- The horizontal alignment is not friendly for scanning, especially on mobile
Goal
Design Goals
#1: Unify the UI pattern across different functions
Create consistent branding, look and feel, and experience
#2: Standardize the interaction
Help users learn the system faster and build muscle memory
#3: Design for efficient scanning
Be consistent with the layout and position of options on the modal
Business Goals
#1: Scalability
After standardizing the filter UI and creating an interaction guideline, frontend developers can create a reusable component to save more time.
#2: Communication efficiency
The design team won't spend extra time explaining the interaction rules every time with the frontend team and QA team.
Solve Problems
Create a rule that can apply to various filters in the existing products and also for future products. Therefore, the rule must be clear and easy to follow and can cover every scenario and consider every case.
Categorize Filters
After understanding the UI differences and design decisions, I realized we changed the design when the structure changed. For example, when the filter contains both single and multiple selections, we use the filter button outside and use the toggle inside. It is different when the filter only has single selections. Therefore, I categorize the filters by the combination of two criteria.
- One/ multiple categories
- Single/ multiple selections
Combinations include
- One category - single selection
- One category - multi-selection
- Multiple categories - all single selections
- Multiple categories - all multi-selections
- Multiple categories - both
Inconsistent UI
#1: Title style
I am making them consistent. Currently, two styles are used. I decided to go for type 2.
Type 1: Without icon, center aligned
Pros
- Providing more vertical space for content (but not a pro when the screen is scrollable)
- The title refers to the whole dialog, so it is reasonable to align the center
Cons
- Create confusion with other modals. When the content is read only or don't have many action buttons, such as terms and regulations, we usually use this style.
Type 2: With icon, left aligned
Pros
- Convenient for users' scanning
- Visually prominent on heavy content with description or more action buttons
- More product filters are currently using this style, so we can save more time for front-end developers
#2: Filter Button
Final decision: Make the style of a single category the same as multiple categories, and also update the multiple categories style.
Single category: Change dropdown into button style
Pros
- consistent with the multiple categories style
Multiple categories: Remove the function of “X” used to reset a filter
- The original design is convenient for users to reset the filter. However, this design causes confusion to users since a button usually has only one action. Thus, we decide to compromise a little bit on the inconvenience.
Color
- Create a new button with an outline in blue, our system's primary color. It provides feedback that the filter is currently applied.
#3: Different Interaction
Final decision: Make the style of a single category the same as multiple categories, and also update the multiple categories style.
Single category: Change dropdown into button style
Pros
- consistent with the multiple categories style
Multiple categories: Remove the function of “X” used to reset a filter
- The original design is convenient for users to reset the filter. However, this design causes confusion to users since a button usually has only one action. Thus, we decide to compromise a little bit on the inconvenience.
Color
- Create a new button with an outline in blue, our system's primary color. It provides feedback that the filter is currently applied.
Different Interaction
Shortcomings of current solution
- Although users can understand how the filter works, users will be confused seeing too many versions of interactions.
- The rule is too complicated to follow for other designers
- It is difficult for front-end developers to create components
Goal: Keep the interaction rule clear and simple and make them consistent
Considerations
Based on the decision reasons made by the team before, obviously, the timings of using those three elements below affect each other.
- The "All" option on single selection
- Toggle
- "Clear all" button
There are two ways to make the filter in different cases simple and consistent
Method 1: Keep toggles and the Clear All button. Don't use the All option for a single selection
Pros
- The Clear All button is used to reset the filter and not apply anything. Toggles can literally "close" the filter, which makes the Clear All button more sense to users.
- Disclosure information step by step that users will only see the category titles and toggles at first glance.
Cons
- Users need to open the toggle to know what options they have, even in one single select or one multi-select.
- Inconvenient to users in collecting information. Eyes need to move from left (category title) to the right (toggle) and back to left (options).
Method 2: Don't use toggles, but keep the Clear all button and All option for single selection
Pros
- Decrease users' mental workload. Users don't need to understand the interaction of toggles. They only need to process titles and options.
- It is convenient for users to read and scan because their eyes don't need to move from left to right and back to left (from title to toggle and to options).
- Users can directly see options that entirely understand what configurations they have.
Cons
- Might be a little bit confused after users hit Clear all and see the single select still remains in the All option. However, this may not be difficult to understand since when they first enter the filter, the default is All.
Decision
After discussing with the product team, we all agreed to go for the second solution, which can provide a better experience on every filter use case (see the section of Categorize Filters).
However, since in some rare cases, the default option of single select is not All, the word Clear all may be confusing, I proposed
- Use "Reset to default"
- Use "Clear all" but add "default" on the option if the default is not All option.
But we finally decided to maintain Clear all to keep it simple. We will change it if users have difficulties in using it after launch.
1) One category - Single selection.
2) One category - Multiple selections, style 1.
One category - Multiple selections, style 2.
Two or more categories (filters).
Responsive Design - Combine filter buttons
Final Decision
Responsive design of filter buttons.
We can combine multiple filters or keep them separated on smaller screens. We selected combine for the following reasons.
Combine
Pros
- Save more space and fewer action buttons
- The modal view after opening the combined filter makes it easier for users to scan
Separate
Pros
- Can see all filters without hiding any
- Better for complicated filters that are hard to combine with others (but we don’t have this use case for now).
Cons
- Users couldn't expect how many filters they can control because some tabs are off-screen.
- The thumb needs to move up (to scroll tabs) and down.
Inefficient Scanning on Mobile
In the current design, we stacked options horizontally because we wanted to save space. However, saving space is not the top priority, especially when users can scroll on their mobile. Therefore, I stacked options vertically for two benefits.
- Easier for users to read and scan filters because they all align left.
- The radio buttons and checkboxes are also aligned left, which makes it easier for users to do actions.
When there are more than 6 options under one filter, I hide the rest of them to allow users to skip this filter if needed.
Learning
Periodically update design system but not too often
Adding or editing components based on new products’ needs is common. However, changing too often will create extra work for the frontend developers. Finding a balance is important, and ensuring every redesign covers all current scenarios and possible future use cases.
Design workshop + design review
I came up with some possible solutions and guidelines first and then discussed them with other designers to make sure we all agreed on the final solution. And then having a design review with the frontend team to ensure we are aligned before implementing.
