Making complex segmentation logic feel effortless

The Problem

Creating an email audience sounds simple until the targeting becomes specific.

A campaign might need to reach customers who:

• spent between $500 and $800,

• live in the United States,

• visited a particular product page,

• and did so within a defined date range.

The logic can become significantly more complex as additional behaviors, traits, and branches are added.

Existing tools often represented this logic through dense query builders, technical operators, brackets, or automation-style diagrams. Those patterns were powerful, but they made the experience feel closer to programming than marketing.

The challenge was not simply to support Boolean logic.

It was to make that logic feel natural.

Starting With a Vague Brief

The original brief was broad:

“E-commerce founders and marketers need an easier way to create, manage, and update mailing groups.”

Before designing the workflow, I had to understand how marketers actually thought about segmentation.

I reviewed competitor tools, support complaints, instructional videos, and campaign-building tutorials. I also spoke directly with email marketers and observed one marketer building an audience for a real campaign.

The turning point came during one of those conversations.

While describing a target group, the marketer repeatedly used the phrase:

“All users who…”

That sentence became the foundation of the interaction model.

Instead of asking users to construct a query, AudienceBuilder would help them complete a thought.

The Core Design Principle

Make the logic read like a sentence

The interface begins with:

All users who…

Users then add either:

• Performed an Event

• Have a Trait

Each selection expands into a readable condition using dropdowns, values, and simple connectors.

For example:

"All users who performed a purchase,
where purchase value is greater than or equal to $500,
and less than or equal to $800,
and have the trait Country: United States"

The structure preserves the flexibility of Boolean logic without exposing users to syntax, brackets, or query language.

Why AND and OR Were Enough

More advanced systems often use constructs such as IF, ELSE, WHEN, or visual node graphs.

I deliberately avoided those patterns.

Audience segmentation did not require causal automation logic. It required marketers to include users who matched one condition, several conditions, or one of several possible groups.

AND and OR were sufficient for that mental model.

They also made the interface easier to read aloud:

"Customers who spent more than $500 AND live in the US, OR visited a specific page after a certain date."

This kept the experience conversational and reduced the sense that users were building a technical rule set.

Progressive Complexity

Starting nearly empty, then growing with the user

One of the most important decisions was to avoid presenting the full complexity upfront.

The default screen includes only:

• a segment name,

• the total contact database,

• a visible audience preview,

• and the prompt: "All users who…"

The interface starts slowly.

Each new event, trait, or Boolean branch adds only the controls required for the next decision. As the segment becomes more sophisticated, the layout expands gradually through nested cards.

This Progressive Disclosure approach allows the system to support highly complex logic without making the first interaction feel intimidating.

Structuring Complexity With Nested Cards

I explored patterns inspired by automation tools and visual programming systems.

They quickly introduced problems.

Brackets made the interface feel mathematical. Node-based flows felt too technical. Deeply indented trees became difficult to scan.

Nested cards provided a better balance.

Each card represented a logical group, while spacing and alignment communicated which conditions belonged together. AND relationships stayed within a group, while OR relationships separated groups visually.

This created a structure users could scan vertically and edit without reconstructing the full logic in their head.

Preventing Empty Results

Showing the audience size in real time

A common failure in segmentation tools happens late in the process.

Users spend time building a complex audience, submit it, and only then discover that no contacts match the criteria.

I proposed updating the audience count as each rule was added.

Because the segmentation logic was already being evaluated during construction, the interface could show the projected audience size immediately.

This made the experience more forgiving.

Users could see whether a rule narrowed the audience too aggressively and adjust it before saving or exporting the segment.

The live count also created a direct relationship between cause and effect:

Add a condition → See the audience change.

Validation

The startup's budget and stage limited formal user research, but we were able to run controlled usability exercises with eight email marketers:

• three participated on-site,

• five participated remotely.

Participants created comparable campaign audiences using the existing process and the new builder.

In the controlled environment, the AudienceBuilder workflow reduced audience creation time by 76%.

The test also confirmed that participants could read previously created segments, understand the logic, and make changes without rebuilding the audience from scratch.

My Contribution

My role was deliberately focused.

I did not own the product strategy, brand, or design system. I worked under the guidance of a senior product designer and used the established visual system to design the segmentation workflow.

Within that scope, I owned:

• researching segmentation patterns,

• translating marketing intent into interaction logic,

• defining the rule-building architecture,

• designing progressive states and branching behavior,

• proposing the live audience count,

• and preparing the workflow for developer handoff.

This project became an important step in my development from interface-focused UX work toward broader product thinking.

The most valuable lesson was not how to design Boolean logic.
It was how to connect user language, technical constraints, and business goals in one interaction model.

Outcome

I left the agency before the product launched, so I cannot attribute any production or commercial results to this work.

The strongest evidence available is the controlled usability testing, where participants completed audience-building tasks 76% faster using the proposed workflow.

The project also gave the wider product team a scalable interaction model capable of supporting:

• behavioral events,

• customer traits,

• date constraints,

• unlimited AND/OR branching,

• and real-time audience calculation.

That distinction matters.

The case study demonstrates the quality of the design direction and validation available at the time, without implying ownership of outcomes I did not observe.

Reflection

The part of this work I am still most proud of is its legibility.

Even when the segmentation becomes complex, the result remains something a marketer can return to, read, and modify without first reverse-engineering how it was built.

That is the real success of the interaction model.

The system did not eliminate complexity.

It organized complexity into a form that felt manageable.