Ymax 2.0

Context

Ymax 2.0 was a rebuild of Yieldmo's ad tech platform. Ymax 1.0's Figma files gave us a starting point for flows and patterns, but 2.0 needed new components and an updated design system, which we built as part of the rebuild. The bigger change was the build process. Our CXO set up a new workflow: instead of designing in Figma and handing off specs, designers worked directly in code through Claude Code, building in a shared prototype deployed on Vercel.

I was one of two designers working this way. I owned the companion audience module, building the flow from creation through attach, using Ymax 1.0 designs as reference and refining them across desktop and mobile breakpoints. Engineering then took the prototype as the blueprint for the production rebuild, aiming to match it 1:1 so they could focus on backend and data integration.

What follows is that flow, and what changed about how I work.

The problem

From Figma reference to working code

The Ymax 1.0 audience flow lived in Figma, where components, layouts, and interaction states were all spec'd out. For Ymax 2.0, I rebuilt it as working code in the shared prototype, resolving layout, behavior, and responsive states in the browser instead of across static frames.

The audiences page is where users find and manage every companion audience they've built, filterable by account. From here, users can create a new audience, or open an existing one to attach it to a deal or campaign.

The creation flow begins by opening a drawer where users name the audience, select an account, and pull components from four tabs: deals and campaigns, line items, supply packages, and 3rd-party data segments. Each component gets added to the components panel on the right, working like a shopping cart for the user's selections.

The components panel was the most interesting design challenge across breakpoints. On desktop and tablet, it has room to live as a fixed right column. Users can see what they're building as they build it. On mobile, that two-column layout doesn't work, so components needed to be reachable without taking permanent screen real estate.

This kind of decision is where the AI-coding workflow really took off. In Figma, prototyping responsive behavior like this means building separate frames per breakpoint, layering interactions and animations on top, spec'ing the logic for engineering, then iterating across all of it when feedback comes in. In code, I could prototype the bottom-sheet behavior live, see how it felt in the actual layout, and adjust without a handoff cycle. What used to take hours or days in Figma took a couple of hours in code, working directly in the browser across real breakpoints.

The bigger shift was what this opened up as a designer. Things I would have skipped prototyping in a Figma-only workflow were a conversation with Claude away from being real, functional interactions. Handoff to engineering became a review of running code, not a translation exercise.

Once the audience is created, users can attach it to a deal/campaign and line item directly from the success state.

Outcome