I've worked on and shipped plenty of things — some more complex, some more well-known. But every now and then, something small stops you mid-implementation and turns out to be worth thinking about properly. No grand architecture, no distributed systems — just a quiet little observation that I thought was worth writing down.
As part of a project I started working on recently, I had to integrate a custom boolean expression filter into the product. Let users define conditions, combine them with AND/OR, nest them — you know the kind of thing.
And my first instinct was obvious: a visual tree-like expression builder. Interactive, widely used, makes the logic visible without making users write raw expressions. Done, right?
But then I started wondering — is there a way to do better than the tree? Something flatter, more constrained, but still usable? Even though I'm not a UI designer or engineer, this felt like an interesting problem to sit with for a bit.
So I thought about it. And the more I thought, the more I kept circling back to the same two goals:
User friendly — the UI shouldn't require users to understand grammar, parentheses, or boolean syntax at all. Just point and click.
Flexible — even if the UI is constrained to a specific form, users should still be able to express whatever nested logic they have in mind. The shape restricts the interface, not the expressiveness.
Those two goals seem simple. They're actually in constant tension. And that tension is exactly what makes filter UI design surprisingly hard to get right.
The two obvious extremes (keeping the tree aside for now)
Let's start from scratch. You need users to express logical rules. Your first instinct gives you two options:
Option A — just let them type it:
(country = "IN" AND plan = "pro") OR (referral = true AND NOT churned)
Powerful. Expressive.Shows every user who isn't a developer the exit.
Option B — a flat AND/OR toggle:
Match [ ALL ▾ ] of the following:
┌─────────────────────────────────┐
│ country is India │
│ plan is Pro │
│ signup_date after Jan 2024 │
└─────────────────────────────────┘
Clean. Approachable. Works fine until someone needs (A AND B) OR (C AND D) — at which point they're completely stuck and don't even know why.
And that got me thinking — is there a way to keep the UI minimal and clean, but not silently take away expressiveness from the user? Like, can you have both?A UI that looks simple but doesn't secretly cap what logic you can express?
That question is what pulled me deeper. And that's when I started thinking: what if you take a more structured approach to the logic itself ? What if the UI enforced a specific logical form?
That's where = OR of ANDs
Group 1: (A AND B) ─┐
Group 2: (C AND D) ─┼─ OR'd together
Group 3: (E AND F) ─┘
. In theory, that means the form doesn't cap what users can express, just how they express it. Unlike the flat AND/OR toggle, a user could say "all of these conditions together, OR this other set" — which covers a meaningfully wider slice of real-world logic.
HubSpot does something similar :
┌─── Group 1 ─────────────────────┐
│ country = India │ ← ANDed together
│ plan = Pro │
└──────────────────────────────────┘
OR
┌─── Group 2 ─────────────────────┐
│ referral = true │
│ signup_date > Jan 2024 │
└──────────────────────────────────┘
You can explain this to a non-technical people in 30 seconds.It's flat. It's readable. User friendly. More expressive than a flat toggle.
Both goals, one clean structure. I was pretty convinced this was it.
So when does it fall apart?
The explosion problem — this is the caveat
Here's the part that actually surprised me when I dug into it.
Both CNF and DNF have what's called an explosion problem — and it goes in opposite directions for each.
Take this expression: A AND (B OR C OR D)
Totally reasonable thing to want. But DNF doesn't allow OR inside an AND-group. To get it into valid DNF, you have to distribute A across the OR:
A AND (B OR C OR D)
↓
(A AND B) OR (A AND C) OR (A AND D)
Three output clauses from one input. Now go a step further:
A AND B AND (C OR D OR E OR F)
↓
(A AND B AND C)
OR (A AND B AND D)
OR (A AND B AND E)
OR (A AND B AND F)
A is duplicated four times. B is duplicated four times. And this is provably unavoidable — the exponential blowup when converting to normal forms is so well-documented that a whole separate technique, the where users have been asking for custom filter rules with proper nested logic — the ask has been open for years.
The problem isn't that these UIs lack expressive power — mathematically, DNF can represent any boolean logic. The problem is that the moment complexity crosses a threshold, the UI stops feeling like a tool and starts feeling like a constraint. Users know exactly what they want — they just can't map it to the interface without repeating the same painful things over and over.
So where does that leave us?
Honestly, the flat DNF/CNF UI isn't widely used in the wild — and I think this is why. The explosion problem is real, and once you've seen it, a strict two-level structure feels like a trap.
What most UIs that handle complex logic actually reach for is some form of a tree abstraction — technically an Abstract Syntax Tree (AST). Instead of enforcing a fixed two-level shape, you let users nest groups inside groups:
AND
├── country = India
├── plan = Pro
└── OR
├── referral = true
└── AND
├── signup_date > Jan 2024
└── trial_used = false
Visual indentation replaces parentheses. You can nest as deep as you need. No duplication, no explosion.
┌─── AND ──────────────────────────────────────┐
│ country = India │
│ plan = Pro │
│ ┌─── OR ──────────────────────────────────┐ │
│ │ referral = true │ │
│ │ ┌─── AND ───────────────────────────┐ │ │
│ │ │ signup_date > Jan 2024 │ │ │
│ │ │ trial_used = false │ │ │
│ │ └────────────────────────────────────┘ │ │
│ └──────────────────────────────────────────┘ │
└───────────────────────────────────────────────┘
So the tree approach answers the question I started with: yes, you can have a minimal-looking UI that doesn't secretly limit what the user can express. You just have to go one abstraction level deeper than DNF/CNF.
The spectrum — and why this is worth knowing
All of this sits on a spectrum:
Flat toggle → DNF/CNF editor → Tree/AST builder → Free-text expression
(simple, (structured, (flexible, (powerful,
hits ceiling hits explosion scales well, intimidating
fast) at scale) but can be flashy) to use)
- Move right →more expressive power, more complexity to build
- Move left → easier to build and use, hits a ceiling faster
This whole thing started from one implementation question and ended up pulling in boolean algebra, normal form theory, and how real products have handled it. That's the part I find genuinely interesting — not that the problem is hard, but that you wouldn't even know there's a formal angle to it unless you happened to dig sideways into it.
If you're building something similar, worth knowing this spectrum exists before you pick a point on it. Anyway, went deeper than expected on this one — hope it was useful.
SOCIAL SHARE CARD GENERATOR