UX/UI & Product Design

What this area actually covers

Three decisions, made in this order, by people who often do not sit together.

The first is what the product should do and in what sequence a person should do it. That is the UX decision, and it is made out of research, constraints and argument rather than out of pixels. The second is what that sequence looks like and how it responds to touch, hover, keyboard and a screen reader: the UI decision, made out of a visual language, a set of components, and a specification of every state each one can be in. The third is how those two decisions survive contact with an implementation, a component library that already exists, a deadline, and content that is longer and stranger than anything in the mock.

That third decision is the one this section weighs most heavily, because it is where engineers and designers actually meet. A flow can be well researched and a screen beautifully drawn, and the product can still ship with a disabled button whose label is unreadable, a table that has no defined behaviour at 400 pixels wide, and an error message written by whoever implemented the validation. Nothing in the design was wrong. The design simply did not say, and every gap it left was filled at speed by someone with a ticket to close.

The boundary with adjacent areas is worth drawing precisely, because three things get wrongly bundled in here.

Product management is not design, even where one person does both. Product management owns which problems get attention and in what order, and it is accountable for the outcome; design owns the shape of the solution and is accountable for whether a person can actually use it. Interviews conflate them constantly, and a candidate who answers a design question with a prioritisation framework has answered a different question.

Frontend engineering is not design either, though the overlap has grown. Building a component correctly — its state management, its rendering performance, its tests — is engineering. Deciding that the component exists, what variants it has, and which of those variants a given screen should use is design. The interesting roles now sit in the seam, and this section is written for people who work in that seam from either side.

Graphic design and brand are a related discipline rather than this one. A brand system decides how the company looks in the world: logo, marketing typography, photographic treatment, tone. A design system decides how the product behaves. The two share a palette and disagree regularly, most visibly when a brand colour chosen against white gets used behind white text and fails contrast.

Design systems, and what else lives underneath

There is one subsection here at the moment, and it is deliberately the one with the most engineering in it.

Design Systems covers the apparatus a company builds so that repeated interface decisions are made once: the design language and its principles, the tokens that name every colour, spacing step, radius and duration, the component library that implements the language in code, the documentation that says which component applies when, and the governance that decides what may be added. It exists as its own subsection rather than as a chapter of frontend engineering because the hard questions in it are not implementation questions at all. They are questions about an internal platform with unwilling consumers: how much customisation a shared component should expose before it stops constraining anything, how you get adoption from six product teams moving at six speeds, what you do about the team that forked your button, and what actually happens when a token value changes underneath nine applications pinned to four different releases.

Open it expecting three recurring shapes. There is the API design shape, which is the same problem as any library boundary: every prop you expose is a promise you will be asked to keep, and a component with six boolean flags nominally supports sixty-four combinations, most of which nobody will ever render and one of which is broken. There is the platform-adoption shape, where the honest answer is always that adoption is earned by making the system cheaper than not using it, and paid for with migration work the platform team does itself rather than files as tickets for others. And there is the propagation shape: a token is a global variable with no compiler watching it, so changing one is a release to consumers you cannot see.

The two areas the section covers that are not yet subsections of their own are accessibility and user research, and both appear throughout the fundamentals sheet for this section. Accessibility is treated here as a design constraint rather than as a testing activity: which contrast pairings a token set has to guarantee, which states a component must define before it can be called finished, and why a keyboard pass takes two minutes and finds a disproportionate share of real failures. The engineering-side counterpart — enforcing compliance across many teams with tooling in a pipeline — lives in the frontend section, and the two are meant to be read together rather than one instead of the other. User research is treated as a question of what each method can prove: generative work tells you what problem exists and for whom, evaluative work tells you whether a specific solution works, and reporting one as the other is the most common way a team convinces itself it has validated something it has only demonstrated.

Where it sits in a real system

