UX/UI
product design

(01) — What is included

What a product engagement contains

• Discovery and user research Interviews, support tickets, the analytics nobody reads. I want the friction you have already paid for, not the friction we imagine in a room.
• Information architecture What content exists, how it groups and what it is called. Half of every "I can't find anything" problem is solved here, before anything is drawn.
• User flows Every path end to end, with its branches, its errors and its way back. Including the paths nobody wants to draw.
• Wireframes and prototypes Cheap, ugly and fast first, so the expensive decisions get made while they are still free. Then a prototype that actually clicks.
• Interface design (UI) Type scale, colour, grid, density, states. The final screen, and also the four unglamorous screens that come with it.
• Design systems Colour and type tokens, a component library with every state written down, and documentation a team of eight can use without asking me.
• Usability testing Five people, real tasks, a report with the fixes ordered by effort. No invented percentages.
• Accessibility, from day one WCAG 2.2 AA review: contrast, keyboard paths, screen readers. A requirement, not a final phase.

(02) — How it goes

(03) — The proof

Every case tells what it started from, what was decided and what came out — including the decisions I would take differently today.

(04) — The tools

What it gets made with

Figma

Wireframes, interface, clickable prototype, component library and variables. It is where the system lives and where your team reviews it.

Adobe XD

Legacy projects that still live there; I migrate them to Figma when it makes sense and maintain them where they are when it does not.

HTML · CSS · JS

Prototypes in the browser when motion, performance or real copy is what decides the design.

Angular · React

When the engagement runs all the way to implementation, I build it myself.

AI

Research synthesis, fast variants and code scaffolding, with my own judgement on top. How I use it.

(FAQ) — Frequently asked

What people ask before hiring me

• 01

  What does a product designer actually do?

  Decides how a digital product works before it exists, and makes sure it keeps working afterwards. In practice: research who is going to use it and against what friction, order the content, draw the flows and the screens, build a prototype, test it with real people and hand over a documented system so the team can keep growing it without breaking it. It is not about making things pretty: it is about deciding what goes in, what comes out, and in what order it appears.

• 02

  How is that different from plain UX/UI design?

  Scope. UX and UI are two parts of the job — how it behaves and how it looks; product design adds the why and the when: what business problem it solves, for whom, what ships first and how you measure whether it helped. On small teams it is usually the same person; on mine, it always has been.

• 03

  Do you work with teams that already have a design system?

  Yes, and that is the common case. I come in, read the library, find the three components that got duplicated while nobody was looking, and work inside the system rather than against it. If it needs extending, I extend it and document the reasoning behind every new piece.

• 04

  Do you hand over the code as well, or the design only?

  Both, and that is the difference. I write the front-end for almost everything I design — Angular, React, HTML, CSS and JavaScript — not because designers must code, but because the last ten per cent (the focus rings, the motion, how a layout holds up against a very long word) is where design either happens or quietly disappears.

• 05

  How do you measure whether a redesign worked?

  Before we start we agree on two or three numbers that are already being measured: task completion rate, support tickets of a specific kind, time to first useful action. If nothing is measured, the first phase is to measure. A redesign with no starting figure cannot be defended, only opined about.