Product design

Screens are the visible part. Product design starts earlier, with the questions that decide whether the screens matter at all: who has this problem, how they solve it today, what would make them switch, and what the smallest useful version looks like.

I work as a design partner to founders and product teams, shaping what gets built as much as how it looks. That means sitting in on planning, challenging scope when it grows, and keeping the product simple enough to ship.

• You have an idea and need to turn it into something you can test with users or show investors
• You have a first version and usage is lower than you expected
• Your product has grown feature by feature and new users are getting lost
• You are adding a major new capability and want it to feel like part of the product, not a bolt-on

The earlier I am involved, the more I can save you. A week of research and prototyping before development costs a fraction of building the wrong thing.

Research here is practical, not academic. A handful of interviews, a look at how competitors and substitutes handle the same job, and your own data if you have it. The aim is a short list of insights the whole team agrees on and can act on, written in plain language.

The best research outcome is a decision you would not have made otherwise.

From there, we define the problem, the people it is for and the measures that will tell us whether the product works.

Ideas are tested as prototypes, not debated as slides. Early prototypes are rough and quick, built to answer one question each. Later prototypes are detailed enough to feel real, so feedback from users and stakeholders is about the product rather than the drawing.

When the direction is clear, the work moves to the same standard as my UI / UX projects: every screen, every state and a design system your developers can rely on.