20 UX Terms Every Designer Should Know

If you’re working in design and can’t explain these terms to a stakeholder, you’ve got a problem. Not a career-ending one—but you’ll waste time clarifying what you mean instead of actually designing.

These aren’t just vocabulary words. They’re the shared language that makes handoffs smooth, meetings faster, and your work more credible. Learn them. Use them. You’ll instantly sound like you know what you’re doing.

:::note[TL;DR]

End User – The actual person using your product, not your boss or client
User-Centered Design – Design decisions driven by user needs, not assumptions
Persona – Fictional representation of your target user
Pain Point – The specific problem your user needs solved
User Journey – The path someone takes to accomplish a goal
Wireframe – Skeleton layout, no styling, all structure
Prototype – Working model to test ideas early
Mockup – High-fidelity visual, looks like final product
A/B Testing – Compare two versions to see what wins
Accessibility – Design works for everyone, including disabilities
Affordance – Visual clue that tells you what something does
Cognitive Load – How much mental effort something requires
Heuristic Evaluation – Expert review against usability principles
Flat Design – Simple, 2D, no shadows or gradients
Responsive Design – Layout adapts to any screen size
Progressive Disclosure – Show more as you need it
Microinteraction – Small animations that provide feedback
Usability – How easy is it to use?
Design System – Reusable components and guidelines for consistency :::

The Terms That Actually Matter

1. End User

The actual person who will use your product. Not your client. Not your project manager. Not your mom.

If you’re designing a fitness app for a pharmaceutical company, your client is the pharma company. Your end user is the 45-year-old trying to track their steps after a knee replacement. Different needs. Different constraints.

Why it matters: Every design decision should serve the end user. When you confuse “what the client wants” with “what the user needs,” you get products that look great in presentations but fail in the real world.

2. User-Centered Design (UCD)

An iterative process where user needs come first in every phase. You research, prototype, test, and repeat—not once, but until it actually works for real people.

The scenario: You’re building a banking app. Your stakeholder wants a dark theme because “it looks premium.” UCD says you test that assumption. Turns out older users can’t read the light gray text. Premium look, terrible usability. Back to the drawing board.

3. Information Architecture (IA)

How you organize, structure, and label content so people can find what they need. Think site maps, hierarchies, and navigation systems.

Real example: Amazon’s product categories are IA at scale. They spent decades refining how to group millions of products so you find what you want without thinking. That’s not accident—it’s architecture.

4. Persona

A fictional character that represents your target user. It sounds like creative writing, but it’s actually one of your most powerful design tools.

A good persona includes:

Name and photo (makes it real)
Demographics (age, job, income)
Goals and frustrations
Tech comfort level
Typical context ( commuting? office? phone?)

The scenario: You’re designing a grocery delivery app. You create “Busy Brenda,” a working mom who shops on her phone during her 15-minute lunch break. Now every decision has a face: Does Brenda have time for this? Will she understand this without reading a manual?

5. Pain Point

A specific problem that causes friction in a user’s journey. Not “users are unhappy”—specific, solvable problems.

Good pain point: “Users abandon checkout when asked to create an account” Bad pain point: “Users don’t like the checkout”

Good pain points lead to solutions. Bad ones lead to redesigns that fix nothing.

6. User Journey

The complete path a user takes to accomplish a goal. Not just the happy path—the detours, the mistakes, and the back button mashing too.

Example: Booking a flight isn’t just “search → select → pay.” It’s:

Open app (while waiting for the bus)
Search “NYC to London” (wait, do I want direct?)
Compare 47 options (okay, this one has the best timing)
Select seats (no, not the middle row)
Enter passenger details (why does it need my frequent flyer number?)
Enter payment (wait, is my credit card saved?)
Get confirmation email (phew, done)

Every step is an opportunity to lose the user.

7. Wireframe

A low-fidelity, black-and-white skeleton of a page. No colors, no fonts, no decoration—just layout and structure.

When to use: Early in the process. When you’re figuring out “where does the navigation go?” and “is this too cluttered?”

When not to use: When presenting to clients who expect pretty mockups. They’ll think you haven’t done anything.

8. Prototype

A working model of your design—clickable, testable, improvable. Lower fidelity than a mockup, but functional enough to learn from.

Low-fidelity prototype: Paper sketches clicked through with a stranger High-fidelity prototype: InVision prototype that feels almost like the real thing

9. Mockup

A high-fidelity visual that looks exactly like the final product. Colors, typography, spacing—all done. Ready for developer handoff.

