Acquia Content Hub is a B2B product that allows users to syndicate content across different websites. Filtering is used to create rules for which content is routed to which sites. These rules are the foundation for the function of this product. Users generally don't do ad hoc filtering like with e-commerce, but create and manage long-lived filters to ensure the proper distribution of content across mutltiple, sometimes many, sites.
The existing UI was limited in function, unintuitive to use, and didn't work well with hundreds of sites. (Examples shown in the following legacy screen shots.) We needed to design an interface to allow both technical and non-technical users to find specific content and configure rules for where to syndicate it. Previous user research from the product owner and product manger provided the following criteria the following criteria:
easy to manage filter facets
clear which facets are currently applied
clear which sites the filter applies to
scales with hundreds of sites
Use the existing design system as much as possible to improve consistency and accessibility. (The existing system did not use the design system at all.)
Content editors, business managers
The UI worked for more technical roles like developers, but it was hard to navigate for non-technical users like content editors and those with more business-oriented goals. Many people don't interact with filters on a regular basis, so even if they figure it out once, they might forget and have to learn the next time they come in months later.
Lead/solo designer
I took over from a team member who left the company after generating some moderately-developed designs. Having no prior experience with the product and without transition from the other designer, I familiarized myself with the product space and design by working closely with the product owner and product manager.
In this project, filter values determine which content is selected, and "assigned sites" refers to which sites will receive this content.
Click images to enlarge.
Default view
Selecting filter values
Editing assigned sites in sidebar
There was no hand-off with the previous designer about his work to understand his direction for the designs, but discussions with the rest of the team led me to make substantial changes to the designs he left in order to accomplish:
better consistency within our systems
better consistency with other products
simplify the users' mental model
Since this was a redesign of an existing feature, it was important to balance the improvements with keeping certain terminology and frameworks in place so as not to frustrate current users.
Click images to enlarge.
Default view
Filter values selection
Editing filter name and assigned sites
After the first round of design was complete, I ran user tests, having them perform several primary functions of the filtering feature. Based on the following primary questions, I drafted a script for testing and reviewed it with our UX researcher and product manager.
Can users easily find and open filter settings?
Do users understand how to preview and save filters?
Can users easily edit assigned sites in a filter?
Unmoderated
With well-developed designs and clear questions, unmoderated testing was sufficient to provide the information we needed.
Playbook UX
The tool Acquia uses for unmoderated testing.
5 testers
A common number of testers for this sort of testing, and the standard used by Acquia.
Not current users of the system
Since one of the goals was to make it a familiar experience compared to other filtering systems on the web, we determined that testing with general users would provide valid usability data.
Once testing was complete, I brought the data into Dovetail for review and synthesis. There, I highlighted key insights from each user and summarized the key points to take into refining the design. These summaries were grouped by categories of navigation, saving, and other.
An example of the summarized key points for navigation together with some accompanying tester highlights.
Interations
As is typical, testing revealed that some tweaks were needed, but we generally had a solid solution. Here are some examples of changes made after testing:
No surprise here since it demonstrates the WCAG success criterion. Fields need labels.
This one was a little surprising. I expected it to be more clear to users than it proved to be.
I definitely understood the lack of certainty users had in this area. It was a tricky part of the design to work around the various possible states while maintaining a clean and consistent UI.
I waffled on this interaction a bit before user testing, but user input laid my questions to rest and made the expected behaviour clear. Indeed, this is why we test.
At this point, I reviewed and confirmed the final designs with Product, provided detailed documentation for engineers, and shared the final designs with the engineering team where they await implementation.
Default view
Simplified to all things related to filtering in the sidebar, accessible from the single button.
Made the Filter button primary, as that's the most common action from this view.
Unsaved filter applied
All filter values are displayed as consistent tags in one place.
Saving as a new filter can be done from this view.
Viewing saved filter values
Permanent label on saved filters dropdown.
Overview of selected filter values.
Clear options to save or preview without saving.
Editing name and assigned sites
More standard checkbox selection for assigned sites to scale with many sites.
Documentation
Example of detailed documentation for engineers, including:
visual specs
behaviours/interactions
states
Click images to enlarge.
Default view
Selecting filter values
Filter applied
Since the main problem to solve was one of user experience, the ideal metric would of course be qualitative data from users regarding their ability to use and satisfaction with the redesigned filtering feature. However, since it's not always feasible to gather that sort of data a more passive and quantitative metric could be the percentage of users who execute and/or save filters. Since it was challenging for non-technical roles to use, they often requested the work be done by more technically-savvy roles. If we see a higher percentage of users engaging with the feature, that suggests more roles are able to use it.
Based on the "Additional Goal" section for the project of increased usage of the design system, two other success metrics could include increased accessibility after the redesign and a decrease in the amount of code that's not using shared components. With the adoption of the design system, we expect a significant decrease in both accessibility violations (i.e. much better accessibility) and unique front-end code for the project.