Unified Filters

Enter the password to view this case study.

← Back to all work

Unified filters

Overview

I led a platform initiative to turn a fragmented filter experience into a shared model, adopted by 3 pillar products in HubSpot.

My role
Lead product designer
My team
1 PM, 1 PD, 1 TL, 5 FE engineers

Context

HubSpot is a go-to-market platform that brings marketing, sales, customer service and operations into one system, built on a shared customer database. People come to HubSpot to find their data and ask questions about it. Filtering is how they do it.

Filtering is the core interaction in 4 HubSpot pillar products

CRM

HubSpot's most-trafficked page. Filtering is how customers find the right records.

Sales reps, CRM admins

Segments

Building a segment is filtering CRM records.

Marketers

Automation

Filters define every trigger and branch in an automation.

RevOps, CRM admins, marketers

Reporting

Every report starts by narrowing the data to what matters.

CRM admins, marketers, RevOps

The problem

Filtering was consistently the top 3 CSAT complaint in all four products.

CSAT themes

  • Not flexible. Users couldn't express the questions they actually had, and nesting support was limited.
  • Missing capabilities. Basic needs worked in one product but not another.
  • Inconsistent. Different capabilities and different UI meant the same “filter” could give different answers.
  • Poor usability. The filtering UX was unintuitive and confusing, and the list of operators was bloated and overlapping.

“HubSpot's data segmentation feels ‘option-divey,’ where the abundance of options and inconsistent interfaces can be overwhelming. The segmentation tools often present multiple ways to achieve similar outcomes, such as using lists, workflows, or filters, without a clear and unified approach, creating confusion.”

Marketing operations manager

“Using the same filters as I do to view Contacts, I get very different results when I put together a list. Very confusing and not an effective use of time.”

Marketing ops lead

The opportunity

Engineering made a big bet: one unified query platform to replace the separate query backends behind each product. With every product about to query data the same way, design had a huge opportunity to unify the front end too.

For customers

How might we make filtering intuitive for simple questions, capable of complex ones, and consistent across HubSpot?

For the platform

How might we make the platform filter editor the easiest way for product teams to ship fast, consistent filtering?

Defining success

  1. Launch

    Time to value

    Time to create a segment, measured by a randomized A/B test.

  2. +2 weeks

    Customer satisfaction

    In-product survey.

  3. +1 quarter

    Customer satisfaction

    A lower share of negative CSAT verbatims tagged as filtering.

  4. Ongoing

    Platform adoption

    Adoption of the new filter editor, fewer custom filter components, and a lower pattern detach rate.

Timeline and my role

As the lead product designer, I set the direction of the new filter UX and aligned product and design leaders across the pillar product areas.

Design strategy and cross-team influence

Defined the shared filter model and the design principles every product area builds on. Led cross-team workshops to identify needs and drive alignment.

Research and design

Audit, competitive analysis, discovery research and usability testing. Delivered high-fidelity mockups and specs, design system patterns and documentation.

Development

Handed off vibe-coded live prototypes, did QA and worked through edge cases with engineers.

My process

Define a shared baseline

UX audit and competitive analysis

I audited the filter patterns across platforms through four lenses: interaction design, content, functionality and data schema. I also looked at how other tools handle filtering.

Stakeholder research

I shared the audit and talked with each product team to understand which differences were intentional, and which were design workarounds for system limitations.

The consistency audit board in FigJam, comparing filter screens across products by interaction design, content strategy, functionality, schema and data layers. Competitive intel board with rows of filtering screenshots from other products. A table of design principles and heuristics for filtering, by user interface, interaction design, content, functionality, schema and data.

Discovery research

Filtering serves a wide range of users, from RevOps and sales reps to marketers and business analysts, with very different technical levels and data literacy. Some were scared to even open the filter panel. Others asked for complex queries the platform couldn't support. Progressive disclosure is key.

We assumed each tool served a different persona with different filtering needs. Research showed the opposite: users' filtering needs were far more alike than different across tools. For example, sales reps on the CRM index often needed the same cross-object filtering as marketers in Segments. Filtering limits pushed users to the wrong tool and caused confusion and frustration.

