Reduce cognitive load. Then ship it.
Process should be visible enough to align a team and light enough that it never becomes the work. Here's how I move a problem from ambiguity to something shipped, measured, and maintainable — the same process I've written about publicly since 2019.
Clarity before cleverness
Every screen has a cognitive budget. My first pass usually removes more than it adds — fewer decisions per step, one obvious next action.
Systems, not screens
I design the pattern and the states behind it, so the tenth screen a team ships costs less than the first and still looks like it belongs.
Shared ownership
Research, critique and decisions happen in the open with product and engineering. Alignment early beats persuasion late.
Designer who codes
I prototype in HTML and CSS when a static frame can't answer the question, and I speak the constraints engineers actually live with.
The process, step by step
Discovery
What is the scope, who is it for, and how will we measure success? I run discovery on four fronts at once — business, user, development and market — so the direction is aligned before anyone draws a screen.
Wireframes
Architect the solution. I map the choices a user can take along the branches of each action's lifecycle, then define the options, context and interactions available in every section.
Mockups
What the product actually looks like given everything gathered so far — including the states teams usually discover in QA, and the responsive behaviour they discover in production.
Prototypes & UAT
Interactive prototypes detail the nuance a static frame can't. I demo them in person whenever possible — sending a file to try alone robs you of the subconscious, real-time reactions.
Ship & learn
Design does not end at handoff. I pair with engineers through build, QA the details, then watch behaviour and feed what we learn back into the system.
Sprint cadence
Design stays one cycle aheadRuns at least one full cycle ahead of development, so kickoff materials are approved, ticketed and ready.
Day 1, week 1 — Feature discovery: what goes into the next release, what is iteration vs. from scratch, and what the engineering implications are for components and the API.
Day 4, week 1 — Wireframe review: functionality and layout. Does this work technically while still hitting the business KPIs?
Day 4, week 2 — Mockup & prototype review: full feature design submitted for final approval. Tickets go to development the following Monday.
Only features fully scoped and approved by both business and engineering enter a development sprint.
Day 1, week 1 — Sprint kickoff: which features are in, how they break into tickets, and a design overview so everyone shares the same picture.
Day 3, week 2 — Code freeze, QA and UAT: finalized tickets pushed to staging, QA pass, stakeholder approval, release scheduled.
Anatomy of a ticket
A ticket should carry enough information for a developer to understand what is happening, why, and who takes the action — without a follow-up meeting.
Who is doing what — “As a {user type}, I want to be able to {take an action}.”
The exact conditions that make the feature correct, including the branch cases: new account vs. existing record, valid vs. invalid input.
Measurable milestones inside the ticket, doubling as the specific items QA tests.
Pixel-accurate UI, an interactive demo of the real behaviour, the full flow through every stage, and a video or gif of any animation.
Working with engineers
A spec sheet ships with every design, so developers never guess at color codes, sizes, spacing or fonts — and assets are exported in each platform's format of choice.
Every scenario gets its full flow. Developers need to know what comes before and after each screen, whatever the user chooses; the biggest handoff failure is one party assuming scope is implicit.
Component states are specified up front: default, empty, no-results, valid, invalid and error — plus breakpoint, aspect-ratio and orientation behaviour.
Animations arrive with keyframes, timing, assets, colors and sizes, plus a real-time preview. Motion is code that has to be triggered — nothing about it is trivial.
Nothing beats a documented design system. I favour tools where developers can inspect native designs and pull CSS, JSON and assets directly.
I sit in refinement and estimation. Knowing what is expensive changes what I design.
How I measure success
Task completion and time-on-task for the core workflow, measured before and after.
Support volume and error rates — the most honest usability signal in operational software.
Adoption of system components across teams, as a proxy for delivery speed.
Business outcome the work was funded for: conversion, transactions, retention, revenue.