UX Designer

Making a screen look right and getting a user all the way to what they came for sat under one job for a long time. The failure always surfaced in the same place: the mockup review passes and real users stop partway through.

Pagedeck's first signup flow worked like that. Looked at one at a time, none of the five screens had anything wrong with it. Type sizes, spacing and button colors all followed the standard the team had agreed on. Yet only one in three people who started signing up reached the end. The third screen asked for a team name and the email addresses of colleagues to invite, and somebody who came in to try the product alone had no answer to either question. A review that examines one screen at a time can't see that spot; it only shows up with the screens laid out in order.

So a role appeared that owns the flow rather than the screen. The design axis holds nine roles, and what separates them isn't drawing skill but how much of the decision each one carries. The stretch a UX designer carries runs from the moment somebody first arrives to the moment they have the result they came for.

Less than half a day goes into drawing screens. The rest goes into reading, asking and checking. Five kinds of work actually pass through their hands.

1. Mapping the flow. Not a list of screens but the branches and the places people get stuck. For a signup flow that means where the solo visitor and the invited visitor diverge, whether email verification can be deferred, and where somebody who closed the tab picks up when they come back.
2. Reading research. Where a company has a UX researcher running the sessions with users, the designer reads the findings; where it doesn't, they run them. Either way, going through the support inbox is usually their own job. The screen that produced twenty copies of the same question is the one that gets fixed next.
3. Making it clickable. A flow can't be checked from static pictures, so screens get wired together into something you can actually click and five or so people are given a task to complete on it. When three of them stall in the same spot, that spot gets fixed.
4. Defining the states that aren't the happy path. The screen somebody sees with no documents yet, the message when a file is too large to upload, what happens when the network drops. Hand these over unspecified and engineering fills them in by guessing, and the guess is usually a single line reading "an error occurred."
5. Looking again after it ships. Not whether it matches the mockup but whether the flow survived. Screens routinely get split in two or reordered during implementation, and those changes sometimes restore the obstacle that was removed in the first place.

What leaves their hands is drawings; what they decide is order and branching. How many screens there should be, what to ask now and what to defer, which states get defined — those are the outputs of the role.

Nothing in this job closes out alone, so four or five other people come through any given day.

1. The product manager brings what gets built and why. This is also the boundary that rubs most often. What to build is usually the product manager's call and how people reach it is the designer's, but the two don't separate cleanly — a proposal to remove a screen is frequently a proposal to remove a feature.
2. Engineers say whether the flow is possible in the current structure and what it costs if it is. The answer that comes back from here often changes the flow itself.
3. A UI designer turns the flow into actual screens. At companies where the two seats haven't split, one product designer covers both, and where reactions to pressing and dragging are pulled out separately, an interaction designer takes that stretch.
4. A UX writer writes the wording that goes inside the screens. With nobody in that seat, the designer writes the strings from item 4 themselves.
5. Whoever watches the data confirms in numbers whether the revised flow actually improved anything.

At Pagedeck, Noa covers this seat. Mia brings what the quarter is building, Noa comes back with a flow, and Theo attaches the implementation cost. The decision to cut signup down to three screens was made by those three in one sitting.

"This isn't a screen problem, it's an order problem. Let's not ask for the team name up front."

What needs fixing sits between the screens rather than inside any one of them.

"Let me see the flow first and the mockups after. Starting from screens hides the sequence."

Setting the order in which a review happens, so the sequence gets examined before the styling.

"This state isn't in the mockup. What shows up when there are zero documents?"

Only the happy path was drawn and every other state was left blank.

The third one comes up most. At Pagedeck, the first thing Theo asks about any new screen is what it looks like empty and what it looks like when something fails. After Noa started attaching three versions — normal, empty, error — as one set, the number of items bouncing back from review dropped sharply.

The most common assumption is that this is the person who draws well. What leaves their hands really is drawings, so it looks that way. But the decisions the role produces are how many screens to use, what to ask first and what to postpone, and which states to define. A hiring process that looks only at finished screens in a portfolio sees none of that judgment. So interviews ask why the order is what it is and what got cut, rather than admiring the result.

The other frequent belief is that asking users produces the answer. Research gets emphasized often enough to leave that impression. What a user tells you is where they got stuck, though, and never the fix. "The invite screen is annoying" does not lead directly to removing invitations. Build what people ask for literally and you accumulate screens that suit only whoever asked, and six months later the product has forty settings. Research narrows the problem, and the judgment after that stays with this role.