Most (great) product features come from a deep understanding of customers’ problems. It’s tempting to build every “good” or “obvious” feature someone can describe passionately but that leads to thoughtless bloat that breaks the UX. And most things people describe as “obvious” actually have 10,000 questions between the comment and a well researched/tested feature.
Sometimes the stars align and a conversation with an insightful person includes an offhanded “wouldn’t it be neat” comment that’s small enough to quickly prototype and test. And those are just the circumstances that led to this experiment: Module Filters.
Behold! Content filters!
The comment, which was part of a much larger conversation on organization and navigation, was
“Wouldn’t it be neat if you could filter by content type right on the Modules page in Canvas?”
This project was a good candidate for me to experiment with because it’s
- small in scope
- technically possible
- UI/UX not immediately obvious
Small in Scope
Small changes a person/team can wrap their hands all the way around are ideal for quality, and ensuring it actually addresses the problem. Feature creep is very real though, and I had to repeatedly slap my own hand and say “No! That’s not part of what is being tested here!” Keeping things in scope is tough in the face of the endless waterfall of “wouldn’t it be neat if it also…”
This is where the bulk of the work (and my excitement for the idea) went. “Filters” in apps don’t have a universal UI: sometimes they’re checkboxes, or a dropdown menu, or toggles, or happen automatically while typing, etc. None of those is right or wrong, and it depends on the situation which direction one might lean. My first version actually uses unstyled checkboxes with labels (which looked awful) just to make sure my code worked. Thinking about the UI/UX also helped me with feature creep in that the UI for a filter like content works well as checkboxes because a user might want any number of filter combinations on/off, but they wouldn’t work well to toggle a single binary state like “has due date”, for example. One might even want different types of filter simultaneously which requires a lot of additional considerations.
Ultimately I settled on an on/off toggle using the corresponding content icon instead of a checkbox with a label to support any combination of content types to be shown/hidden, and to avoid adding text to the app UI. Keeping the filters to just content type made the UI more approachable and let me focus on the UX of how it might be to actually use this feature.