Filter Groups - Building layered segmentation logic into Typeform's Contacts CRM
Me - (Product Designer)TL;DR
- Led design for Filter Groups in Contacts, Typeform's lightweight CRM experience
- Solved a messy interaction problem around grouping filters with AND/OR logic
- Worked across product, design, and engineering to make the logic clear and buildable
- Tested the pattern with 5 users from our saved lead-gen template group
- Helped shape a wider Contacts experience measured through contacts enriched, active automations, completion rate, and email engagement
Background
This project sat inside Contacts, Typeform's lightweight CRM feature. Filtering already existed and worked fine for simple cases, but the moment the team wanted proper segmentation, the flat list of filters fell apart. People needed a way to build more layered logic without the panel starting to look like a database query builder.
This was the original filter feature - you could add multiple filters but not filter groups. The code snippet on the right was what we planned to implement.
This was the original filter feature - you could add multiple filters but not filter groups. The code snippet on the right was what we planned to implement.
The challenge
Filter Groups sound simple on paper. The behaviour gets messy fast.
The job wasn't to drop in another UI element. I had to define what a group actually meant inside the product, how filters should behave inside a group versus between groups, and how much logical complexity was worth exposing at all.
On one side, product needed something powerful enough to support real segmentation. On the other, engineering was already shaping the filtering model and there were real constraints in the existing composer and panel structure. So the job wasn't just to make something look good - it was to define a filtering pattern that made sense conceptually and could actually be built, but was also familiar and simple to Typeform's users.
There was also an important scope boundary: we didn't want to go as far as nested groups. That would have made the whole thing much more technical, much harder to explain, and probably too heavy for where the product was at that stage.
The job wasn't to drop in another UI element. I had to define what a group actually meant inside the product, how filters should behave inside a group versus between groups, and how much logical complexity was worth exposing at all.
On one side, product needed something powerful enough to support real segmentation. On the other, engineering was already shaping the filtering model and there were real constraints in the existing composer and panel structure. So the job wasn't just to make something look good - it was to define a filtering pattern that made sense conceptually and could actually be built, but was also familiar and simple to Typeform's users.
There was also an important scope boundary: we didn't want to go as far as nested groups. That would have made the whole thing much more technical, much harder to explain, and probably too heavy for where the product was at that stage.
What I did
I worked on the logic before the visuals. I went through the existing filtering work with engineering, looked at how the wider structure was being shaped, and mapped where Filter Groups would add extra friction for users.
The first thing I worked through was how grouping should actually behave: benchmarking how other tools handled similar filtering logic, when a new group should be created, how it should relate to existing filters, and where AND/OR logic should live.
The first thing I worked through was how grouping should actually behave: benchmarking how other tools handled similar filtering logic, when a new group should be created, how it should relate to existing filters, and where AND/OR logic should live.
Some early benchmarking around the existing filtering logic
The AND/OR problem
The hardest part of this project wasn't visual - it was working with complex operators without adding massive complexity to the user.
We used one rule: don't mix AND and OR at the same level.
Within a group, all filters share one operator (all AND or all OR). Between groups, groups are joined by one operator. By locking each level to a single operator, we got three things at once:
We used one rule: don't mix AND and OR at the same level.
Within a group, all filters share one operator (all AND or all OR). Between groups, groups are joined by one operator. By locking each level to a single operator, we got three things at once:
- No ambiguity. A group always evaluates one way. There's no hidden precedence to learn.
- A predictable simplified UX. The AND/OR control sits at the group level, not next to every filter.
- A clean engineering contract. The data model becomes "a list of groups, each with an operator and a list of filters, joined by a top-level operator."
In an early version, adding a new group could reshape filters that were already there. The real design problem wasn't visual clarity - it was predictability.
Further iterations
From there I pushed the interaction and UI to make groups feel deliberate. When someone adds a group, it should feel like they're intentionally creating a new layer of logic, not accidentally changing the meaning of what's already there.
Most of the work sat in the details: making the hierarchy between filters and groups read clearly, working out how much emphasis the group containers needed, getting empty and default states right, handling incomplete states and validation, and keeping the logic simple enough that the UI didn't start to feel like a query builder.
Most of the work sat in the details: making the hierarchy between filters and groups read clearly, working out how much emphasis the group containers needed, getting empty and default states right, handling incomplete states and validation, and keeping the logic simple enough that the UI didn't start to feel like a query builder.
Separating groups into an individual card with ability to add a new filter group
Validation
Because this pattern was more involved than a normal filter flow, I wanted to check whether people actually got it. I ran a usability test with 5 users from our saved lead-gen template group - marketing, BD, and research/sales.
The model broadly landed. Most people assumed AND/OR options existed before they ever opened the dropdown. With filter groups specifically there was some initial hesitation, but the moment people saw the UI shift as they grouped filters, they understood the two sections were filtering separate sets of data.
The model broadly landed. Most people assumed AND/OR options existed before they ever opened the dropdown. With filter groups specifically there was some initial hesitation, but the moment people saw the UI shift as they grouped filters, they understood the two sections were filtering separate sets of data.
"Ok so we have our individual filters stacked inside filter groups… this makes less sense in this example that they're AND conditions, but if the groups were separated by OR conditions it would make more sense to me."One user on a small screen didn't see the "Add filter group" button at all - it sat below the viewport. That turned into an implementation note in the handoff: the draggable panel always has to stay within the viewport height.
Anatomy for handoff
I added a breakdown of this complex logic and included all the edge cases for handing off to engineers.
Where this sits and what it shipped
Filter Groups shipped as part of the wider Contacts experience in Typeform - a lightweight CRM layer built on top of forms, designed to help teams capture, segment, and follow up on leads without leaving the product.
The success of Contacts overall was measured against four things: contacts enriched, active automations, completion rate, and email engagement.
For Filter Groups specifically, the bar was whether people could build segments that previously weren't possible, and whether they could do it without needing support to understand the logic. Both held up in testing, and the AND/OR-per-level rule was the thing that kept the feature usable as segmentation got more advanced.
The success of Contacts overall was measured against four things: contacts enriched, active automations, completion rate, and email engagement.
For Filter Groups specifically, the bar was whether people could build segments that previously weren't possible, and whether they could do it without needing support to understand the logic. Both held up in testing, and the AND/OR-per-level rule was the thing that kept the feature usable as segmentation got more advanced.
Reflection
The most interesting design work on this project wasn't on the surface. It was in shaping the behaviour of the system - defining how it should think, what it should let users do, and what it should protect them from - and then making that legible enough for a small team to build, ship, and explain without a manual.