The difference:

Wireframe = “Where things go”
Prototype = “How things work”
Mockup = “How things look”

10. A/B Testing

Showing two versions to different users and measuring which performs better. Not guessing—which actually wins.

Real example: Google tested 41 shades of blue for their search button. They measured click-through rates and went with the winner. That’s data-driven design.

Designing for people with disabilities. Visual, auditory, motor, cognitive—everyone should be able to use your product.

Real constraints:

Color blindness (don’t use red/green alone to signal status)
Screen readers (alt text, semantic HTML)
Keyboard navigation (can’t rely on hover states)
Motor issues (large tap targets, no time-limited interactions)

12. Affordance

A visual cue that tells you how to use something. A button looks clickable. A link looks tappable. A door handle looks pullable.

Bad affordance: A text that says “click here” but looks like plain text Good affordance: Blue underlined text with a hover state change

If users have to think about what to do, your affordances are weak.

13. Cognitive Load

The mental effort required to complete a task. Too much information, too many steps, too many decisions—that’s high cognitive load.

The restaurant menu example: A 3-item menu = low cognitive load. A 47-item menu = high cognitive load (see Hick’s Law from our UX Laws article).

Your job isn’t to challenge users. It’s to make their lives easier.

14. Heuristic Evaluation

A structured review where experts check your design against established usability principles (like Nielsen’s 10 heuristics).

The quick version:

Can users recover from mistakes?
Is system status always visible?
Do you prevent errors or help users recover?

15. Flat Design

A style that uses simple 2D elements, solid colors, no gradients, no shadows. It’s minimalism’s practical cousin.

Where you’ll see it: iOS, Windows, most modern apps. It loads fast, scales well, and focuses on content over decoration.

16. Responsive Design

Your layout adapts to any screen size—desktop, tablet, phone. Not optional anymore. Mandatory.

The scenario: You design a beautiful desktop dashboard. User opens it on their phone during a commute. If they can’t read it or tap anything, your design failed.

17. Progressive Disclosure

Show simple content first, reveal complexity as needed. Don’t overwhelm users with everything at once.

Example: Advanced settings in a settings menu. You see the basics first. Click “Show advanced” to see more. That’s progressive disclosure in action.

18. Microinteraction

Small, single-moment feedback—liking a post, toggling a switch, completing a form field. They’re tiny, but they make the product feel alive.

Why it matters: That little heart animation when you like something? That’s a microinteraction. It tells you “it worked.” Without it, interfaces feel dead.

19. Usability

Can people actually use your product to accomplish their goal? Without frustration? Without a manual?

The test: Give a stranger your app. Watch what happens. If they can’t figure it out in 30 seconds, your usability has problems.

20. Design System

A collection of reusable components, guidelines, and principles that ensure consistency across your product. Think buttons, color palettes, typography rules—all documented.

Why it matters: Without a design system, every page looks different. With one, you move faster and maintain consistency. Figma’s design system, Material Design from Google, Apple’s Human Interface Guidelines—all are formal versions of this.

FAQ

Do I need to memorize all these terms?

No. But you should be able to explain any of them in a meeting without pausing. That’s the bar.

What’s the difference between UX and UI?

UI = how it looks. UX = how it works. You can have a beautiful interface that’s impossible to use (bad UX). You can have a functional interface that’s ugly (bad UI). Both matter.

When should I create a persona?

Early. Before you design anything. Personas come from user research—interviews, surveys, observations. Build them from real data, not assumptions.

Should I always do A/B testing?

Not always. A/B testing is expensive in time and traffic. Use it for high-impact decisions (like redesigning checkout) where the winner makes real money. Don’t A/B test everything.

How do I know if my design is accessible?

Use tools like WAVE, Axe, or Lighthouse. Better yet, test with actual users who have disabilities. Automated tools catch maybe 30% of accessibility issues.

Summary

End User is who actually uses your product—not your client
User-Centered Design puts user needs first, always
Information Architecture organizes content so people find it
Persona gives your target user a face and story
Pain Point is the specific problem to solve
User Journey maps the full path to a goal
Wireframe is low-fi structure, Mockup is high-fi look
Prototype tests functionality before full build
A/B Testing uses data, not opinions
Accessibility ensures everyone can use your product
Affordance tells users what to do visually
Cognitive Load is the mental effort you put on users
Design System keeps everything consistent

These terms aren’t just vocabulary—they’re the foundation of professional design work.

20 UX Terms Every Designer Should Know