What product designers actually do all day
The job is framing, flows, states, and handoff — not pixel polish. What you need to know to start, and what you can safely defer.
In one sentence
Product design is mostly deciding what problem is worth solving and specifying how the solution behaves in every state — the visual craft is real, but it is the last and smallest part of the job.
Why it matters
The portfolio version of this job is a sequence of beautiful screens. The employed version is a Tuesday spent working out whether a feature is worth building at all, a Wednesday drawing the four error states nobody asked for, and a Thursday in a call about what the API can actually return.
That gap matters for two reasons. If you are trying to get into the field, you are probably practising the wrong thing — a portfolio of polished screens with no visible reasoning is the most common reason a strong-looking application gets passed over. And if you are hiring or working alongside designers, expecting the job to be screen production is how you end up with a team that is fast at producing screens nobody needed.
How it works
The day-to-day surface area, roughly in the order it tends to happen:
Framing. Turning "engagement is down" into a problem statement specific enough to design against. This is where most of the leverage is and where the least time is usually spent.
Discovery. Interviews, session recordings, support tickets, analytics — whatever gives you evidence about what people actually do rather than what the roadmap assumed.
Flows before screens. The structure — what steps exist, what happens on each, where branches occur. A flow that is wrong cannot be rescued by any amount of interface work, and it is much cheaper to find out at this stage.
Interface and states. The screens, and then the parts around the screens: empty, loading, error, permission-denied, too-much-data, name-is-84-characters. A frame showing the ideal case is roughly a third of the specification.
Handoff and follow-through. Documenting behaviour, answering the questions that surface during the build, and reviewing what actually shipped against what was designed. Work that stops at file delivery reliably ships as something else.
Measurement. Deciding before launch what would count as it having worked, instrumenting for it, and reading the result honestly afterwards.
In practice
What to learn first, if you are starting:
- Flows and states. Every product has them and most designers under-specify them. Being thorough here makes you immediately useful to engineers.
- One tool, properly. Figma. Components, auto layout, and variants — enough to build something maintainable rather than a folder of loose frames.
- Spacing, hierarchy, and type scale. The visual fundamentals that fix most rough work, in that order. Color and illustration come much later.
- How to run a usability test. Five people and a prototype. It is the fastest way to develop judgement, because it is the fastest way to be shown you were wrong.
- Enough of the business to know what the product is being judged on.
What you can safely defer: motion and micro-interaction craft, design system architecture, research method depth beyond interviews and usability tests, and almost all tooling that is not Figma. These matter, but they matter at a scale you will not encounter for a while, and they are far easier to learn once you have shipped something.
Common pitfalls
- Presenting outcomes without decisions. Reviewers are looking for the trade-off you made and why, not the final frame.
- Designing the happy path and treating the rest as an engineering concern. The states are the design.
- Optimising the interface for a problem that has not been framed. Fast, confident work on the wrong problem is the most expensive failure mode available.
- Treating handoff as an ending. The design is what ships, not what was in the file.
- Waiting for permission to talk to users. Ten support tickets and one recorded session will change your view of the product more than a month of iteration.
Further reading
The Product Design and UX Design roadmaps on roadmap.sh are a reasonable map of the territory — this site follows their vocabulary. For the framing half of the job, Teresa Torres on opportunity solution trees is the clearest short treatment of connecting an outcome to something you can actually build.