Follow one change. Somebody believes there is a problem. Research either confirms, reframes or kills that belief, and the reframing is the valuable outcome rather than the confirmation. A design candidate gets drawn, usually assembled from components that already exist, and it is tested against people who are not on the team. What survives becomes a specification: not a picture, but the picture plus every state, every breakpoint rule, the copy for each error, and which token each colour came from. Engineering implements it, mostly by composing existing components, occasionally by needing something the system does not have — and that branch is the slow one, because it goes through the design system and comes out at whatever pace consumers upgrade. The screen ships, instrumentation observes what people actually do, and that observation is supposed to feed back into what the team believes about the problem.

flowchart TD
    A["Problem believed"] --> B["Research: confirm<br/>or reframe"]
    B --> C["Design candidate<br/>from existing components"]
    C --> D{"Covered by<br/>the system?"}
    D -- yes --> E["Product code"]
    D -- no --> F["Token or component<br/>release, then upgrades"]
    F --> E
    E --> G["Shipped screen"]
    G --> A

The edge worth staring at is the one from the shipped screen back to the belief at the top. Almost every team draws that loop and almost none traverses it, so what shipped never revises what they think the problem is, and the next cycle begins from the same assumptions with another feature attached. The second thing to notice is the asymmetry at the decision node: the left branch ships this week and the right branch ships when the last consumer upgrades. That asymmetry is the whole mechanism by which design systems fall out of step with the products they describe, because a team under deadline pressure will always push a change down the fast branch even when it belongs in the system.

The handoff step deserves its own picture, because the failure there is social rather than technical. Nobody withholds information deliberately; the design simply answers the questions it was drawn to answer, and the rest are resolved in a chat thread that never gets written back into the source.

sequenceDiagram
    participant D as Designer
    participant S as Design system
    participant E as Engineer
    participant Q as Review
    D->>E: Screens plus states and tokens
    E->>S: Which component covers this?
    S-->>E: Existing variant, or nothing
    E->>D: What happens at 400px wide?
    D-->>E: Answer, in a chat thread
    E->>Q: Built screen, real data
    Q-->>D: Long content and empty states break it

Look at the two round trips in the middle rather than the first message. Each one is a question the specification could have answered and did not, and the answer arrives somewhere that is not the design file, so the next engineer to build a similar screen asks it again and may get a different answer. Handoff quality is best measured by how many of those arrows exist and how many of the replies get recorded, not by how thoroughly the mock was annotated.

The vocabulary you will hit on day one

Six words carry most of the weight, and each is used loosely enough elsewhere that it is worth pinning down before the questions start.

The affordance and signifier pair looks like pedantry and is the most practically useful distinction on the list, because it separates two different bugs with two different fixes. "They did not know they could tap it" is a missing signifier and is repaired by adding a cue. "They tapped it and nothing happened" is a broken affordance and is repaired in code. A team without the vocabulary argues about whether the design is unclear.

Who does this work

A product designer is the generalist and the most common title. The work is a sequence of small negotiations: understanding a problem well enough to argue about it, drawing something, showing it to people, revising it, then specifying it in enough detail that an engineer does not have to guess. A realistic day is more conversation than drawing. The strongest ones are distinguished by what they cut rather than by what they draw.

A UX researcher does the research as a discipline rather than as an activity squeezed between design tasks. They plan studies, recruit participants, run sessions without leading them, synthesise findings that survive challenge, and — the part that separates good from mediocre — get findings in front of the decision early enough to change it. In smaller organisations there is no researcher and the product designer does an honest amateur version, which is far better than none.

A design systems engineer or design technologist builds and maintains the shared component library and the token pipeline. This is a platform engineering job in everything but name: versioning, deprecation, migration tooling, release notes with visual deltas attached, and the diplomacy of an internal product whose users can always choose not to use it. It suits engineers who like design and designers who can write production code, and it is the most reliably in-demand role in this whole area.

A content designer owns the words: labels, button verbs, empty states, and above all error messages. Interface copy carries more of the usability than the visual design does, and it is the part most often filled in as placeholder during implementation and never revisited. Where no such role exists, the default of "whoever typed it" is what produces four names for one concept on a single screen.

