Catalyze

(1)

The bet

In early 2025, Enable made a deliberate bet that its next chapter was AI, not analytics bolted onto the side, but AI that could recommend better commercial decisions. The problem: there was almost nothing concrete to show. Model research was underway, the roadmap was a list of product areas, and the company had committed to demonstrating its AI capabilities at Catalyze, its annual customer conference, on a hard deadline.

The vehicle was a concept demo of AI-driven rebate optimization. As I understood the brief, it had to do four jobs at once: win the internal greenlight and funding, sign customers on as design partners, secure the real customer data we'd need to train the models, and prove we could actually execute. A pretty screen wouldn't do any of that. The demo had to be believable.

Underneath the business bet sat the user problem. Commercial teams spend enormous time manually analysing rebate contracts to find opportunities, and still can't see, before they commit, what a change will do to their margin. Harder still: rebate optimization was a net-new job for our customers. We weren't improving a task people already did in our product; we were proposing work many had never had a tool for at all.

(2)

My role

I was the product designer on Enable's AI program, and the person responsible for what the Catalyze demo was and how it felt to use. The data-science team built the optimization and RAG models; my PM presented the demo live on the day.

• Facilitated the three-session discovery workshop that scoped the project, problem framing, ideation, prioritization
• Designed the entire demo experience: the agreements view, the optimization diff, the “Enable AI” co-pilot, the AI work queue, the landing page, and the RAG “Rebate Expert” assistant
• Ran the design QA pass on the working build, a screen-by-screen punch-list of interaction details, each note signed and dated
• Stayed hands-on operationally in the run-up, down to provisioning the access needed to run the demo environment

(3)

Framing the problem before designing it

Before any pixels, I ran a three-session discovery workshop, about eight people across design, product, and key stakeholders, in FigJam, to force agreement on the problem before anyone fell in love with a solution. Session one was problem framing, using a fill-in-the-blanks formula so the team converged on one statement instead of ten. Session two was lightning ideation. Session three cut the MVP down with an impact/effort matrix and MoSCoW. The outputs were deliberate: a problem statement, a prioritized feature list, and a prototype plan. The format worked well enough that the team reused it as the template for discovery in other product areas.

“Users are currently spending too much time analyzing contracts to identify optimization opportunities, which delays decision-making and impacts their earnings potential. They need a way to quickly forecast expected earnings based on contract changes to make more informed decisions.”

The working problem statement, written in the workshop

Catalyze itself became a research instrument as much as a demo. Around and after it we ran structured customer interviews, discovery calls, advisory-board sessions, an external SME review, and a post-event survey. The signals were remarkably consistent:

That trust insight became the spine of the whole design.

(4)

Constraints and strategy

(5)

The design

The design centred on one screen: the agreement, mid-optimization. A diff, not a dashboard. The default pattern for AI output is a separate “insights” surface, but a commercial user trusts what they can tie back to the source. So the optimization lives on the agreement itself: the program-lines table shows each AI change in place, old value → new value, colour-coded, with a running change count so the scope of what the AI proposes is never hidden. Every change can be toggled on or off; the count and the bottom bar update live.

Reasoning lives in the assistant, not on the canvas. The right-hand “Enable AI” panel carries the why, considerations, risks, and opportunities behind each proposal, so the main canvas stays clean while the depth is one glance away. That split later became an explicit principle in the Edge product: the assistant explains the data; the page shows the data.

And the flow ends in the familiar Enable pattern, “Send for approval”, so a brand-new AI capability lands inside a workflow users already trust. Early feedback also pushed me to add entry points beyond a single “Optimize” button, like surfacing an underperforming agreement proactively and routing into the flow from there.

(6)

Craft and the unglamorous foundation

The QA punch-list is the evidence of interaction rigor: visibility timing of the changes tab, chat scroll and jump-to-latest, selection state vs. count synchronisation, hover states scoped only to rows that actually changed, change-card truncation after two lines. Small things that decide whether an AI feature feels solid or flaky.

Words carried a disproportionate load, because the product makes financial claims. In the productization we did a dedicated copy pass, “Rebate payout” became “Proposed rebate payout,” “Accept” became “Send for approval”, and made the numbers look real: “$27,000,000 exactly looks fake.” When research later showed users ignoring AI insight text written as prose, the fix was to lead with the visual diff, not the paragraph.

And the unglamorous truth underneath all of it: optimization is impossible without clean data, and at kickoff only about 10% of customer data was model-ready. In Enable Edge, I went on to own the data-onboarding design lane, CSV upload, the data mapper, the data hub, the part that makes everything else possible.

(7)

Outcome

Catalyze did its job. The demo ran 15 times on day one and 4 on day two with zero errors, “the vast majority were super engaged,” and optimization in particular “bought a wow factor.” Companies that signed on at or after the conference flowed directly into the Edge design-partner program. And the results earned the company buy-in, the funding, and the data access to proceed, the greenlight that created Enable Edge, the standalone AI rebate- and pricing-optimization product now in active build.

It also taught us what to build: post-event feedback ranked the most-wanted capabilities (create-contract-from-PDF was the #1 ask), confirmed the two AI tracks worth pursuing, and surfaced the risks that shaped the roadmap, chiefly trust in the numbers and data privacy. Many visitors didn't fully grasp what “optimization” meant, which directly informed how we'd explain it going forward.

The trust thesis, validated.When I later ran a live usability session on the productized Edge prototype with a real customer, the loudest finding was exactly the bet made at Catalyze: one participant ignored the AI's written explanation and trusted the visual diff (“reading that blurb does not tell me, visually it was easier to see it”) and caught a math inconsistency instantly (“the math doesn't math”); the other, from finance, said she “would feel better if it would show its work.” The conclusion I wrote in the debrief, the product needs to show its work, is the Catalyze principle, sharpened by evidence.

(8)

From demo to product

After the greenlight I moved onto Enable Edge and designed the first product screens that carried the concept forward, the portfolio home, the create-portfolio flow, and the recommendation view, plus the foundational page components.

As the team grew, the design work split: a second designer took the deep simulation and portfolio-builder evolution, while my lane became data onboarding, anomaly detection, and org/admin, and I became the team's de-facto research lead, authoring and moderating the flagship customer usability sessions and writing the moderation guides. I'm honest about that evolution because it's the truer, more senior story: I designed the thing that won the bet, then helped build the practice and the foundations that let a growing team deliver it.

(9)

Reflection

• Trust is a design material, not a model property. Users don't adopt confident answers; they adopt answers they can interrogate. The most important screen in an AI product is often the one that shows the reasoning, not the result.
• Demo-as-discovery works. A high-fidelity concept demo in front of customers is one of the fastest, highest-signal research instruments I've used, provided you treat the feedback as data and capture it rigorously. Catalyze recruited partners and told us what to build.
• What I'd do differently: put a believable version of the optimization in front of real users earlier, even rougher, the strongest learning (trust = show your work) came from a live session months later, and some of it could have been banked sooner. And bring accessibility into the concept stage, not just productization.