The work of deciding what a product does, in what order a person does it, and how that decision survives being implemented by someone else. Design systems, accessibility and user research are the three parts of it that engineering interviews reliably examine.
Assumes you know: Enough HTML and CSS to read a component's markup and see where its styling comes from, Having used one design tool well enough to build a multi-screen flow, A product you have shipped, or watched being shipped, with real users on the other end
Overview
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.
There is one subsection here at the moment, and it is deliberately the one with
the most engineering in it.
Subsection
What it is for
Design Systems
Component libraries, design tokens, governance, and how a design decision gets made once rather than per screen
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.
Loading diagram…
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.
Loading diagram…
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.
Term
What it means precisely
Where people get it wrong
Design system
Language, tokens, coded components, docs, governance, and the team that maintains them
Called a Figma file, or a package on the registry — those are two of its outputs
Design token
A named binding of a design value that consumers reference by name, not by value
Treated as a variable rename rather than as a global with no compiler watching it
Semantic token
A token named for its role, such as text-link or background-danger
Named for appearance instead, so the name becomes a lie the day the colour changes
Affordance
What an object makes possible
Used interchangeably with the visible cue that advertises it
Signifier
The perceptible cue that tells a person an affordance is there
Removed by flat visual styles, leaving things clickable but not looking clickable
Information architecture
How content and functions are organised, labelled and related, independent of any screen
Mistaken for navigation design, which is one expression of it
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.
Loading diagram…
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.