An accessibility specialist sets standards, audits against them, and trains the people who will make the same mistakes again next quarter. The specialist role exists mostly in large organisations and in regulated or public-sector contexts; elsewhere the work is distributed, which usually means it happens to whatever degree the design system has baked in.

Design managers and heads of design specify and defend the work rather than producing it: hiring, allocating designers against a roadmap, running critique so it stays useful, and arguing for research budget in rooms where it is the first thing cut.

Demand, adoption and how that is changing

Steady is the honest description, with the demand distributed unevenly across the roles above rather than rising or falling as a block.

Three forces hold it up. The first is that design systems have become infrastructure at any company with more than a handful of product surfaces, because the alternative — every team rebuilding a date picker — is visibly more expensive. That has created a durable engineering-adjacent role which did not really exist a decade ago, and it is the part of this area where hiring is strongest. The second is accessibility regulation. Public-sector procurement in several jurisdictions requires a conformance claim, and legislation and litigation have made accessibility a compliance matter rather than a matter of goodwill, which turns it into funded work with a named owner. The third is that multi-platform delivery multiplies the value of a single source of design decisions: three platforms rendering the same product from one token pipeline is an argument that survives a budget review.

Two forces push the other way, and it is worth being candid about them. Generalist mid-level design work is the part most exposed to tooling that produces plausible-looking screens quickly, because assembling a competent layout from a known component library was always the most mechanisable part of the job. What does not mechanise is deciding which problem is worth solving, judging what a research finding actually licenses you to conclude, and owning the consequences of a decision. Candidates whose portfolio consists of screens rather than decisions are competing in the exposed part of the market. And the classic separation between UX and UI as two job titles has largely collapsed into product design, with the specialisms re-forming around research, systems and content instead.

The direction of travel is towards the seam. Roles that combine design judgement with the ability to work in the codebase — design systems engineer, design technologist, the frontend engineer trusted to own a component's accessibility — are growing faster than either pure discipline. That is also why this section sits among the engineering disciplines rather than apart from them.

What makes it hard

The first difficulty is that the feedback signal is weak and slow. A backend engineer who breaks something gets a failing test, a 500, or a page. A designer who makes a screen 15 per cent harder to understand gets nothing at all: support tickets that nobody attributes, a conversion rate that drifts within noise, and a team that has grown used to the flow. Developing judgement in a domain with weak feedback takes far longer than in one with a compiler, and it is why experience is not substitutable here.

The second is that almost everything true about an interface is a property of a pair or a context rather than of a thing. Contrast is a property of a foreground against a background, so a token reviewed alone can break four screens nobody opened. A label is only ambiguous in the presence of the other label near it. Spacing communicates grouping only relative to the other spacing on the screen. This is why design review by inspection of individual elements finds so little, and why reviewing a built screen with real data at a width nobody designed finds so much.

The third is that a design is a specification of a continuum but is drawn as a handful of points. Two mocks at two widths imply nothing about the space between them, and one state out of eight implies nothing about the other seven. Every gap is filled by someone else, later, under time pressure — which is the mechanism that turns a coherent design into an inconsistent product, and it shows up on exactly the widths and states nobody reviewed.

The fourth is that the shared layer has consumers you cannot see. Once a token or a component is published, its behaviour is depended upon by applications on several versions at once, and there is no type error when a value changes meaning. Getting good at this is mostly getting good at propagation: aliases instead of renames, contrast pairings asserted as tests where the tokens live, visual deltas published with each release, and an inventory of who is on what.

The fifth is political and the one nobody warns you about. Design work is evaluated by people who all believe they have taste, which means every decision is contestable by anyone in the room in a way that a choice of data structure is not. Doing this well requires being able to convert a preference into a claim about a user and a situation, and to hold that claim under pressure without becoming precious about the drawing.

Why study it

Study it if you build interfaces and keep receiving designs you have to interpret. The return is immediate and specific: you stop guessing what the disabled state should be, you know which questions to ask before you start, and you can tell the difference between a design that is incomplete and one you have simply not read properly. Engineers who can hold this conversation end up owning more of the product than engineers who cannot.

