Process

Design in the browser,not in a deck.

I work in code from day one — you review live URLs, not static files. Four phases, roughly six weeks, weekly deploys the whole way through.

How design shows up

From research to handover

01

Research & audit

I study what already exists before designing what comes next.

02

Copy + structure

Content hierarchy and information architecture, in writing.

03

UX in the browser

Flows and states built as working pages, not static mocks.

04

Frontend build

Production code — components, tokens, motion, accessibility.

05

QA + handover

Edge cases closed, docs written, support window after ship.

The process

Brief to launch

Every project is different, but the rhythm is usually the same: get clear, move fast, build properly, then tighten until the work feels ready for the real world.

Week 1

Phase 01 - Align + Map

Before any design happens, I need the real problem — which is rarely what the brief says. I audit the existing product, talk to whoever owns the outcome, and we agree in writing on what done looks like.

Typical outputs

  • Scope in writing: outcomes, not a feature list
  • Audit of the live product with what's worth keeping
  • Success criteria we both signed
  • Repo, deploy pipeline, and first URL
Week 2—4

Phase 02 - Design + Iterate

I design in the browser, not in Figma. You get clickable flows built with real components at real widths — because a static comp hides every problem that only shows up when content changes or the viewport shrinks.

Typical outputs

  • Information architecture and user flows
  • Working screens, already responsive
  • Empty, loading, and error states
  • Weekly deployed URLs for feedback
Week 4—6

Phase 03 - Build + Connect

Design and code move as one. I ship production-ready components weekly — not prototypes you hand to someone else. Every Friday ends with something live you can review on a real URL.

Typical outputs

  • Production frontend, component by component
  • Design tokens and a system your team can extend
  • Micro-interactions and motion, not just layouts
  • Integration with your backend or CMS
Final stretch

Phase 04 - Refine + Ship

The part that decides whether the work outlives the engagement. Performance pass, accessibility audit, edge cases closed, and documentation written so the next person doesn't reverse-engineer my reasoning.

Typical outputs

  • Lighthouse scores: performance, accessibility, SEO
  • Component and pattern docs
  • Handover session with your team
  • Two-week support window post-launch

Timelines flex with scope — a single flow is faster than a design system, a marketing site shorter than a product surface.

Our tech stack

The tools behind the process

I keep the stack flexible, but these are the tools I use most often across design, build, and delivery.

How we stay close

Async work, clear live touchpoints

I like fast progress — a mix of async updates, focused calls, shared files, and tight feedback loops. I can plug into your existing workflow or run a lightweight structure on my side.

01

Kickoff

One call at the start to find the real constraint and agree on what done looks like.

02

Shared thread

One channel for everything — questions, updates, feedback. No context split across tools.

03

Weekly updates

What shipped, what's next, what I need from you. Written, async, never a meeting.

04

Live review

You review the actual URL, not a screenshot. Comment on the real thing whenever suits you.

05

Handoff

Docs, a walkthrough, and reasoning behind the non-obvious calls — so it survives me.

06

Support

I stay available after launch. Questions, tweaks, edge cases — I don't disappear on day one.

How we stay aligned.I don't vanish for two weeks and come back with a big reveal.

Tell me whatyou're building.

A short call to scope the work, or see how I engage.