Product Designer

Taking the design job titles a large company has split apart and dropping them into a small company leaves a hole. Having one person design the whole flow and another turn that flow into screens works at a few hundred people. A 45-person company can't hire three designers, and hiring one leaves the question of what to write on the offer letter. The title has to name a seat that owns the whole thing, because at that size that is what the work actually is.

Hiring two into the split roles created a different problem. Ask the person drawing screens why a particular step exists and they can't answer, because it was settled upstream. Ask the person who designed the flow and they can't answer either, because they've never seen that screen. The person who made the decision and the person who rendered it were different people, so every question engineering raised during implementation had to travel through both of them. The handoff cost more than the work.

So a seat appeared that carries everything from problem definition to the screen. It's the most common design title at companies under 100 people, and it's fair to read it as UX designer and UI designer before those two have separated. As headcount grows, research and copy peel off first — three interviews in the morning and screens in the afternoon leaves only the screens with a deadline on them.

Drawing screens takes less than half the day. The rest goes into agreeing on why it's being built this way and confirming that what got built actually holds. Six kinds of work move through a day.

1. Confirming the problem. Reading which step in the funnel leaks, and counting how often the same sentence appeared in last week's tickets. With a figure like 34 percent of signups creating a first document, the job starts with finding where they stop. Two numbers and a ticket count are usually enough to name the broken step.
2. Designing the flow. How many screens, in what order, and where the path branches. A prototype does the work here; hand-drawn sheets shown to five people surface most ordering problems.
3. Drawing the screens. Not from scratch — assembling parts from the design system. Redeciding buttons and inputs each time produces a product running seventeen shades of gray three years later.
4. Writing the copy. With nobody dedicated to it, this lands here too. Replacing "an error occurred" with "this file is over 20MB and can't be uploaded" often cuts more tickets than any screen change.
5. Handing off and answering. The questions increase after the handoff, not before. What shows when the list is empty, where a 40-character name gets truncated, and so on.
6. Watching what shipped. Checking a couple of weeks later whether the number moved on the screen that changed.

In organizations that treat only item 3 as design work, items 1 and 5 end up assigned to nobody. Screens still arrive on schedule, but what those screens were meant to solve doesn't survive anywhere. The schedule still looks healthy, which is what makes the loss hard to notice.

Four people a day, give or take. Looking at Noa at Pagedeck, they split like this.

1. The product manager. With Mia, the work is agreeing on what is being built and why. Narrowing the problem takes the longest of any conversation here, and thin agreement at this stage sends everything downstream back around once.
2. Engineers. With Theo, the work is what's possible and by when. Showing him something before the handoff pays off; discovering that the current structure can't support a screen after drawing all of it wastes the whole drawing.
3. The growth marketer. With Ravi, screens for experiments get divided up. Splitting traffic between two versions means the designer draws one more version.
4. Sales and customer success. The requests Sofia brings arrive shaped like screen requests. Asking what the customer couldn't do, before drawing the screen they asked for, belongs to this seat. A request for a button is rarely a request for a button.

The decision boundary blurs easily. What gets built is the product manager's call; how it looks and in what order it flows is the designer's. The overlap is cutting scope. Whether dropping one of three screens breaks the flow is something the person who drew them knows best, so what to drop gets decided by both.

"The product designer is in on this one from problem definition."

Not a seat that receives a spec and renders it, but one that joins while what to solve is still open.

"All the screens are done, but the empty state and the error copy aren't decided."

Only the happy path has been drawn; the other states are missing.

"This isn't a make-it-prettier problem. It's a remove-one-step problem."

Judging that visual polish won't fix it.

Pagedeck's document sharing flow went this way. Mia brought the problem of a low sharing completion rate, and Noa drew six sheets on paper and showed them to three people from a neighboring team. All three stopped on the permission screen, and the order got reversed on the spot. Polishing the screens started the following week.

The work continued past the handoff. During implementation Theo asked where someone who opens an invite link while logged out should land, and a screen that wasn't in the mockup got added that day.

The most common reading is that this is the person who makes screens look nice. The output is a visible screen, so the assumption comes naturally. But most of the decisions in this seat are about what to remove and what to fold away rather than what to add. Most of the craft is deciding what a reader should read first, which is a decision about the problem rather than about taste. Treat it as a decoration role and the seat stops getting invited to problem definition, which produces well-drawn screens nobody needed.

The other frequent belief is that the job ends at handoff. That's the visible deadline, so it reads as the finish line. But states that aren't the happy path — an empty list, a name that runs too long, a user opening something without permission — arrive in a row during implementation. If the person who can answer those has already moved on, engineers decide by themselves, and two months later the same product shows empty states in three different shapes.