Study it if you maintain or are about to build a design system, because the failure modes are extremely well documented and almost entirely social. Nearly every abandoned design system was abandoned for funding, staffing or governance reasons rather than technical ones, and knowing that in advance changes what you build first.

Study the accessibility material regardless of your role. It is the part of this area with actual rules, it is small enough to learn properly, and the failures are the ones with legal and human consequences rather than aesthetic ones. It is also the highest-yield interview preparation here, because the answers are checkable and most candidates are vague.

Do not study this expecting it to be the fastest route into a design job if you do not already have one. Hiring in design turns on a portfolio that demonstrates decisions with evidence and outcomes attached, and no amount of vocabulary substitutes for having shipped something and being able to say what you got wrong. If your goal is that job, build and ship one small real thing, research it properly, and use this material to make sense of what happens. And if you are a backend or infrastructure engineer with no interface work in your future, the honest advice is to read the accessibility group and the handoff group and skip the rest.

Your first hour

Pick a screen in a product you use daily and did not build. Then do four passes, in this order, writing down what you find as you go.

Put the mouse away and complete one whole task using only Tab, Shift-Tab, Enter, Space and the arrow keys. Note every control you cannot reach, every point where you cannot see where focus is, every place the tab order jumps somewhere the layout did not suggest, and whether a dialog lets your focus escape behind it. Under WCAG at AA, keyboard operability and a visible focus indicator are both requirements rather than refinements, so anything you find here is a genuine defect and not a matter of taste.

Second, check contrast on four specific pairings with any contrast checker: the body text, the placeholder text inside an input, the label on a disabled control, and white text on the brand colour. AA asks for 4.5:1 for normal-size text and 3:1 for large text and for the boundaries of interface components. Two of those four pairings fail in most products, and they are always the same two.

Third, resize the window slowly from full width down to about 320 pixels rather than jumping between the usual breakpoints, and watch what happens to any table or sidebar in the region between the widths somebody clearly designed. Then paste 200 characters into every text field and see what breaks.

Fourth, write the specification the team should have had for that one screen. One page, in prose: every state each interactive element can be in, what the layout does in each region as width falls, the exact error copy and where it appears, what the empty state says, and which colour and spacing values are repeated often enough that they ought to be tokens.

flowchart TD
    A["Pick one screen<br/>you did not build"] --> B["Keyboard-only pass"]
    B --> C["Contrast on four pairings"]
    C --> D["Resize slowly to 320px"]
    D --> E["Paste 200 characters<br/>into every field"]
    E --> F["Write the one-page spec"]

The artefact at the end is that one page, and it is worth keeping. It is simultaneously the thing a design handoff should contain, a defect list you could file today, and — if you can talk through why each item on it matters to a specific user in a specific situation — most of a critique round answer.

What this is not

It is not visual polish. The largest usability wins in most products come from removing a step, cutting a field, fixing a label and rewriting an error message, none of which change how anything looks in a portfolio screenshot. A candidate who treats this area as styling will describe restyling when asked about outcomes.

It is not a component library. A library is the coded implementation; the system is that plus the reasoning about when to use what, plus the governance that decides what gets added, plus the funded team that keeps it alive. Forty components with no guidance about which of three cards applies produces visual consistency without behavioural consistency, which users experience as a product that looks like one thing and behaves like several.

It is not user validation. Research that sets out to confirm a design will confirm it, and a usability test on something already frozen is a demonstration. The point of research is to be able to change what happens next, which means it has to arrive before the decision it is meant to inform.

It is not the same as accessibility conformance testing. Automated checks catch a useful but limited slice — missing alternative text, contrast on plain backgrounds, some structural problems — and are silent about whether a label makes sense, whether the focus order matches the visual order, or whether the flow can actually be completed with a screen reader. Passing the automated suite is the beginning of the work.

And it is not opposed to engineering constraint. The best design work in this area is done by people who know what a component already does, what a token change costs, and what will happen to the layout when the content arrives in German. A design that ignores the implementation gets reinterpreted; a design that understands it gets built.

The specification is the design. The picture is only the part of it that is easy to show.