What does a product designer actually do?

A product designer works out how a digital product should help someone complete a task, then makes that experience clear enough to test and build. The work includes understanding users, deciding how information fits together, designing interactions and checking whether the result works. Screens are one of the outputs. The decisions behind them are the larger part of the job.

For a founder, the useful question is what uncertainty the designer will remove. A new product might need a clearer definition of its first useful workflow. An established product might need to untangle permissions, improve setup or make a complicated task understandable. Those are different briefs, even when both end with a polished interface.

1. What happens before anyone draws a screen?

Start with a user, a task and the conditions around it. Who needs this? What are they trying to finish? What do they do today? Where does the existing process break? Support conversations, product data and interviews can help answer different parts of that picture. A founder’s explanation is useful context, but it is not a substitute for seeing the work happen.

The GOV.UK discovery guidance offers a useful principle: understand the problem and its constraints before committing to a solution. For a commercial product, that means looking at the business model and technical dependencies alongside the user’s needs. A desirable feature is not automatically something the company can operate or support.

2. What should a product designer deliver?

• A clear account of the problem, the people affected and the evidence behind it.
• Flows showing how a task starts, progresses, fails and finishes.
• Interface designs using real content and representative data.
• A prototype at the level of realism needed to answer the open questions.
• States, behaviours and priorities that an engineer can implement.
• A record of what was tested, what changed and what still needs checking.

The exact files matter less than whether the next person can act on them. A beautiful page with no loading, empty or error state leaves decisions for engineering to invent. A diagram of every possible state can be equally unhelpful if it never identifies the path that matters first. The designer should make the system understandable and the next build manageable.

3. How is product design different from UX and UI?

UX usually describes the broader experience of using a product; UI focuses on the controls, layout and visual language of its interface. Product design commonly includes both, together with product priorities and delivery constraints. Titles vary between teams. Ask about responsibility and examples of work rather than assuming the job title guarantees a particular skill set.

A designer working on a dashboard should be able to explain why particular information is prioritised, what happens when the data is missing and how someone moves from noticing a problem to resolving it. Colour and spacing support that sequence. They cannot supply the sequence on their own.

4. When should engineering get involved?

Bring engineering into the conversation while the options are still open. A flow may depend on data you do not have, a slow integration or permissions the current system cannot express. Discovering that in a finished handover makes every option more expensive to change.

Design review should continue into the working build. Check the actual layout, keyboard behaviour, responsive states and real data. A design file cannot show a slow response from an external service or prove that focus returns to the right control after a dialog closes. These details belong to the experience too.

5. What should you ask before hiring a product design studio?

Ask how the team learns about users, who works with engineering and what happens after the first prototype. Ask to see decisions, not only final screens. A useful case study explains the problem, the constraints and how the team reached the outcome without pretending every choice was obvious from the start.

At Refract, product design and engineering sit together. A product sprint gives a contained problem a practical starting point: examine the existing flow, prototype a direction, test it with users and agree what should be built next. Bring the awkward workflow and the real content. That is enough to start a useful conversation.

6. Questions

Does a product designer write code?

Some do, and some work closely with engineers. What matters is that the design accounts for real technical constraints and is checked in the working product. Coding ability alone does not establish research or design skill.

Do we need product design before building an MVP?

You need enough design work to agree the user, the core task and the behaviour you intend to test. That can be a focused piece of work; it does not require designing every future feature.

Can a product designer improve an existing product?

Yes. Existing behaviour, support requests and user workarounds provide a concrete starting point. Scope the work around a task or failure rather than a vague request to modernise the interface.