My UX design process

Every engagement starts with a joint read of the problem across product, engineering, and users. I map the existing system — data models, APIs, constraints, and the codebase's real seams — before sketching a single screen. This upfront technical grounding is what stops designs from being 'beautiful but infeasible' and shortens the round-trips with engineering later.

Qualitative interviews and contextual inquiry pair with quantitative signal — funnels, event logs, support tickets, session recordings. I look for the pattern in the data that a single interview can't show, then triangulate it against what users say. The output is a small, ranked set of jobs-to-be-done, not a 40-page report.

I translate research into a decision doc: which problems are worth solving now, what we're deliberately not doing, and the measurable outcome we're chasing. This is where 'data-driven' becomes real — hypotheses are written with the metric they'll move and the threshold that counts as success.

Low-fidelity flows first, then component-level design in the existing system. I prototype the risky parts — the interaction, the empty state, the error path — not the happy path everyone already agrees on. AI-assisted prototyping speeds up variant exploration; peer review keeps it honest.

Usability tests on the prototype, then instrumented A/B or staged rollouts on the build. I write the analysis plan before the test runs so the result can't be rationalized after the fact. Failed tests are the point — they're the cheapest way to learn.

Design work isn't done at handoff — it's done when the metric moves. I stay close through launch: watching the dashboards, reading support tickets, and shipping the small follow-up fixes that turn a good release into a durable one.