The problem

Enterprise admins at Fortune 100 CPG companies, global tech firms, and healthcare systems all saw the same thing: a binary "low adoption" state on every feature with no benchmark and no narrative. They couldn't defend the numbers to their leadership, couldn't tell which resource to reach for first, and got zero acknowledgment when things were going well.

The reframe

I designed a two-state model, On Track and Building, with transparent expert-set targets for each feature. Features still climbing get two or three curated reasons adoption may be lagging, each linked to a specific playbook, delivered in a calm accordion-and-carousel pattern instead of an alarm.

The craft

The voice principles were as designed as the UI: plain English over jargon, "specific not precise" over fake math, every Building state routed to a next step, Cloverleaf as a credible human voice, not an algorithm. The details mattered too, down to 40px hit areas on 24px paginator controls.

I scoped the MVP deliberately small and documented a five-version trajectory (trend data → severity layers → peer benchmarks → auto-diagnostics → projections), each with explicit "revisit when" criteria, so engineering knew exactly what we weren't building yet, and why.

The setup

Alongside its enterprise business, Cloverleaf grows through individuals who find the product themselves. That funnel is a different discipline: a stranger arrives from an ad or a recommendation, and you have a few minutes of attention to get them from a landing page to a moment of real value. My early design work at Cloverleaf lived here, and I never fully left.

The practice

We instrumented the funnel end to end, so every release shipped with a hypothesis and a number to watch. Weekly activation rate was the primary metric, with early-week behaviors like joining a team and connecting a calendar as the supporting cast.

The iteration was unsentimental. One onboarding task got killed when time-on-task data showed nobody actually read it. Later, click data showed users hunting for exactly that kind of help, so it came back redesigned around activation moments instead of feature tours. We also unified what had grown into three divergent onboarding paths into one coherent journey, and moved key integrations into the flow itself after data showed that users who get coaching inside their daily tools stay engaged longer.

Designing the paywall

The trial redesign treats the moment of payment as part of the experience, not an ambush. Card capture sits right after the assessment, when anticipation for results is at its peak. Pricing is listed plainly. A persistent countdown keeps the trial honest, billing is manageable from anywhere in the product, and two days before conversion the user gets a courtesy email saying exactly what will happen and how to stop it.

The setup

What I care about in a design system is consistency with flexibility: end users get a cohesive, reliable experience that's accessible to everyone, and the team gets components that bend without breaking. The metrics I track serve that goal (component adoption in code, handoff time, visual regression rate) because a library nobody ships from delivers consistency to no one.

The work

I built and maintain the component library, from tokens to interactive states to light and dark modes, plus the documentation that keeps designers and engineers in sync. When new AI surfaces stressed the system, I extended it rather than letting one-off components multiply.

Closing the gap

This is where my front-end roots came back around. Using Figma's MCP integration with Claude and Cursor, I connected the design system directly into the build workflow: generating mode variations, prototyping new experiences against real components, and pushing accessibility redlines back into Figma. I taught the pipeline at our engineering tech talks.

A year ago I hadn't opened a terminal in months. This past year my GitHub chart is solidly green. It's not senior engineer code, but it's functional, tested, and shipped, and it turns "let me describe the micro-interaction" into "here's the PR."

The problem

Cloverleaf's coaching experience begins with users selecting a development focus. Mining six months of meeting notes, user interviews, and product data surfaced an uncomfortable truth: the vast majority of users picked a focus at random, with no context. That included some of our most enthusiastic champions, who created none at all without direction.

That one broken moment contaminated everything downstream: coaching relevance, check-in completion, and the credibility of the ROI story enterprise buyers were asking for.

My role

I owned this end-to-end as PM and designer: synthesized the signal from research and data, made the case to leadership in our planning process, and designed the new flow.

The approach

Flip the model from "pick from a list" to assessment-first and recommendation-led. Users complete a short assessment before choosing; the product then recommends focuses grounded in their actual personality data. First contact becomes an "I see you" moment instead of a blank menu.

I prototyped the new flow against the current one, paired it with qualitative interviews, and defined the falsifier up front: if assessment-first increased trial drop-off through cognitive load, we'd revisit. Designing the test that could prove me wrong is part of the design.

The problem

The platform's AI capabilities had grown up as silos: discovery chat, feedback tools, practice scenarios, each its own destination. Users experienced features. The brand promised a coach. The longer the gap persisted, the more it defined our category position.

The vision

A unified coaching surface where one AI coach draws on every tool, plus a personalization layer that puts existing personality data to work in every interaction. Every user already had rich assessment data we weren't using in coaching conversations, and that data is the hardest thing for a competitor to copy.

The strategic call

The engineering foundation shipped before the design strategy was settled, which forced a real product decision: ship multi-tool calling inside the current chat UI as an MVP, or hold for the unified design. I argued for both: ship now in the existing UI to start learning, and design the unified surface in parallel. I also named what would change my mind, which was research showing the unified surface hurt discoverability of the features it absorbed.

My role

Design lead and product voice for the vision: sequencing which surfaces get personality data first, defining the MVP path, and pressure-testing the discoverability risk.