Every state, not just the happy path
Empty, loading, error, partial, and the overflowing case where someone's company name is sixty characters. These are most of the real usage and most of the usual gaps.
UI/UX Design for Products
Design that survives contact with implementation, because the person designing it also builds it.
The expensive failure in product design is not an ugly interface. It is a beautiful Figma file that cannot be built as drawn — a layout that collapses at 360px, states nobody designed, a type scale that needs six custom sizes, and a developer quietly improvising the other half of the product under deadline.
I design and build, which removes that gap. Every screen I hand over has been checked against what it costs to implement, and the edge cases that get discovered in week four of development — empty, loading, error, too-long, too-many — are drawn up front rather than invented later.
What you get
A token system, not a swatch page
Colour, spacing, radius and type defined as tokens that map directly onto CSS variables, so the build inherits the system instead of approximating it.
Accessibility checked at design time
Contrast ratios verified against WCAG AA, visible focus states designed rather than left to the browser, and touch targets large enough to hit on a phone.
Responsive behaviour specified
What happens to a data table at 360px is a design decision. If the file does not answer it, a developer will, at 11pm.
Prototypes for the risky flows
Clickable prototypes for onboarding and checkout — the flows worth testing with five real users before they are built.
Handover a developer can use
Named components, documented spacing, exported assets, and a walkthrough. Or I build it myself, which removes the translation step entirely.
Tools and methods
How the work runs
Understand the job the product does
Who uses it, how often, under what pressure. Software used sixty times a day by a trained operator should not look like a consumer landing page.
Structure before surface
Information hierarchy and flows first, in grey. Colour decisions made before the structure works tend to be defending a layout rather than serving it.
Design the hardest screen first
The densest table or the most conditional form. If the system survives that, the marketing page is easy.
Validate, then systemise
Test the risky flow, fix what fails, and only then expand the component library across the rest of the product.
Typical projects
SaaS dashboards
Dense, data-heavy interfaces that stay readable with real volumes rather than the four tidy rows in the mockup.
Mobile app design
Native-feeling iOS and Android screens that respect each platform's conventions instead of shipping one layout twice.
Marketing and landing pages
Pages built around a single conversion, designed to load fast rather than to win a design award.
Redesigning what exists
Improving an interface incrementally, without a big-bang relaunch that retrains every existing user overnight.
Questions
Can you design without building it?
Yes. The deliverable is a Figma file with components, tokens, responsive specs and a handover walkthrough for your developers. I will also stay available during the build for the questions that always come up — that costs little and prevents most of the drift between file and product.
We have no designer and no design system. Where do we start?
Not with a design system. Start with the two or three screens that carry the product, get them right, and extract the system from what those screens actually needed. Systems built up front tend to be large, speculative, and half unused.
Do you do user research?
Lightweight, proportionate research: five-user usability tests on the flows that matter, and analysis of whatever analytics or support tickets you already have. I do not run large quantitative studies — for that you want a dedicated researcher, and I will say so rather than sell you a weak version of it.
How do you handle dark mode?
As a token-level concern from the start, not a late inversion. Both themes are designed deliberately, because naively inverting a light palette produces grey text on grey surfaces and contrast failures that only appear on real screens.
What if we do not like the direction?
Direction is agreed early and cheaply, on a small number of key screens, before any of it is systemised across the product. Revisions at that stage are expected and included. The sequence exists so that disagreement happens while it is still inexpensive.
Related services
Tell me what you are building
A short call costs nothing, and if your project is a better fit elsewhere I will say so. Replies usually within 24 hours.
Get in touch