UI Designer

When a product company had exactly one designer, that person handled the logo, the business cards and the screens. With ten screens in the product, the arrangement worked.

Once the screen count reached the dozens, two kinds of work inside one person started crowding each other out. One is deciding the order in which somebody moves from signing up to getting their first result. The other is turning that order into individual screens, deciding what sits at the top of each and what gets folded away. The two need different raw materials. The first runs on user research and usage data. The second runs on real string lengths, real screen widths, and how a layout behaves when a label turns out to be three words longer than expected.

That is also why meetings used to end in the middle of nowhere. "Should we cut the invite flow from three steps to two?" and "should this button be blue?" in the same half hour produces no decision on either. Answering the first needs more knowledge of what users are trying to do; answering the second needs someone to have already settled what the screen wants read first.

So companies split the scope of the decisions rather than the skills. A UX designer owns the whole path to the goal, and a UI designer owns the translation of that path into screens. What separates the two is not who draws better but how far each one's own authority extends. Keeping them as separate seats is mostly a thing larger organizations do. Below about 100 people, a single product designer covers both.

The day fills up with screen-level decisions, and with recording those decisions in a form the next screen can reuse.

1. Setting the hierarchy within a screen. If four buttons share the same size and color, a person has to read all four. Make one of them solid and the other three get skimmed. Choosing color, type size and spacing is the craft called visual design, and its purpose is deciding what gets read first rather than what looks nice.
2. Drawing every state of a screen. A document list is not one mockup. There is the state with no documents yet, the state while loading, the state where loading failed, and the state where the viewer has no permission. Drawing those four is what stops engineering from inventing them.
3. Working within the design system — the single set of colors, spacing rules and reusable parts the product draws from. If an existing part solves the problem, use it; if not, add a new one deliberately. Defer that call often enough and three years later the product uses seventeen shades of gray with no record of which is correct.
4. Producing mockups and prototypes in a tool. Most of this happens in Figma, and the version that goes into review is usually clickable rather than flat.
5. Answering questions after the handover. Comparing what got built against the mockup and flagging the spot where the padding is off by four pixels or where a label wrapped onto a second line.

At Pagedeck this is Noa's work. Shipping one document-sharing dialog, she first checks whether four permission names fit on one line and how far the list stretches when someone invites ten people. Color comes after that.

The handoffs in and out are fixed, so the same few people show up every day.

1. Work arrives from whoever owns the flow. A UX designer or product designer settles what gets shown in what order, and the UI designer turns that into screens. When a flow arrives only half decided, drawing stalls, and the question has to go straight back rather than getting resolved by guessing on the canvas.
2. Work goes out to front-end developers, who turn mockups into code. That means spacing, state transitions, and how the layout reflows at narrower widths all have to be written down, not implied. This passing-over is called handoff.
3. Copy gets aligned with the UX writer. A button reading "Save" and a button reading "Save changes" produce different layouts, so late copy means redoing the arrangement.
4. Motion and response get split with the interaction designer. What changes and how after a click belongs to them; the screen the change lands on belongs to the UI designer. Where those seats are not separate, one person does both.
5. Scope gets negotiated with the product manager. Saying up front that drawing all four states adds two days is what keeps the schedule honest.

"The flow is as we agreed last week, and Noa is doing the screens."

Confirming where the decision boundary sits on this piece of work.

"There's no mockup for the empty state or the error state. Hand it over like this and engineering will invent them."

One screen is not one mockup.

"This button isn't in the system. Do we register it as a component or keep it as an exception on this screen?"

Deciding now whether this is used once or used forever.

Pagedeck has exactly one designer, so the collision between the two kinds of work is visible in the open. In a week that needs the flow rethought, the screen mockups slip. In a week close to a release, the flow review slips.

Padding and states are what Noa and Theo talk about most. They look at the built screen together and mark where it differs from the mockup, and the culprit is almost never color — it is what happens when text gets longer than the mockup assumed.

The most common misreading is that this is the person who makes things look nice. The output is visual, so the conclusion comes easily. But the test applied to the work is not whether it looks good, it is whether people find what they came for first. Making one button solid in a row of four is not a taste call; it is a decision about reading order. Without that distinction, reviews turn into taste debates. Blue against green goes back and forth and the loudest voice in the room settles it.

The second misreading is counting one mockup as a finished screen. A single image is what shows up in review, so it is easy to count that way. In practice the four states above, plus a narrow-width layout, make one screen five or six artifacts. Count it as one and estimates land about three times off. "Ten screens this week" turns out to mean sixty drawings in a week, which is where a plan quietly stops being real.