2026
May 11, 2026
Questions Before Pixels
A short handbook for UX in 2026. The bar for "looks good" is now zero. The work that's left is the questioning, before any pixel is drawn.
S
Sascha Becker
Author17 min read
May 11, 2026
A short handbook for UX in 2026. The bar for "looks good" is now zero. The work that's left is the questioning, before any pixel is drawn.
17 min read
In 2026, a competent generator can produce a polished interface in under a minute. Type a prompt, get a layout. Refine the prompt, get a better one. Pick a style, swap a palette, regenerate the empty state. The screen looks fine. It looks like it was designed by someone who knows what they're doing. In a sense, it was.
This has quietly moved the bar for what counts as design work. "It looks good" used to be a meaningful compliment. It signaled craft, taste, hours spent. Today it signals that the tool was used. Polish is no longer a moat. It is a default.
What is not a default is the thinking underneath: whether the screen should exist, where attention is supposed to land when it opens, what the user was doing thirty seconds before they got here, what they will try next, and what the cost is when they guess wrong. None of that gets generated. None of it gets caught by a code review. None of it shows up in a Figma mockup that looks great in isolation.
This post is a handbook for that part. Not the visual layer, the questioning layer. A list of the questions worth answering before any pixel is drawn, plus a short diagnostic for telling a UI fix apart from a real UX fix. It is meant to be re-read, not read once.
Jared Spool has been making the same point for over a decade: UX is the experience the user has, end to end, and UI is one of many surfaces it shows up on.1 A beautiful screen attached to a confused flow is bad UX dressed in good UI. A plain screen attached to a flow that gets the user to their goal in two clear steps is good UX in a t-shirt.
Don Norman, who coined the term "user experience" at Apple in the early 90s, framed it from the start as everything around interacting with a product, not just the screen.2 The screen is one slice. The slice happens to be the most visible one, which is why it absorbs most of the budget and most of the conversations. It is also the slice that's now cheapest to produce.
The trap looks like this. A view feels off. Someone notices. The fix proposed is "let's redesign this card." The card gets redesigned. It looks better. The original problem (users abandoning a flow, missing a button, ending up on the wrong screen) is unchanged, because the problem was never the card. It was the path that led to the card, or the assumption that this card needed to exist at all.
The questions in this handbook are designed to surface that gap before it shows up as a redesigned card.
Most "UX issues" reported by users, support, or stakeholders are described in UI terms, because UI is what they can point at. "The button is hard to find." "The form is confusing." "This page is ugly." A UI-shaped complaint does not mean a UI-shaped fix.
A short diagnostic to run before reaching for Figma:
| If the answer is... | The fix is probably... |
|---|---|
| The user can't find the action they need | UX. Wrong screen, wrong moment, or wrong information architecture. |
| The user finds the action but doesn't trust it | UX. Missing feedback, missing context, unclear consequence. |
| The user triggers the action but lands somewhere they expected | UI polish. The page is functionally correct, the visual hierarchy is off. |
| The user completes the task but says it "feels clunky" | UX. Too many steps, missing defaults, the system is asking the user to think. |
| The user can't tell whether something happened | UX. Missing or delayed feedback, broken loop between action and result. |
| Two screens look almost the same and the user picks the wrong one | UX. Two screens that look the same usually shouldn't be two screens. |
| The screen does the right thing but looks dated | UI polish. Genuinely cosmetic. Treat it as such. |
If most of your "UX problems" land on the UI-polish row, congratulations: you have good UX and a styling backlog. If they land everywhere else, the redesign of any single screen is unlikely to move the metric you care about.
The patch trap
The cheapest fix to ship is "make this control more prominent." It will pass review, it will look like progress, and it will not move the funnel. If a symptom keeps coming back after each round of UI polish, the problem is one layer up: the flow, the entry point, or the existence of the screen itself.
What follows is a working list. Run through it before opening the design tool, not after. Twelve questions, in roughly the order they tend to bite when skipped. Most are unglamorous. The first three are the ones most often skipped, and the most expensive when they are.
The cheapest UI to design is the one you don't ship. Before designing a new view, ask whether the same job could be done by an inline action, a dialog, a default that removes the choice, or by simply not asking. Every new screen is a navigation cost, a maintenance cost, and a place where the user can get lost. The answer is sometimes "yes, it earns its keep." It is far more often "no, this could be a row in the existing list."
Screens are designed in isolation, but they are used in flows. The user did not teleport to your view from a clean slate. They came from somewhere, in a particular state, with a particular intent. If the design assumes a fresh, focused user, it will be wrong about the most common one: the user mid-task, mid-conversation, mid-search, holding a thought they cannot afford to lose. Anchor the screen to the moment, not to the empty state.
Not the feature name. Not the page title. The user's intent, phrased the way they would phrase it. "Pay this invoice." "Find the file I had open yesterday." "Decide whether to renew." If the team cannot agree on the sentence, the screen is going to be a compromise of three different unspoken intents and will serve none of them well.
Every screen has an attention budget. The user spends roughly the first second looking at exactly one thing, then the next two seconds at one or two more.3 If you can't name the first thing, the screen has no hierarchy. If you can name it but it isn't the most important thing for the user's task, the visual hierarchy is wrong, no matter how good the spacing is.
Once the user has oriented themselves, what is the one action you expect them to take? Is it the most prominent control on the screen? Is it labeled in the user's language, not the system's? Is it positioned where the eye will be after the orientation pass? If the next action requires a scan, the design has implicitly decided that "the user will figure it out." That is a hope, not a design decision.
Every interface is designed twice: once for the happy path, and once for the moment a user does the wrong thing. Most designs only ship the first one. The unhappy path is the user typing into the wrong field, clicking the wrong button, navigating away mid-edit, hitting back, double-submitting, denying a permission, losing their connection. Each of these has a recovery cost. Designs that ignore them are designs that work in demos and burn in production.
The cheapest unhappy-path test
Open the screen. Click everything that is not the intended next step. Note what each of those actions costs the user. If any of them lose work, lose context, or land them somewhere they cannot get back from in one step, those are the cases the design needs to answer for. They will happen.
Every form field, every confirmation, every "are you sure?" is a small accusation that the user might not know what they're doing. Some of those accusations are warranted. Most are leftover from the first time the feature shipped and the team was nervous. Audit the things the design asks the user to confirm, repeat, or re-enter. If you cannot defend each one with a real failure mode it prevents, cut it.
The polished mockup shows the screen with three perfectly representative items. Real users see it with zero items on day one, with five hundred items in year two, with a slow API response in week one, and with a 500 error on the day a colleague is depending on them. Each of those states is a real screen the user will see. Designing only the middle one is designing a fiction.
A practical checklist:
Designs that only answer the "happy, full, fast" state pass review and fail in week two.
Action without feedback is the most common bug in interface design.4 The user clicks save, the network round-trips for 800 milliseconds, the screen does nothing, the user clicks save again. Every interaction needs a visible confirmation that the system received it and a visible result when the system has acted. Optimistic updates, inline states, toasts, focus changes: pick one and use it consistently. Silence is not a state.
The design that ends at "the user clicked the button and it worked" is incomplete. After success, the user is somewhere with a new state, a new question, a new next move. Where do you put them? On the same screen with a confirmation? On a follow-up screen with the next likely action queued up? Back where they came from? The post-success moment is one of the highest-leverage moments in any interface, because the user is paying attention and is open to being guided. Most designs waste it.
Not all actions deserve the same weight. Deleting a row of test data and deleting a customer's billing history are not the same operation, and they should not require the same number of clicks or the same kind of confirmation. Reversible, low-stakes actions should be one click and a clear undo. Irreversible, high-stakes actions should be slower on purpose, with a confirmation that includes the specific thing being affected, not "Are you sure?" in the abstract. Match friction to blast radius.
This is the question that makes most of the previous eleven cheap. A single observation session with one real user, doing the actual task on the actual flow, will surface more issues than a week of internal review. The team's intuition about where users will struggle is reliably wrong, because the team built the thing and cannot un-know how it works.5 Five users will catch around 85% of the usability problems on a given flow. One user will catch a third of them. The marginal cost of one user is hours, not weeks. There is no design budget too small for it.
The questions only work if they show up at the right moment. Most teams that try to "do better UX" insert a review at the end, after the design is done. That is the worst time to ask whether the screen should exist. The cost of an answer at that point is throwing the design away.
A better placement, in roughly chronological order:
At the ticket. Before the design ticket gets pulled, the team should be able to answer questions 1, 2, and 3. Should this exist, what was the user doing before, what are they trying to accomplish. If the ticket cannot answer those, refine the ticket, do not start the design.
At the first sketch. Questions 4 through 7 belong with the first low-fidelity sketch. Where the eye lands, what the next action is, what happens when the user is wrong, what the design assumes the user knows. None of these need pixels to answer. They need a whiteboard or a napkin. If you cannot defend the layout in pencil, no amount of polish will fix it.
At the high-fidelity stage. Questions 8 and 9, the empty / slow / broken / full states and the feedback model, belong here. They are easy to skip because they are unglamorous. They are also the questions whose absence shows up first in production.
Before handoff. Questions 10 and 11, the post-success state and the friction calibration, deserve one explicit pass before handing off to engineering. They are often only visible when the screens are looked at in sequence, not in isolation.
Before "done". Question 12, watching one real user. Five if you can, one if you cannot. Before calling the feature done, not after.
A meeting cadence that costs nothing
Add three minutes to your design review: one minute on "what was the user doing before this screen?", one on "what is the first thing they look at?", and one on "what happens when they're wrong?". You will not need a formal process. You will need someone willing to ask those three things every single time, until the team starts answering them unprompted.
If the questions are this obvious, why is most of the work in the industry not done this way? A few honest reasons.
Pretty is legible. Thinking is not. A polished mockup gets praised in a stand-up. A redesigned flow that removed two screens does not. The work that produces the better outcome is invisible, because the artifact is "we shipped less." Teams that reward the thinking out loud get more of it.
The tools shape the work. Design tools are surface tools. They are excellent at producing pixels and indifferent to flows. The path of least resistance in any modern design tool is to make the current screen look better, not to ask whether the current screen should exist. Tools have a gravity, and the gravity is toward the artifact.
Stakeholders ask for screens. "Can you show me a mockup?" is the most common request a designer hears. Almost no one asks "can you show me the user flow before you start mocking?" The default deliverable is a screen, so screens are what get produced. Changing the deliverable changes the work.
The user is not in the room. Most design decisions are made between the people who built the product. They share assumptions the user does not share. Without a voice in the room that is not the team's voice, the team's assumptions become the design.
Process eats craft. When teams notice the gap, the instinct is to add a "UX review" stage to the workflow. Reviews catch a few things, but they do not change how the work is done in the hours between reviews. The questions in this handbook only work if they live in the design stage, not in a separate gate.
None of these are unfixable. They are predictable, and they are worth naming, because every team that tries to raise its UX bar runs into the same five obstacles in the same order.
Generation tools are very good at making interfaces. They are not good, and probably will not be soon, at deciding which interface should exist, which question the user is actually asking, what the user was doing two minutes ago, or what the cost is when they make a mistake. Those decisions are local to the team, the product, the customer, the moment. They are also the decisions that make the difference between a screen that looks designed and a product that feels designed.
The optimistic version of this transition is that the time freed up by no longer having to fight pixels gets spent on the questions in this handbook. The pessimistic version is that the freed time gets spent producing more screens. Which version a team ends up in is not a function of the tools. It is a function of which questions get asked in the room, by whom, and how early.
The work that produces good UX has not changed in twenty years. The work that produces good-looking UI is now nearly free. The two being conflated is the source of most of the confusion in product design today, and it is what the questions in this handbook are designed to separate.
Ask the questions. Keep asking them. The screens will follow.
There's a skill for this
These twelve questions and the UI-vs-UX diagnostic exist as an agent skill.
Install it with npx skills@latest add saschb2b/skills --skill ask-ux or read
the full ask-ux skill.
The canonical case study for why a single bad UX decision can cost more than a multi-year visual redesign. Worth re-reading once a year.
Don Norman, who coined the term at Apple in the early 90s, on why UX was always meant to cover the entire experience, not just the interface.
The 1994 heuristics still hold up. Visibility of system status, match to the real world, error prevention, recognition over recall. A short list every designer should be able to recite.
The classic argument for low-budget usability testing. Five users catch most of the problems. One user catches more than zero. There is no excuse not to test.
Still the most useful single book on usability. The whole thesis is in the title, but the chapters on self-evidence, hierarchy, and testing are the ones to reread.
A reframing of UX as 'help the user become better at their goal,' not 'help the user use the product.' The shift is small, the consequences are large.
Goal-directed design, personas, and the discipline of designing for the user's intent rather than the system's structure. The reference text for designing flows, not screens.
| The user keeps doing the same thing the system warns against |
| UX. The warning is in the wrong place, or the design is fighting the workflow. |