“It makes it easier to work in different areas of HubSpot when you don't have to consider that certain things have limitations to them versus other tools within the platform. But for some reason you decided to artificially limit the functionality for this particular part of the platform.”

Sales operations manager

Set design principles

The situation

Each team wanted a “simpler” filter for their everyday cases, plus the advanced capabilities their app specifically needed. As a platform team, my tech lead wanted one filter editor everywhere that exposed nearly everything the query could do. I needed to set a direction our team could all stand behind.

My approach

I reframed the goal: consistency is a means, not the goal. The goal is successful task completion in each app. I defined consistency as a learnable pattern, not identical UI, so small variants could live within one shared model. Then I let user research draw the line between the shared baseline and app-specific capabilities.

The result

These became the team's design principles. We stopped re-litigating each feature, design conversations got faster, and we converged on a phase 1 solution quickly.

The filters design base principles doc, starting with: breaking consistency requires intent and evidence; advanced capabilities must not tax the default path; baseline capabilities are exposed everywhere; users must be able to predict their results.

What we built

Design decisions

One model that scales from a single condition to complex queries

Before

The old advanced filters panel, where a single condition already sits inside Group 1 with an 'or' to add another group.
Every filter had two levels of nesting. That was intimidating for simple use cases and not enough for complex ones.

After

The new All filters panel with two plain conditions joined by 'and'. The same panel with groups and a subgroup that filters on associated deals.
Users add nesting only when they need it, from a single condition up to three levels.

Flexible filtering with drag and drop, group and ungroup

Restructuring a filter shouldn't mean rebuilding it. Users can drag a condition into or out of a group, drop one condition onto another to create a group, or turn any condition into a group from its menu.

Dragging the condition 'City is any of Cambridge, Seattle' into Group 2.
Dropping a condition with a 'Drop to create a group' hint.
A condition's menu with Duplicate, Pin filter, Turn into filter group and Delete.

Scalable data panel IA for many data sources

Each product filters on a different set of data sources. I designed for a scalable IA that accommodated all of them.

Segment

  • Primary object
    • Properties
    • Events
      • Event properties
    • Membership
    • Associated objects
      • Properties
      • Events
        • Event properties
      • Membership
  • External data source
    • Properties

Workflow

  • Data from trigger
    • Triggered event
    • Primary object of the triggered event
    • Associated objects to primary object
  • Data from workflow
    • Previous action 1 tokens
    • Previous action 2 tokens

One consistent UX pattern across associated objects and events

Filtering on associated records and linked events under the hood shared the same paradigm. I designed a consistent UX pattern that scales to both.

PatternAssociated objectsLinked events
ExistenceHas / has no associated dealHas done / has not done Opened email
QuantityNumber of associated deals is at least 3Opened email at least 3 times
AttributeAny (or all) associated deals where amount > $1,000Opened email where campaign is Spring Sale
AggregationTotal deal amount > $50,000Total purchase amount > $500
Which oneFirst / most recently associated dealFirst / most recent email opened event
Scoped byAssociation label (e.g. Primary)Time window (e.g. last 30 days)

Reduce operators by 30% by moving the choices to values

Long, overlapping operator lists were one of the top usability complaints. I reduced the operator overhead by introducing modes into the input value: a property comparison mode lets users compare against another property, and a new date picker handles relative and fixed dates in one place.

Property comparison mode

Recording: an Amount filter switches from a literal value to comparing against another property, then picks Companies, Primary, and Annual revenue.

New date picker

Recording: the date picker opens, switches to the Fixed dates tab, chooses 'is between' and selects a date range on the calendar.

Learn filtering once, use it everywhere

Before

A collage of different filter panels from across HubSpot, each with its own layout and styling.

After

The unified filter editor with groups, a subgroup on associated deals and an event filter.

Design walkthrough

Open the live demo →
Recording: adding filters, opening the Add filter menu to add a filter group, adding a subgroup inside it, then adding a date condition to the subgroup.

