Case Study · Optimeleon

I designed and built the first thing the product ever shipped.

Campaign creation, the multi-step flow where Optimeleon users turn a single page URL into a live, AI-generated A/B test. I designed and coded it; the engineering team refined it for production.

Role · Design Engineer Designed + coded the flow Shipped as the product's front door Optimeleon · founding product
The final Ideas page — a unified screen where users review, filter, refine and generate A/B test ideas
Ch 01 — Where it started

No product yet. Just a point of view.

I joined Optimeleon before there was a product. One of my first tasks was sitting down with Nico, the founder, to decide what this thing should even feel like. We kept circling the same frustration: every SaaS tool looks the same: the same gradients, the same rounded cards, the same safe palette.

So we aimed at the opposite. We moodboarded toward Neobrutalism, but raw Neobrutalism was too loud for a tool people use every day. We dialed it down until it felt bold but livable, and called it Optibrutalism. That point of view shaped every screen that followed.

Optimeleon helps businesses improve website performance automatically. Its AI creates, tests, and optimizes page variants so companies get more conversions without manually running A/B tests. The first surface anyone needed was a way to create a campaign. That's what I built.

I designed and coded the campaign creation flow; the engineering team refined it for production.
Ch 02 — The problem

Six steps that couldn't feel like six steps.

Creating a campaign isn't one decision. It's a chain of them. A user pastes a page URL; our AI analyzes it and proposes the product details, USPs, and audience; they confirm or edit that; the AI picks the page elements worth testing; they adjust the selection; the AI proposes optimization ideas; they refine those into variants; then they publish.

Every one of those steps is a place a first-time user could stall, second-guess, or quietly give up. And this is the front door: if someone bails here, they never reach a published test, never see the product work, never become an active user. The hard part wasn't any single screen. It was making an AI-heavy, multi-stage flow feel guided instead of overwhelming.

URL Analyze Ideas Variants Publish

This case study goes deep on the Ideas step, highlighted above. It's the first screen that hands the user something the AI made, which makes it the moment the whole product either earns trust or loses it.

Ch 03 — The centerpiece

The first screen that had to earn it.

The Ideas page is where a user first sees value: the AI's proposed angles for optimizing their page. It carries a lot: reviewing ideas, refining them, generating more, and it had to do all of that while feeling exciting and simple at the same time. It took three versions to get there, shaped by founder feedback and watching real users move through it.

1
Version 1 · MVP

It worked, but it fell flat.

Version 1 of the Ideas page — a grid of color-coded idea cards

The problem Each card held one overarching idea to build variants from. But "Add idea" took up a whole card slot, and the cards were thin, so thin that when I watched people use it, they read the cards as empty or unfinished and didn't trust the output. Nico flagged the same thing: for the screen meant to deliver the product's first real payoff, it landed flat.

2
Version 2 · Reclaiming space

Made room, and made it inviting.

Version 2 of the Ideas page — richer preview cards with idea generation moved into a floating action bar

The change I gave the cards real previews so they read as finished, and pulled idea generation out of the grid into a floating action: "type your own idea" or "add a random idea." That reclaimed the space the empty "Add idea" tile was wasting and turned generation into a deliberate, inviting action. The cost: a persistent floating element is one more thing competing for attention on an already busy screen; a tradeoff I accepted then, and one the next version resolved.

3
Version 3 · Final

One screen to review, refine, and generate.

Final version of the Ideas page — ideas categorized by angle, with a side chat panel to refine any idea and add more

The resolution The final version unified everything into one workspace. Ideas are grouped by psychological angle (emotional, rational, social proof, urgency), each carries a hypothesis and a live status, and a single chat panel lets users refine any idea, reference existing ones, and generate more, so reviewing and creating stopped being separate modes. That unification was the hard part: collapsing three interactions into one coherent panel is far more complex to build than it looks. I worked through it in code myself rather than handing off a spec and hoping it survived. That is the whole point of designing and building in the same place.

A note on the visuals
This page evolved across different phases of the product's life, so the styling shifts between versions: earlier shots carry the louder Optibrutalism treatment, while the final reflects a more refined system and a richer set of interactions added as the product matured.
Ch 04 — What shipped

It became the product's front door.

The flow I designed and coded was refined by engineering and shipped as the live campaign creation experience, the path every Optimeleon user takes to launch a test. Not a prototype or a concept: the real entry point into the product.

The URL entry step — a single field to paste the page URL and start campaign creation

The front door. One field. Paste a page URL and the campaign begins.

The analysis step — the AI's detected page sections with every element selectable

The analysis. The AI's read on the page. Every detected element is reviewable and selectable before anything is generated.

The variant editor — where a chosen idea becomes an editable page variant

The variant editor. Where a chosen idea becomes an editable page. A deep enough problem that it gets its own case study, soon.

Shipped to production as the live campaign creation flow.

The Ideas page reached a unified review-and-refine workspace across three iterations.

Set the Optibrutalism visual language that the rest of the product built on.

Ch 05 — What I'd do next

The version that ships is never the last one.

The thread through all three versions was trust: users didn't engage until the screen looked finished and behaved like one place instead of three. If I picked it up again, I'd close the loop with evidence: instrument where people drop off inside the Ideas step and let real drop-off, not just observation and feedback, drive the next iteration. The build-in-code workflow that got me here makes that cheap: I can ship an instrumented change and read the result, instead of guessing from a static mockup.

The takeaway

I don't hand off the flow. I build it.

From a point of view about how SaaS should feel, to a coded multi-step flow that shipped. Designed and built end to end, then refined by engineering for production.