Challenge

At Epsilon, the Events platform likely emerged from a few hard-coded, client-specific projects before evolving into an application where clients could create their own functional programming. When I joined, the product was in this transitional half hard-coded state, and at one point, I noticed that the 'Exclusion Builder'—what seemed to be the more complex parts of the product—was constantly postponed in favor of clearer, easier-to-scope work, leaving it without clear ownership or a path forward.

Approach

Sensing an opportunity, I initiated a discovery process with Product and Engineering before deadlines forced reactive decisions. I led workshops to unpack user needs and system constraints, ensuring all voices and technical realities were considered. I then sketched and iterated on early logic constructs to visualize how clients might self-serve exclusion logic without engineering intervention.
I wasn’t afraid to risk misunderstanding the problem at first, as I saw my role as creating some clarity through structured visual exercise that, even if wrong, would spark discussions and help the team see what paths not to take. That’s exactly what happened: the discussions surfaced flaws in early approaches and pushed the team to explore better alternatives with confidence.
These visuals became a shared language across teams, helping us align on feasibility, clarify edge cases, and co-create a path forward toward scalable implementation.

Design Thinking Framework

I applied structured design thinking to break down the complex logic requirements:

Problem Definition: How might we enable clients to create sophisticated exclusion rules without requiring custom development?

Ideation: Mapped out various exclusion scenarios:

• Time-based rules (recent purchases, abandoned carts)

• Behavioral triggers (email engagement, site activity)

• Demographic criteria (location, preferences)

• Nested conditions (multiple AND/OR statements)

Outcome

While this epic would have been solved eventually, by proactively initiating some design thinking, I made it easier for the engineering team to make key decisions and architect it thoroughly before implementation. Also as a consequence this allowed the team to have more time to think together and reduce engineering lift.

Key Learnings

Design Leadership

This project reminded me that impactful design often happens before the traditional "design phase." By proactively identifying system problems and facilitating cross-functional alignment, I was able to drive significant business value.

Systems Thinking

Complex logic requires visual representation to become actionable. The constructs I created weren't just wireframes—they were architectural blueprints that enabled technical implementation.

Collaborative Problem-Solving

The most challenging design problems require deep collaboration with engineering and product teams. Success came from understanding technical constraints while pushing for user-centered solutions.

Reflection

The Exclusion Builder project demonstrates how design thinking can solve complex systems challenges beyond traditional UI/UX work. By focusing on the underlying logic and creating visual frameworks for implementation, I was able to transform a recurring operational problem into a scalable product feature.

This experience reinforced my belief that product designers must be comfortable with ambiguity and complexity—our role is to bring clarity to abstract problems and create frameworks that enable teams to build impactful solutions.