By Mehdi HassanDesigners use a lot of shorthand, and founders often nod along in reviews without being sure what a 'modal', a 'token' or 'progressive disclosure' means for the product. This glossary covers the product design vocabulary: the terms you'll hear while building a SaaS app, a dashboard or a mobile product. Each term has a plain definition and an example from a typical SaaS product.
It sits under our SaaS product design guide, which explains how these pieces fit together into a process. Marketing, SEO and website terms such as conversion rate or schema markup are defined in our web design, SEO and AEO glossary instead.
What UI/UX terms do founders hear most often?
The UI/UX terms founders hear most are the ones that show up in every design review: user flow, wireframe, prototype, component, state and design system. If you only learn ten words, learn these. They describe what's being shown, how finished it is and what it will take to build.
Term | Plain meaning | SaaS example |
|---|---|---|
UX (user experience) | How it feels and works to use a product, from first visit to daily use. | Whether a new admin can invite their team without asking support. |
UI (user interface) | The visible layer people interact with: screens, controls, text and visuals. | The buttons, inputs and layout of the invite screen. |
User flow | The sequence of steps a user takes to complete one task. | Sign up, verify email, create workspace, invite teammates. |
Wireframe | A low-detail sketch of a screen's structure, without final visuals. | Gray boxes showing where the table, filters and actions sit. |
Mockup | A static, high-fidelity picture of a screen as it will look. | The finished billing page in Figma with real type and color. |
Prototype | A clickable simulation of a flow, used to test or demo before building. | A Figma link where clicking 'Upgrade' opens the plan picker. |
Component | A reusable interface piece built once and used everywhere. | One button component used across every page. |
State | A version of a component or screen in a given condition. | A project list that's empty, loading, failed or full. |
Design system | The shared set of components, rules and tokens a product is built from. | Buttons, inputs, colors and spacing documented in Figma and code. |
Handoff | Passing finished design to developers for building. | A Figma file plus specs sent to the engineering team. |
Which research and discovery terms should you know?
Research and discovery terms describe how designers learn what users need before deciding what to build. They matter because they tell you how confident a team is in a direction: an idea backed by usability testing is a different bet from one backed by a hunch.
Term | Plain meaning | SaaS example |
|---|---|---|
User research | Any structured way of learning from real users, by talking to them or watching them. | Five calls with ops managers about how they track approvals today. |
User interview | A one-to-one conversation about a person's past behavior and problems. | Asking a customer to walk through the last time an invoice went wrong. |
Usability testing | Watching people try to complete tasks with a design to find where they struggle. | Asking testers to export a report and noting where they hesitate. |
Persona | A profile representing a group of users, their goals and context. | 'Priya, finance lead at a 50-person company, closes the books monthly.' |
Jobs to be done (JTBD) | A framing that focuses on the progress a user is trying to make, not who they are. | 'When month-end comes, I want to reconcile fast so I can report on time.' |
Journey map | A diagram of a user's steps, thoughts and feelings over a longer experience. | From discovering the tool to their first successful payroll run. |
Pain point | A specific problem or frustration a user experiences. | Having to re-enter the same customer details in two places. |
Synthesis | Turning raw research notes into patterns and decisions. | Grouping 40 interview quotes into five themes on a board. |
Heuristic evaluation | An expert review of a design against established usability principles. | Checking a settings page for consistency, feedback and error prevention. |
A/B test | Showing two versions to different users and comparing results. | Testing two onboarding checklists to see which leads to more activations. |
To see where research fits in a full build, our guide on how to design a SaaS app from scratch walks through each stage.
What do structure and flow terms like information architecture mean?
Structure and flow terms describe how a product is organized and how people move through it. They come up when a product grows past a handful of screens and people start saying they can't find things. Our guide to SaaS information architecture goes deeper on all of them.
Term | Plain meaning | SaaS example |
|---|---|---|
Information architecture (IA) | How content and features are grouped, labeled and arranged. | Deciding whether 'Integrations' lives under Settings or in the main nav. |
Navigation | The menus and links users rely on to move between areas. | A left sidebar with Projects, Reports and Settings. |
Card sorting | A research method where users group items to reveal how they expect things organized. | Users sorting 25 feature names into groups that make sense to them. |
Happy path | The ideal route through a flow where nothing goes wrong. | A user signs up, connects data and sees a chart on the first try. |
Edge case | An unusual situation the design must still handle. | A workspace with 2,000 members, or a name with 80 characters. |
Onboarding | The first-run experience that gets a new user to value. | A checklist guiding a new account to connect its first data source. |
Activation | The moment a new user first gets real value from the product. | The first report successfully shared with a teammate. |
Progressive disclosure | Showing basic options first and revealing advanced ones on demand. | An 'Advanced filters' link that expands a longer filter panel. |
Which layout and visual design terms come up in reviews?
Layout and visual terms describe how a screen is arranged and how it guides the eye. They're the language of UI feedback. When a designer says the hierarchy is off or the spacing is inconsistent, they mean the screen is harder to scan than it should be, not just that it looks wrong.
Term | Plain meaning | SaaS example |
|---|---|---|
Visual hierarchy | Using size, weight, color and position to show what matters most. | The account balance is larger and bolder than the transaction list. |
Grid | An invisible column structure that keeps layouts aligned. | A 12-column grid used for every dashboard page. |
White space | Empty space around and between elements that improves readability. | Extra space separating the plan cards on a pricing screen. |
Typography scale | A fixed set of text sizes used across a product. | Six sizes from caption to page title, nothing in between. |
Contrast | The difference in brightness between text and its background. | Gray table text checked against WCAG so it stays readable. |
Density | How much information fits on a screen. | A compact table view for power users with tighter rows. |
Responsive design | Layouts that adapt to different screen sizes. | A table that becomes stacked cards on a phone. |
Dark mode | A color theme with dark backgrounds and light text. | A theme toggle that follows the operating system setting. |
What are the common UI component and pattern terms?
Component and pattern terms name the building blocks on screen. A component is one reusable piece, like a button. A pattern is a reusable solution to a common problem, like a confirmation step before deleting something. Our guide to web app UI design shows how they combine on real screens.
Term | Plain meaning | SaaS example |
|---|---|---|
Modal (dialog) | A window that appears over the page and blocks it until closed. | 'Delete project?' with Cancel and Delete buttons. |
Drawer / side panel | A panel that slides in from the side, keeping the page visible. | Clicking a ticket opens its details on the right. |
Toast | A small, temporary message confirming an action. | 'Invite sent' appearing briefly in the corner. |
Tooltip | A short label that appears on hover or focus. | Hovering an icon shows 'Export as CSV'. |
Dropdown / select | A control that reveals a list of options to choose from. | Choosing a time zone from a list. |
Combobox | An input that combines typing with a filtered list of options. | Typing a teammate's name to assign a task. |
Command palette | A keyboard-opened search box for jumping to pages or running actions. | Pressing Cmd+K and typing 'new invoice'. |
Data table | A grid of rows and columns for scanning and acting on records. | A customer list with sort, filter and bulk actions. |
Call to action (CTA) | The main action a screen asks the user to take. | 'Connect your bank' as the primary button on an empty dashboard. |
What do interaction and state terms mean for your product?
Interaction and state terms describe what happens when people act and what the product shows in each condition. These are where unfinished designs usually fall short. A design that shows only the full, happy screen leaves developers guessing about the rest, and guesses become bugs.
Term | Plain meaning | SaaS example |
|---|---|---|
Empty state | What a screen shows when there's no data yet. | A projects page that explains what a project is and offers 'Create your first project'. |
Loading state | What users see while content is being fetched. | Skeleton rows that match the shape of the table. |
Error state | What users see when something fails, with a way forward. | 'We couldn't load reports. Try again' with a retry button. |
Success state | Confirmation that an action worked. | A check mark and 'Payment method updated'. |
Microcopy | The small bits of interface text: labels, hints, errors and buttons. | 'Use your work email' under the email field. |
Affordance | A visual cue that suggests how something can be used. | A raised button that clearly looks clickable. |
Optimistic UI | Updating the interface instantly before the server confirms. | A comment appears immediately, then syncs in the background. |
Undo | Letting users reverse an action instead of confirming it in advance. | 'Task archived. Undo' instead of a confirmation modal. |
Most of these are as much about words as visuals. Our guide to UX writing for SaaS covers how to write empty, error and success messages that help. For AI features, the same states multiply, and our guide to AI product UX covers patterns like visible plans and citations.
Which design system and handoff terms matter for the build?
Design system and handoff terms describe how design becomes code and stays consistent as the product grows. They matter to founders because they drive build cost and speed. A product with a clear system ships new screens faster, while one without it re-designs the same button every sprint.
Term | Plain meaning | SaaS example |
|---|---|---|
Design tokens | Named values for colors, spacing, type and radii shared by design and code. | 'color-danger' used for every destructive button and error. |
Variant | A version of a component with different properties. | Primary, secondary and ghost versions of one button. |
Style guide | Rules for visual identity: colors, type, logo and imagery. | A page listing brand colors and when to use each. |
Figma variables | Figma's built-in way to store token values and themes. | Light and dark color sets switched with one setting. |
Dev Mode | Figma's inspection view for developers. | Developers copying spacing values and CSS from a frame. |
Accessibility (a11y) | Designing so people with disabilities can use the product. | Every action reachable by keyboard and labeled for screen readers. |
Role-based access (RBAC) | Showing or hiding features based on a user's role. | Only admins see the billing page. See our roles and permissions guide. |
How do commonly confused UI/UX terms differ?
The most commonly confused terms are near-synonyms that describe different levels of finish or scope. Mixing them up causes real problems: a founder who expects a prototype and receives a wireframe will think the work is behind, when it's simply at an earlier stage.
Pair | The difference | Why it matters |
|---|---|---|
Wireframe vs mockup vs prototype | Structure vs static final look vs clickable simulation | Sets expectations for how finished a review is |
Component vs pattern | One reusable piece vs a reusable solution made of pieces | Patterns need rules, not just parts |
User flow vs journey map | Steps in one task vs the whole experience over time | Flows guide screens, journeys guide strategy |
Persona vs job to be done | Who the user is vs what progress they want | Jobs usually lead to sharper product decisions |
Usability test vs A/B test | Watching why people struggle vs measuring which version wins | One explains, the other counts |
Design system vs style guide | Components, tokens and rules vs visual identity only | A style guide alone won't speed up building |
For example, suppose a design review uses ten of these terms in one sentence
For example, suppose your designer says: 'The wireframe for the invite flow is done, and the prototype covers the happy path, but we still need the empty and error states, and the modal should probably be a drawer so people keep context.'
Translated: the structure of the invite steps is agreed, there's a clickable version for the ideal route, but nobody has designed what the screen looks like with no teammates yet or when an invite fails. They also want the invite form to slide in from the side rather than block the page. That tells you the work is roughly halfway, and that the remaining pieces are the ones developers would otherwise have to guess.
For the principles behind good use of all these terms in complex products, read our B2B SaaS UX principles.