Add filters and filter groups

Start with one condition and add more as you go. When the logic needs it, add a filter group from the Add filter menu, or a subgroup inside a group, up to three levels deep.

Recording: dragging conditions into and out of groups, dropping one condition onto another to create a new group, then ungrouping.

Drag and drop, group and ungroup

Change the structure without rebuilding the filter. Drag a condition into or out of a group, drop one condition onto another to group them, and ungroup when the group isn't needed anymore.

Recording: filtering contacts that have exactly 2 associated companies with the Primary label, where all of the companies match annual revenue and industry conditions, then renaming the group.

Filter by associated objects

Filter records by the companies, deals and other records they're associated with. Set how many should match, narrow them by association label, and add conditions on their properties, like annual revenue or industry.

Recording: adding a Demo requested event, setting it to 3 or more times on a date, then filtering the most recent event by channel and device type.

Filter by linked events

Filter by what people did, like requesting a demo. Set how many times and when, then filter on the event's own details, such as channel or device type, across all events or just the first or most recent one.

Recording: choosing a Google Sheet of Q3 webinar attendees from external data sources, then filtering rows where Attended is true and Industry is Manufacturing.

Filter by external data sources

Filter on data that lives outside HubSpot, like a spreadsheet of webinar attendees. Pick the source, then add conditions on its columns the same way as on any other property.

Filters in context

Workflow editor with the Triggers panel open. The enrollment filters use the new editor: a form submission channel condition, a group with form type and form name, and a contact owner condition.

Where it landed

  1. Launched in private beta

    Thousands of requests to join the beta in one week, and lots of positive customer feedback.

    Recognized by HubSpot's co-founder and CTO.

  2. Product teams on board to migrate in Q1 2027

    Segments and Workflows committed to the migration on their roadmaps.

Customer comment, with the name blurred. Customer comments, with names blurred: 'Happiest days of my life: 1. Birth of my son 2. The day cross object filtering went live in HubSpot', 'I'm so happy this is live! It's been one of my wave a magic wand answers for so long with the product team!', and 'Something I've been waiting for for 5 years!!!'

What I've learned

Set the direction, don't wait for it

With no dedicated PM for most of the project, the biggest risk was no decision at all. My tech lead and I stepped in to fill the gap. I learned to set the direction early, ground it in research, and let others push on it. We debated almost every decision, and that push and pull is how we got to a design that's intuitive and scales to complex use cases.

Go as deep as the query goes

Every filter is a query underneath. Understanding how the query works showed me where different requests were really the same need, and where the UI had to expose real complexity.

If I had more time...

Two directions are in progress: natural language combined with manual filtering, and subquery support.

Learnings from natural language filtering

A parallel research study by the Segments team tested building filters through chat.

What the study found

  • Manual filtering is table stakes. 10 out of 10 customers built filters faster by hand than through chat.
  • Chat at the edges, manual at the center. Chat helps with shape, the rough intent. Manual handles precision.
  • Chat breaks down on complex and messy data.

What we decided

Rebuild the manual foundation first, designed so chat can hand off into the manual builder later.

Design exploration for NL filtering

Open the live demo →
Recording: asking Breeze for contacts in Boston who attended a webinar or requested a demo, Breeze adding the filters and listing what it added, then a follow-up that removes the demo condition and adds an associated company.

Asks when language is vague

When a word like “best” could mean several things, Breeze asks a clarifying question and saves the answer to memory.

Shows what changed

Each reply lists which filters were added and which were removed.

Design exploration for subquery

Open the live demo →
Recording: in a group with a City condition, adding a filter where the sum of annual revenue of associated companies in an industry is equal to the sum of deal amount of associated deals.

Compare against a calculated value

Filter on a sum, average, min or max from related records, like a contact’s companies’ total revenue compared with their deals’ total amount.

Recording: adding a filter that takes the annual revenue of the first associated company and checks that it is equal to the deal amount of the first associated deal.

Use a value from one associated record

Filter on a value from a specific associated record, like the first associated company’s revenue or the most recent deal’s amount.

← Back to all work