This batch is NNGroup’s accumulated UX Slogans — compressing decades of common sense from usability research into pithy "golden lines" you can stick at your workstation or toss out in review meetings. They are not precise formulas, but mnemonics that remind you not to repeat old mistakes: many principles actually point to the same thing (put users at the center, subtract, use evidence), just tapping you on the shoulder from different angles.
How to read them: group the 19 lines into 5 thematic clusters by their underlying intent, rather than memorizing them in isolation —
- Don’t treat yourself as the user (perspective): you ≠ the user; you must design for them, and they are "efficient people".
- Less is more (restraint + proactive ease of use): cut features, cut options, then proactively polish until the experience feels effortless.
- Communication is design (content + expression): interfaces exist to communicate, not to decorate, show off, or hold back information.
- Understand the problem first (don’t rush to solutions): ask "why" first; don’t jump straight into solutioneering.
- Replace guesswork with evidence (research): if you don’t validate, you’re guessing; look at data, love observing, but the answer is often "it depends".
These slogans are highly intertextual with NNGroup usability testing and the 10 Usability Heuristics (full list of 10 heuristics · application to complex apps · hierarchy of user delight · testing methods: the 5-user rule/recruitment/remote testing/task scenarios/step-by-step tasks/attitude vs behavior/4-step analysis/small-sample bias/competitive evaluation): the heuristics are a "checklist for giving interfaces a health check", while the slogans are "mnemonics that remind the team not to drift in mindset". Jargon is explained inline on first appearance.
1. Don’t treat yourself as the user: four lines on perspective
This cluster is the "foundation" of the whole set of slogans — almost every UX error originates from designers treating their own brain as the user’s brain.
| Slogan (EN / ZH) | One-sentence core mindset | Counterexample |
|---|---|---|
| You Are Not the User You Are Not the User | No one involved in design is an ordinary user: you know the product too well, are too familiar with its architecture; when you judge that something is "easy to find", real users may be getting lost elsewhere | A designer places a menu item somewhere thinking it’s "obviously here", but real users first click the wrong spot → get confused → give up |
| Design for Them, Not for You Design for Them, Not for You | Just as when you cook for a friend you cater to their taste, not only make what you like to eat; don’t be fooled by the "false-consensus effect" | The team makes decisions based on "that’s what I think too", only to find that the user group’s preferences are very different from the team’s |
| UX Is People UX Is People | The core of UX is people (users + the design team), not technology or devices; what determines success or failure is whether workflows/information architecture/copy fit human cognition, not what tech stack is used | The team pours all its energy into showing off technical implementations, ignoring whether the process matches users’ mental models |
| Users Aren't Lazy, They're Efficient Users Aren't Lazy, They're Efficient | When users deviate from your designed path, they aren’t being lazy — they are calculating "is this benefit worth the extra effort?"; you should adapt to them rather than correct them | Labeling users who take a "suboptimal path" as "lazy" causes you to miss the real friction points that should be optimized |
Why this cluster holds: "You Are Not the User" comes from two older lines in the 1993 book *Usability Engineering* —"Users Are Not Designers" and "Designers Are Not Users":
- Users are not designers: you won’t get good design just by asking users "what do you want?" — users have no obligation, nor the ability, to imagine how technology can improve their lives. Identifying latent needs is the job of the UX team, and the method is observing users doing real tasks, and inferring needs from their behavior.
- Designers are not users: the team knows the product too well (and may even have higher intellectual/technical skill levels), so they simply cannot feel the operational difficulty new users face — that’s why you need to do user testing, not rely on "I think".
The "False-Consensus Effect" is a psychological bias: people instinctively overestimate that "others think the same way I do". For example, in politics people may assume relatives and friends share their stance, when they may not. In design, this same bias makes you misjudge that user needs = your own needs.
Three efficient behaviors behind "Users Aren't Lazy"(they look like laziness, but are actually effort-saving tradeoffs):
- Device Inertia: when multiple devices are at hand, users would rather muddle through a task on the current device than switch to the "more appropriate" one — the time and energy of switching isn’t worth it.
- Momentum Behavior: once they have chosen a path, they stick with it, even if it takes a detour, rather than going back to reselect.
- Selective Attention: they only focus on content related to the current task and automatically filter out the rest — this is an attention-saving instinct evolved in humans. → Design countermeasures: lower switching costs, optimize the path users have already chosen (even if it is not the optimal solution), and make task-relevant information prominent enough.
Decision guide: every time you say "users will probably…", mentally replace it with "I will…" — if the sentence sounds suspicious after replacement, then it was suspicious all along; go run a small test (see Cluster 5).
2. Less is more: from "restraint" to "proactive ease of use"
This cluster is about subtraction. But you need to distinguish two levels:Keep It Simple is passive restraint (don’t add things), Make It Easy is active polishing (go smooth out friction) — NNGroup deliberately uses keep (maintain) vs make (cause to become) to draw the distinction.
| Slogan (EN / ZH) | One-sentence core mindset | Counterexample |
|---|---|---|
| Keep It Simple Keep It Simple | The fewer features and options, the more usable the product; every added feature reduces usability a little — this is restraint | Adding core features yields high net benefits early on, but cramming them in later → "Featuritis", a bloated interface |
| Less Is More Less Is More | This does not mean being so minimalist there are no cues, but focusing on "the user’s current core task" and setting a "value threshold" for every new element: if it does not significantly improve task completion, don’t add it | Forcing in components just to "look comprehensive" weakens the prominence of core features |
| More Choices, More Trouble More Choices, More Trouble | The more options there are, the higher the cognitive load, error rate, and abandonment rate; like driving long distances, the more intersections there are, the easier it is to turn the wrong way | Stakeholders pile on features to "look competitive", resulting in tired, lost, churned users |
| Make It Easy Make It Easy | A step further than "Keep It Simple":proactively eliminate friction through repeated iteration until operations are "obvious and effortless" | Stopping design once it is "not complicated", without continuing to polish details, so users still find it awkward |
Why new features hurt usability(mechanism behind Keep It Simple / Featuritis):
- Increased cognitive load: the more elements there are, the more effort users spend scanning the interface and finding target actions.
- Higher error rates: more features → higher probability of misuse and mis-taps.
- Slower efficiency + more complicated documentation: redundant features slow down tasks and make manuals thicker, making it harder for users to find key information.
- Diminishing marginal utility: adding high-priority features early in a product delivers high value with little interference,so net benefit is positive; the later you go, the lower the priority of new features and the more they interfere with core functions,so net benefit can turn negative — at that point, "not adding" is the right call.
Einstein’s often-quoted line hits the nail on the head:"Everything should be made as simple as possible, but not simpler." Simple ≠ cutting features: a product must satisfy both Usability (how easy it is to use) + Utility (whether it is useful) — if it is usable but not useful, users won’t choose it; if it is useful but not usable, users will abandon it.
Why Make It Easy relies on "iteration": usable designs look "obvious", but this natural feel usually hides a huge amount of polishing.Early iterations first eliminate obvious big problems, and once the big problems are removed,finer small problems surface, which you then pick off round by round. So "Make It Easy" is not a task you can ever "finish" — even the best design always has room for further optimization. This line shares the same origin as #8 Aesthetic and minimalist design (signal-to-noise ratio) in the 10 heuristics; see NNGroup usability testing and the 10 Usability Heuristics (full list of 10 heuristics · application to complex apps · hierarchy of user delight · testing methods: the 5-user rule/recruitment/remote testing/task scenarios/step-by-step tasks/attitude vs behavior/4-step analysis/small-sample bias/competitive evaluation).
Decision guide: before adding a new button/field/option, first pass the three value-threshold questions — ① Does it significantly improve users’ ability to complete core tasks? ② Will it make existing key functions harder to find? ③ Is this "what users need" or "what stakeholders want to look comprehensive"? If it fails the three questions, don’t add it.
3. Communication is design: four lines on content and expression
This cluster shifts focus from "how many features" to "how information is conveyed". The core stance:Interfaces exist to communicate with users and help them complete tasks, not to decorate, show off, or hold back information.
| Slogan (EN / ZH) | One-sentence core mindset | Counterexample |
|---|---|---|
| Communication, Not Decoration Communication, Not Decoration | Every element in a digital interface consumes the user’s cognitive budget; when there is too much decoration, users can’t tell what is clickable and what is just pretty | A photography site hid controls for finding and playing content inside decorative elements just to look "cool," which instead got in the way of viewing content. |
| You Can't Impose Joy You Can't Impose Joy | Delight comes from completing tasks efficiently; it cannot be manufactured by shoving in "fun" elements. Flashy design becomes a burden after a few repeated uses. | During the dot-com bubble,Splash Screens: flashy welcome animations slowed down tasks and reduced conversion rates. |
| Brevity is Brilliance Brevity is brilliance | Web users have scarce attention and can leave at any time; the fewer words, the easier they are to read and remember;web copy is usually cut down to half the length of the print version. | Copying long brochure text directly onto a website makes users leave before they have the patience to finish reading. |
| This Is Too Easy to Understand, Said No One Ever"This Is Too Easy to Understand, Said No One Ever" | No matter how expert they are, users prefer clarity and simplicity; don't fear that "being too simple looks unprofessional." | Forcing overly ornate, complex wording when writing content for experts actually erodes trust. |
| Clarify, Don't Mystify Clarify, Don't Mystify | UX is not mysticism; interfaces, copy, and error messages must let users understand functions and outcomes at a glance — don't hold back key information for dramatic effect. | Clickbait"You'll never guess what Celebrity X wore last night": it boosts clicks in the short term, but loses trust and drives users away in the long run. |
Why decoration is a cognitive tax (Communication, Not Decoration): In the physical world, wearing a fancy hat doesn't bother anyone else (no interaction required); but in digital interfaces,on first encounter users cannot tell which elements are functional and which are purely decorative, and every extra decoration adds a guessing cost of "can I click this?" This does not mean "interfaces can't look good" — good typography, contrast, whitespace, and color schemes improve information delivery; but aesthetics must serve communication, and usability must not be sacrificed for beauty.
Why forced joy hurts the experience (You Can't Impose Joy): Users come to a website to get things done, not to "be entertained." Cool animations on splash screens or first clicks may be fun the first time,but with repeated use they quickly become tedious, turn into waiting time, and diverge from user goals. Real delight comes from efficiency + utility + smoothness — making users want to come back, instead of driving them away with flashiness. (This aligns perfectly with Heuristic #8 (Aesthetic and Minimalist Design) and the "four-layer pyramid of delight: delight is not adding sugar, it is removing pain"; see NNGroup Usability Testing and the 10 Usability Heuristics (Full Table of 10 Heuristics · Application to Complex Apps · User Delight Hierarchy · Testing Methods: 5-User Rule/Recruitment/Remote Testing/Task Scenarios/Step-by-Step Tasks/Attitude vs Behavior/4-Step Analysis/Small-Sample Error/Competitive Evaluation). )
Why web text must be cut in half (Brevity is Brilliance): For print reading, users have paid money, have strong motivation, and are willing to read slowly; on the web, competitors are just one click away, and if information cannot be conveyed quickly users will leave. Success is not measured by "how many words are crammed on the page," but by how much users remember after they leave — brevity also incidentally builds a brand impression of "expressing ideas powerfully and seeming intelligent."
A key tool for Clarify is "Information Scent": let users accurately predict what they will see after clicking, through the wording of links, headings, and buttons. Strong scent → what users get after clicking matches expectations → trust accumulates; weak scent (clickbait, vague wording) → users find the content does not match after clicking → disappointment and churn. Supporting practices: use the user's language to name menus and commands (not the development team's internal jargon), and make error messages clearly state "what went wrong + what to do next." This intertextually connects to Heuristic #2 (Match between System and the Real World) and #9 (Help Users Recognize, Diagnose, and Recover from Errors).
Decision orientation: To judge whether a visual or copy element should stay, ask one question — "Is it communicating information, or just decorating/holding back information?" Keep the former, cut the latter. Clickbait, above-the-fold animations, and ornate long sentences almost always lose money in the long run.
IV. Understand the Problem First: Two Rules on Not Rushing to Solutions
This cluster specifically treats the occupational disease of product managers/designers/developers —acting too fast, starting to propose solutions before the problem is even clear.
| Slogan (EN / ZH) | One-sentence core mindset | Counterexample |
|---|---|---|
| Why Beats What Why Beats What | Data (click-through rate, dwell time, abandonment rate) only tells you what users did(What), it does not explain why(Why); only by finding the reasons behind behavior can you fix the root cause. | Errors kept occurring on the payment page; looking only at data showed "there is a problem here," but the root cause was actually one step earlier, where users did not understand what they were supposed to fill in. |
| Stop Solutioneering Stop Solutioneering | Jumping to solutions before fully understanding the problem ("We need a chatbot") easily leads to building features no one wants; understand the problem first before looking for answers. | Deciding to launch a chatbot just because "there are many customer inquiries," without verifying whether users actually need it or whether there is a better solution. |
Why "why" is more valuable (Why Beats What): Analytics tools can tell you how many people visited a certain page, which button was clicked the most, how many people abandoned a form — these can locate "where the problem is," but cannot locate "what the problem actually is." For example, if a user fails to pay, the root cause may not lie in the payment page itself, but in an earlier step where they did not understand what information to enter; only modifying the payment page is "treating the head for a headache."
How to get the "why" — through qualitative methods:
- Think-Aloud (thinking aloud): Have users voice their thoughts in real time as they operate ("This button looks like the next step, but nothing happened when I clicked it").
- User interviews: Talk through real thoughts, likes/dislikes, and points they find troublesome.
- Usability testing: See where users get stuck, and identify process obstacles combined with feedback.
Three-step antidote to Stop Solutioneering:
- Ask more questions, lock in the problem: When faced with a proposed solution, first ask in return — What core problem are we trying to solve? What evidence shows this is a problem? Why do we think this solution will solve it?
- List the "unknowns": Write down what is currently unknown about the problem and affected users, and prioritize researching these unknowns.
- Do user research: After research you may find a better solution,or even find that the problem does not exist at all and there is no need to build anything. → Value: Saves time and resources (not paying for ineffective solutions) + improves product effectiveness (solutions better target real pain points).
Decision orientation: Every time someone throws over a solution ("We need feature X"), don't evaluate whether the solution is good or bad first — translate it back to the problem: "What problem is X trying to solve? Where is the evidence?" — pulling the conversation back from "answers" to "problems" is one of the highest-ROI actions a PM can take.
V. Replace Guesses with Evidence: Three Rules on Research + One Closing Rule
This cluster is the practical implementation of "Don't treat yourself as the user" (Cluster 1) — since you cannot trust your own intuition, you must use evidence.
| Slogan (EN / ZH) | One-sentence core mindset | Counterexample |
|---|---|---|
| If You're Not Checking, You're Guessing If You're Not Checking, You're Guessing | Even observing only 2–5 users can greatly improve decision-making accuracy; decisions without validation are essentially guesses. | The team makes decisions directly based on "we know our users," skipping all validation. |
| Show Me the Data Show Me the Data | Internal subjective arguments within the team (about whitespace, button color, copy) should be settled with data;data ≠ only numbers; qualitative findings are also data. | Design reviews get stuck in back-and-forth like "I think it's too bright" / "I don't like this copy," and no one looks at what users actually think. |
| UX Researchers, We Like to Watch UX Researchers, We Like to Watch | What users say and what they do are often inconsistent; observing real behavior is more reliable than listening to self-reports. | During interviews everyone said "this feature is great, I'll use it," but after launch the usage rate was extremely low for half a year. |
| It Depends It Depends | There is no one-size-fits-all answer in UX; decisions depend on context, goals, and constraints; you need to find a balance between "best practices" and "contextual fit." | Rigidly applying a certain "best practice" to unsuitable scenarios, or designing completely from scratch every time and throwing away consistency. |
Empirical numbers (If You're Not Checking): A often-cited forum example — discussing "how to help users adjust interface text size,"people who cited real user data had a 100% correct rate, while those relying only on personal opinion had only a 25% correct rate (meaning 75% of guesses were wrong). Three misconceptions that make teams skip validation: ① Thinking "I myself / a certain stakeholder is similar enough to the user"; ② Overestimating personal experience and intuition; ③ Mistakenly believing user research requires a big budget/professional team/large sample — in fact,observing 2–5 users who match the persona can reveal key problems (this shares the same root as the "5-user rule: 5 users find about 85% of problems" in the 10 heuristics batch; see NNGroup Usability Testing and the 10 Usability Heuristics (Full Table of 10 Heuristics · Application to Complex Apps · User Delight Hierarchy · Testing Methods: 5-User Rule/Recruitment/Remote Testing/Task Scenarios/Step-by-Step Tasks/Attitude vs Behavior/4-Step Analysis/Small-Sample Error/Competitive Evaluation)).
Data is not just numbers (Show Me the Data):
- Quantitative data: Suitable for validating clear options, such as running an A/B test on button copy/color to look at click-through rates.
- Qualitative data: Suitable for understanding deep needs and "why," such as interviews and usability testing. → The goal is to shift discussion from "team members' preferences" to "users' actual feedback," and build a data-driven team culture.
Why observing > asking (UX Researchers, We Like to Watch): What people say, what they do, and "what they say they do" can all be different from each other, for three reasons —memory has limits, behavior is often unconscious, and social desirability leads people to give idealized answers. Two famous quotes make the point: anthropologist Margaret Mead — "What people say, what people do, and what they say they do are entirely different things"; philosopher René Descartes — to understand people's real thoughts, look at behavior rather than words. Implementation: in the discovery phase, go into users' real environments to see how they work; in usability testing, have users do real tasks instead of "looking at the design and giving opinions"; you don't have to force users to think aloud the whole time — the friction in their behavior itself is informative enough. (This corresponds to the distinction between "attitudinal data vs behavioral data"; for details see NNGroup Usability Testing and the 10 Usability Heuristics (Full Table of 10 Heuristics · Application to Complex Apps · User Delight Hierarchy · Testing Methods: 5-User Rule/Recruitment/Remote Testing/Task Scenarios/Step-by-Step Tasks/Attitude vs Behavior/4-Step Analysis/Small-Sample Error/Competitive Evaluation). )
"It Depends" is a sobering reminder, not an excuse to pass the buck (It Depends): It acknowledges the inherent tension between "best practices" and "specific contexts" — treat the two as a spectrum: one end is absolute consistency/standardization (copying specifications regardless of context), the other end is complete originality/contextual adaptation (designing from scratch every time). Excellent UX professionals do not stand at the extremes, but flexibly weigh trade-offs in the middle. For example, "Should we make a service blueprint or a user journey map?" "Should we add this button?" — the answers all depend on the current stage, goals, existing content, and click distribution of other elements.
Decision orientation: When encountering design disputes, first distinguish whether this is "something that can be settled with evidence" or "an It Depends matter." Settlable things (effects of copy/color/layout) → run A/B tests or small tests to close the issue with data; truly context-dependent things → don't pretend there is a standard answer, lay out the contextual variables and weigh them. The worst mistake is the reverse: making gut calls on things that should be tested, and rigidly following dogma on things that should be weighed.
Stringing the 19 rules together in one sentence: Don't treat yourself as the user (Cluster 1) → therefore subtract instead of piling on (Cluster 2), let the interface communicate well instead of decorating (Cluster 3) → understand the problem before acting, don't rush to solutions (Cluster 4) → and understanding problems and validating solutions relies on evidence rather than intuition, but exactly how to do it "depends" (Cluster 5).
Sourced from NNGroup Topics / UX Slogan - UX Principles (19 articles, including 1 summary index for NO.1–NO.19 + standalone notes for each slogan). Highly intertextual with the 10 Usability Heuristics, 5-user rule, attitude vs behavior, information scent, and four-layer pyramid of delight; see NNGroup Usability Testing and the 10 Usability Heuristics (Full Table of 10 Heuristics · Application to Complex Apps · User Delight Hierarchy · Testing Methods: 5-User Rule/Recruitment/Remote Testing/Task Scenarios/Step-by-Step Tasks/Attitude vs Behavior/4-Step Analysis/Small-Sample Error/Competitive Evaluation); for basic UX concepts see NNGroup UX Fundamentals (UX/Usability/UI definition distinctions · Human-Centered Design HCD · Design Thinking 5+1 stages · Product triad DVF · No research, no UX · Research methods three-dimensional framework/20 methods/9 quantitative methods/user interviews · 6-step solution tradeoff · 10 usability heuristics index · UX career 5 stages/transition/portfolio/resume). Images/original files are kept in sources.
Sources and related materials
- NNGroup UX Fundamentals (UX/Usability/UI definition distinctions · Human-Centered Design HCD · Design Thinking 5+1 stages · Product triad DVF · No research, no UX · Research methods three-dimensional framework/20 methods/9 quantitative methods/user interviews · 6-step solution tradeoff · 10 usability heuristics index · UX career 5 stages/transition/portfolio/resume)
- NNGroup usability testing and the 10 Usability Heuristics (full list of 10 heuristics · application to complex apps · hierarchy of user delight · testing methods: the 5-user rule/recruitment/remote testing/task scenarios/step-by-step tasks/attitude vs behavior/4-step analysis/small-sample error/competitive evaluation)