Imagine: the team is about to redesign the onboarding in the app. The task sounds like "make it prettier and clearer." Two weeks later the mockups are ready, and a month later it turns out that the share of users reaching their first payment hasn't grown — it has dropped. Because the original hypothesis wasn't about beauty, but about the fact that people don't understand the value of the product on the third screen, and redrawing the first screen didn't solve that problem.
This is where the boundary lies between "drawing pretty pictures" and product design. A product designer starts with the task and data, not with a mood board: who the user is, what they're trying to do, where exactly they drop off, what hypothesis we're testing, and by what metric we'll know it worked. The interface is a consequence, not a starting point.
Below is a substantive breakdown of the subject: how the working cycle is structured, at which step the mechanism most often breaks, and what really distinguishes those who reach the result.
How the working cycle is actually structured
Let's take a concrete task: in a B2B meeting room booking service, employees abandon the form at the time selection step. The hypothesis is that the form is too long. Before changing anything, a practitioner does three things.
- Looks at the data. In analytics they see: out of 1,000 form opens, 640 reach date selection, 380 reach time selection, 210 reach confirmation. The biggest drop-off is between date and time.
- Checks the cause through interviews. Five short conversations show: people don't understand which time zone the time is shown in, and they're afraid of taking someone else's slot.
- Tests the hypothesis with a prototype. Not a final mockup — a clickable prototype with one change: an explicit time zone label and highlighting of occupied slots.
If the team had immediately redrawn the form to be "shorter," they would have reduced the steps but not removed the uncertainty — and the drop-off would have remained. The cost of the mistake here isn't a spoiled mockup, but a month of designer, developer, and analyst work wasted.
Where the mechanism itself breaks
Even the right cycle fails — not because of beginner mistakes, but because conditions change. Four typical scenarios.
The data stopped being representative
You collected interviews with active users, but you're making a decision about new ones. Or the metric is calculated across everyone, including bots and internal accounts. How to notice in advance: check which segment you're looking at, and whether it matches the segment you're designing for. If it's too late — recalculate the metric on the right sample and re-check at least 3–5 interviews specifically with that segment.
The rule stopped being applied
The design system requires using a ready-made component, but the task is about a non-standard scenario that isn't in the system. A "workaround" begins, and six months later the product has three versions of the same element. What to do: record the exception explicitly, with the reason and a deadline, and create a task to extend the system. Otherwise exceptions become the norm.
The deadline passed, and the hypothesis wasn't tested
The prototype wasn't tested in time, the release is scheduled, and the design goes into development "as is." How to notice in advance: if a week before release there hasn't been at least one run with users — the risk has already materialized. The honest next step is to plan a post-release measurement on the same metric, not to pretend the hypothesis is confirmed.
The tool stopped working
Mockups are in one format, development is in another; the design system was updated, but the mockups weren't. The "lossless" handoff breaks not at the drawing stage, but at the handoff stage. Check first: whether the tokens (colors, spacing, typography) match in the mockup and in the code, and who is responsible for synchronization.
Three learning paths and their cost
| Path | Time | Money | Main risk |
|---|---|---|---|
| Self-study through articles and videos | 6–12 months | Low | No feedback: logic errors only become visible on a real project |
| Course with solution reviews | 3–6 months | Medium | Requires discipline — no one will make you finish the case |
| Practice in a team (internship, junior position) | 3–6 months | Often they pay you | Hard to get in without a portfolio; they teach what the team needs, not what the market needs |
The self-study path is cheaper but hits a barrier: there's no one to verify your solution with. You can draw a beautiful prototype and never learn that the hypothesis is formulated in a way that can't be tested. A course closes exactly this gap — with feedback on your decisions and breakdowns of calculations using examples. An internship gives real context, but rarely a systematic foundation.
Who this path suits and who it doesn't
It suits those who are ready to start with the question "why," not "how pretty." Those who aren't afraid to calculate and defend a decision in front of product and development. And those who understand: a portfolio of three well-analyzed cases with logic is stronger than ten beautiful screens without explanations.
It doesn't suit those who want only visuals and freedom without metrics — here you'll have to justify every decision. And those who expect a quick entry: the first months go into research and analysis, not drawing.
The course Profession: Product Designer UI/UX breaks down exactly these calculations and gives feedback on your decisions — from interviews and information architecture to handing mockups off to development. If you want to verify your path against practice rather than assembling it piecemeal from articles — start there.
You can start here: Profession: Product Designer (UI/UX).