Glossary · 95 terms
Design and research terms, in plain English
The vocabulary of product design teams, user research and A/B testing, explained without jargon. Each entry gives you a one-line answer first, then the detail, an example and the mistake people most often make with it.
Roles and teams
Who does design work, how teams are shaped, and how big they should be.
Design and product work
The activities that fill a design or product week, from discovery to launch.
Value and outcomes
What design work buys a business, and how to tell a real number from folklore.
Research methods
Ways to learn how people think and behave before you build.
Experimentation
Testing changes with real traffic, and reading the result honestly.
A
A/B test
An experiment that shows two versions of something to randomly split groups of users, to measure which one performs better.
ExperimentationAgreement score
For one card in a card sort, the percentage of participants who put it in its most common group. High agreement means people see it the same way.
Research methodsAI evals
Systematic tests that measure whether an AI feature gives good answers, run every time the prompt, model or data changes.
Design and product workB
Benchmark
A reference point you compare against, such as a typical allocation for a role, a competitor's score or last quarter's conversion rate.
Value and outcomesBuild vs buy
The decision between building a capability in-house and buying an existing product, weighed on cost, control, speed and focus.
ExperimentationC
Card sorting
A research method where participants group a set of items into categories that make sense to them, to inform how a site or app is organised.
Research methodsClosed card sort
A card sort where participants place items into categories you have already defined. It tests whether a proposed structure makes sense.
Research methodsCompany stage
Where a company is in its life, from finding product-market fit to running many teams on one product. Each stage needs a different design team.
Roles and teamsCompetitive analysis
Studying how competitors and adjacent products solve the same problem, to learn what users already expect and where there is room to differ.
Design and product workComponent library
A collection of reusable interface building blocks, such as buttons, inputs and cards, available in design files and in code.
Design and product workConfidence interval
A range of plausible values for the true effect of a change, such as 'conversion up by between 0.4 and 2.1 per cent'.
ExperimentationConsistency
Similar things looking and behaving the same way across a product, so people can apply what they learned in one place everywhere else.
Value and outcomesConversion rate
The percentage of people who complete a goal, such as buying, signing up or upgrading, out of everyone who could have.
Value and outcomesCorrelation vs causation
Two things moving together (correlation) does not prove that one causes the other (causation). Only a controlled test can show cause.
Value and outcomesCost of change
The idea that a problem costs more to fix the later it is found: little in design, more in development and most after release.
Value and outcomesCraft
The quality of the making itself: how well a design is executed in its detail, from spacing and type to motion, copy and edge cases.
Design and product workCustomer satisfaction (CSAT)
A measure of how happy customers are with a product or interaction, usually the share who rate it 4 or 5 on a five-point scale.
Value and outcomesD
De-risking
Reducing the chance that a product bet fails, by testing its riskiest assumptions before investing heavily in it.
Value and outcomesDelivery velocity
How quickly a team turns decisions into shipped work. Design affects it through clear specs, shared components and fewer late changes.
Value and outcomesDendrogram
A tree diagram from card sort analysis that shows how items cluster, from pairs that almost everyone grouped together up to broad sections.
Research methodsDesign critique
A structured session where designers review each other's work against its goals, to improve it before it ships.
Design and product workDesign debt
The accumulated cost of shortcuts and inconsistencies in a product's design, which makes every future change slower and the experience worse.
Value and outcomesDesign handoff
Passing a design to engineering with everything needed to build it: specs, states, assets, behaviour and the reasoning behind decisions.
Design and product workDesign manager
The person responsible for a team of designers: their growth, their hiring and the quality bar, rather than designing screens themselves.
Roles and teamsDesign maturity
How well a company uses design: from treating it as decoration at the end, to involving it in strategy from the start.
Roles and teamsDesign QA
Checking the built product against the design before it ships, to catch differences in layout, behaviour, content and states.
Design and product workDesign ROI
The business return from investing in design, such as higher conversion, lower support costs or faster delivery, compared with what the design work cost.
Value and outcomesDesign system
A shared set of reusable components, patterns, rules and documentation that teams use to build a product consistently.
Design and product workDesign systems designer
A designer whose users are other designers and engineers: they build and maintain the shared components and rules a whole product is made from.
Roles and teamsDesign tokens
Named values for basic design decisions, such as colours, font sizes and spacing, shared between design files and code.
Design and product workDesigner-to-engineer ratio
How many engineers each designer supports. It is the most common starting point for deciding how big a design team should be.
Roles and teamsDiminishing returns
Each extra unit of effort adds less value than the one before. The tenth hour of research in a week teaches you less than the first.
Value and outcomesDirectness
In tree testing, the share of participants who reached the answer without going back up the tree. It shows how confidently people found it.
Research methodsDomain expert (SME)
Someone who knows what correct looks like in a specialised field, such as medicine, tax or airline pricing, and checks that the product gets it right.
Roles and teamsDouble-barrelled question
A question that asks about two things at once, such as 'Was the app fast and easy to use?', so a single answer cannot be interpreted.
Research methodsE
Engineers-per-PM ratio
How many engineers each product manager supports. Published figures range from about 3 to 20, and product type moves the number more than company size does.
Roles and teamsEvidence quality
How much you can trust a claim, judged by who measured it, how, on how many people, and whether anyone can check the source.
Value and outcomesExperiment readout
The write-up of what an experiment or analysis found, what it means, and what the team should do next.
Design and product workF
Fidelity
How closely a sketch or prototype resembles the finished product. Low fidelity is rough and quick; high fidelity looks and behaves like the real thing.
Design and product workFirst-click testing
Showing people a screen and a task and recording where they click first. If the first click is right, they are far more likely to succeed.
Research methodsG
Generalist and specialist
A generalist covers the whole design process; a specialist goes deep on one part of it, such as research or design systems.
Roles and teamsGo-to-market (GTM)
Everything needed to get a product or feature in front of the right customers once it is built: positioning, pricing, launch plan, sales and support readiness.
Design and product workGolden dataset
A curated set of example inputs paired with expert-approved correct outputs, used as the answer key when evaluating an AI feature.
Design and product workGroup product manager
A product leader who owns a portfolio of squads, often with a P&L: they set strategy for their area, choose its bets and develop the PMs who run them.
Roles and teamsH
Head of design
The leader who owns the design function as a whole and earns design a seat in the decisions made before anyone writes a brief.
Roles and teamsHead of product
The leader who owns product strategy for the whole company, the operating model the product org works by, and the hiring bar for every PM.
Roles and teamsHybrid card sort
A card sort that starts with some categories but lets participants add their own, testing a draft structure while leaving room for disagreement.
Research methodsI
Ideation
Generating many possible solutions to a problem before choosing one, so the team is not stuck with the first idea that came up.
Design and product workIndividual contributor (IC)
Someone whose job is doing the work themselves rather than managing people. In design, every role below manager is an IC role.
Roles and teamsInformation architecture (IA)
How content and features are organised, grouped and labelled so people can find what they need.
Design and product workK
L
Leading question
A question worded in a way that suggests the answer you want, such as 'How much did you enjoy the new feature?'
Research methodsLoaded question
A question that contains an assumption the respondent may not agree with, so any direct answer accepts it. 'Why do you prefer our app?' is loaded.
Research methodsM
McKinsey Design Index (MDI)
A score from McKinsey's 2018 study of 300 public companies, which found that top design performers grew revenue and shareholder returns much faster than their peers.
Value and outcomesMinimum detectable effect (MDE)
The smallest improvement a test is designed to reliably detect. Choosing it is a business decision about which changes are worth knowing about.
ExperimentationO
Open card sort
A card sort where participants create and name their own groups. It shows how people would organise the content from scratch.
Research methodsOpportunity cost
The value of the best alternative you give up when you choose something. Engineering time spent on internal tools is time not spent on the product.
ExperimentationOutcome vs output
Output is what a team ships; an outcome is the change it causes, such as more customers finishing checkout. Outcomes are what matter.
Value and outcomesP
P-value
The probability of seeing a difference at least as large as the one you observed if there were actually no difference between the versions.
ExperimentationProduct analyst
An analyst who turns product data and requirements into decisions a squad can act on: metrics, analyses, user stories and the read-out of experiments.
Roles and teamsProduct backlog
The ordered list of work a team could do next, with the most valuable items at the top and ready to start.
Design and product workProduct designer
A designer who owns the end-to-end experience of a product area, from understanding the problem through to checking what engineering built.
Roles and teamsProduct discovery
The work of deciding what to build: understanding the problem, the people who have it and whether a solution is worth building, before committing engineering time.
Design and product workProduct manager (PM)
The person accountable for whether a product area moves its business metric: they decide which problems to solve, in what order, and check that it worked.
Roles and teamsProduct owner (PO)
The person who owns one squad's backlog: they turn the roadmap into user stories and acceptance criteria and decide what goes into each sprint.
Roles and teamsProduct roadmap
A plan of what a product team intends to work on and roughly when, and the reasoning for choosing those problems over others.
Design and product workProduct trio
The product manager, designer and tech lead who share responsibility for what a team builds and why.
Roles and teamsPrototyping
Building a working simulation of a design, from paper sketches to clickable mockups, to test an idea before it is built for real.
Design and product workR
RACI matrix
A table of decisions against roles that marks who is Responsible, Accountable, Consulted and Informed for each one, so nobody has to guess who decides.
Roles and teamsRetention
The share of customers who keep using or paying for a product over time. Its opposite, churn, is the share who leave.
Value and outcomesRework
Work that has to be done again because it was wrong the first time, such as rebuilding a feature after users could not use it.
Value and outcomesS
Sample size
How many users or sessions a test needs before its result can be trusted. It depends on your baseline rate and the smallest effect you care about.
ExperimentationSimilarity matrix
A grid showing, for every pair of cards in a card sort, the percentage of participants who put them in the same group.
Research methodsSocial desirability bias
People's tendency to give the answer that makes them look good rather than the true one, for example over-reporting how often they exercise or read.
Research methodsSpan of control
How many people report directly to one manager. For design managers, five to eight is the usual healthy range.
Roles and teamsSquad
A small, long-lived, cross-functional team, typically engineers plus a product owner or manager and a designer, that owns one part of the product end to end.
Roles and teamsStaff designer
A senior individual contributor who works across teams on problems nobody owns, buying leverage for the organisation rather than extra output.
Roles and teamsStakeholder alignment
Getting the people who influence a decision to agree on the problem, the goal and the plan, so the work is not undone later.
Design and product workStatistical power
The chance that a test detects a real effect when there is one. Tests are usually planned for 80 per cent power.
ExperimentationStatistical significance
A result is statistically significant when it would be unlikely if there were no real difference, typically less than a 5 per cent chance.
ExperimentationT
Task success rate
The percentage of participants who complete a task correctly. It is the most basic measure of whether a design works.
Research methodsTeam capacity
The total amount of work a team can take on in a period. It is fixed, so giving more time to one activity always takes it from another.
Roles and teamsTechnical debt
The future cost created by taking shortcuts in code or architecture: work that will have to be redone, and that slows everything built on top of it until it is.
Design and product workTechnical product manager
A product manager whose product is technical, such as an API, a data platform or internal tooling, and whose customers are usually other teams.
Roles and teamsTechnical program manager
The person who owns how and when complex work lands across several teams: dependencies, timelines, risks and release coordination. They do not decide what gets built.
Roles and teamsTime allocation
How a person's working week is divided between activities, such as research, UI design, reviews and meetings.
Roles and teamsTotal cost of ownership (TCO)
The full cost of a tool or system over its life, including set-up, licences, maintenance and the staff time it needs, not just the purchase price.
ExperimentationTree testing
A method for testing navigation: participants see only a text version of your menu and click through it to find where they would complete a task.
Research methodsU
UI design
Designing the screens and controls people interact with: layout, components, states and how each element looks and behaves.
Design and product workUsability testing
Watching real people try to complete tasks with a design or product, to find where they get confused or stuck.
Research methodsUser flow
The sequence of steps someone takes to complete a task in a product, including the decisions and branches along the way.
Design and product workUser research
Studying the people who use a product, through interviews, observation, testing and surveys, to understand what they need and where they struggle.
Design and product workUser story
A short description of a piece of work from the user's point of view, such as 'As a traveller, I want to save a search so I can book later', plus the criteria that say when it is done.
Design and product workUX researcher
A specialist who studies how people think and behave so the team can decide what to build before engineering spends time on it.
Roles and teamsV
Rather put these ideas to work?
The free tools use most of these terms in practice: plan a design team, run a card sort or tree test, check your survey questions, or read an A/B test properly.