Product design
Interface design an engineer can build, often because I am that engineer.
What this work is
I design the flows and the screens, usually because I am also the one building them. The files stay close to the code: a small component set in Figma, not a library someone else has to reinterpret. Empty, error, and loading states are part of the design, not a later pass.
I take design-only work when the brief is already clear: who it is for, what the screen has to do, and what already exists. If those are still loose, I'd rather settle them before drawing a full set of screens. A review of a product you already have is the same work, on a smaller brief.
This covers
- User flows
- Interface design
- Prototypes
- Small design systems
- UX reviews of an existing product
- User flows
- Interface design
- Prototypes
- Small design systems
- UX reviews of an existing product
- User flows
- Interface design
- Prototypes
- Small design systems
- UX reviews of an existing product
- User flows
- Interface design
- Prototypes
- Small design systems
- UX reviews of an existing product
- User flows
- Interface design
- Prototypes
- Small design systems
- UX reviews of an existing product
When it fits
You need the interface decided properly, whether or not I am the one writing the code.
You leave with
- A flow someone can follow, and files a developer doesn't have to reinterpret.
- Fewer dead ends in the product
- Empty, error and loading states included
- A component set that stays small
Projects in this area
The other three
Start on Product design.
Say what you need this to do, who it is for, and what already exists. I reply by email, and we agree scope in writing before work starts.