How I work, what I ship with

How the work divides

I split the work into five moves. They overlap, they loop back on each other, and the design system is what keeps them from drifting apart.

1. 01
   Research

   Understand the problem before touching pixels. Patterns, constraints, real user language.

2. 02
   Design & UX

   Flows, states, and the interaction grammar. What happens when, and why.

3. 03
   Prototyping

   Fast, cheap, disposable. Figma, Figma Make, code sketches, whatever gets to the answer first.

4. 04
   Design system

   The hinge. This is where "looks like a button" becomes "is a governed Button component". Tokens, API, variants, states.

5. 05
   Production code

   The part that has to survive reality: data, edge cases, a11y, performance, integration.

Most of the craft lives in step 4. That's where the prototype stops lying and the real system starts.

From prototype to production

Prototypes are visual hypotheses. They're supposed to lie. That's what makes them fast. Production systems have to tell the truth, which is a different job. Here's how I move from one to the other.

1. 01

   Prototype, speed and intent

   Figma, Figma Make, Lovable, whatever. The goal is to validate UX, flows, and visual direction on the happy path. I ignore edge cases on purpose, because edge cases are a later conversation. This is a hypothesis, not a spec.

2. 02

   System alignment, structure and reusability

   Now the visuals turn into building blocks. Tokens for color, spacing, typography. Component APIs, props, states, variants. And the call every designer-engineer has to make on every screen: is this reusable, or a one-off? Getting that wrong is how design systems rot.

   The shift: from "this looks like a button" → "this is a governed Button component."

3. 03

   Data and state, the layer most people skip

   This is where prototype-to-production actually begins, and it's the step I see skipped most often. I define the data shape. API contracts, schemas. Then the state structure. Local vs global, server vs client. And I ask the questions the prototype never had to answer: what does this component do when data is missing, partial, or late?

   That single optional name is the difference between a design that works in Figma and a UI that works in production.

   type User = {
     id: string
     name?: string
     avatar?: string
     status: "active" | "inactive" | "pending"
   }

4. 04

   Edge cases and resilience

   Empty, loading, error, partial, slow network, large dataset. Every component gets at least three states: loading, success, failure. If I can't name all three, the component isn't done. It's a screenshot.

5. 05

   Hardening, pretty to robust

   Variants. Defensive props. ARIA, keyboard nav, focus management. Memoization where re-renders are expensive, virtualization where lists are long. And governance rules for the design system itself: when to extend a component vs. when to create a new one, so the library doesn't fragment into a thousand “just tweak it locally” forks.

6. 06

   Integration, production readiness

   APIs connected. Auth, sessions, global storage wired. Error boundaries where failures would otherwise cascade. Logging and monitoring so something is watching when I'm not. Responsive behavior that reflows, not just scales, because real layouts break on real devices.

Prototypes define how things look. Production systems define how they behave under stress. That gap is the whole job.

What I bring

• UX prototyping in both Figma and codeI iterate in whichever medium is closest to the answer. Sometimes that’s a frame, sometimes it’s a branch.
• Motion as infrastructureMicrointeractions that communicate state and change, not decorate the edges. Timing is a design decision.
• Accessibility as baselineWCAG isn’t a checklist. Keyboard nav, ARIA, focus order, contrast, before the PR opens, not after.
• Design systems that survive contact with teamsTokens, component APIs, governance rules, Storybook docs. The kind of system that works when I’m not in the room.
• Figma to pixel-accurate ReactTranslating complex design concepts into high-fidelity, resilient components. Not a screenshot-chase. A faithful port with the edge cases filled in.
• Pragmatic tradeoffsDesign intent, tech debt, velocity. I pick the one that ships a durable answer, not the one that looks best in a review.

Tools & technologies

Tools come and go. The instinct for whento use each one is the part that doesn't.

Currently exploring

The layer I'm working my way into now, the one I think reshapes how UI gets designed and shipped.

• AI interaction designThe new input surface. How users talk to agents, how agents surface state, and what feedback, latency, and microcopy look like when the system is thinking.
• Agent systemsLangChain and LangGraph. Designing the flow of control across tools, memory, and multi-step tasks. Less "chat UI," more state machines with a language model in the loop.
• Retrieval & grounding (RAG)Getting models to answer from your data, not their training set. Schemas, chunking, ranking, and the UX of citations and confidence.
• Lightweight fine-tuning (QLoRA)Task-specific model adaptation for the moments where prompt engineering stops being enough, and the whole product starts behaving differently.