Module 5 · Design

31

UX Principles Every PM Should Know

The handful of design principles that explain why some products feel right and others don't, in language PMs can use.

8 pages3.3K words16 min read

Why PMs Need a Few Solid Principles

PMs are not designers. They don't need to know every UX research finding or every interaction pattern. But they benefit enormously from knowing a small number of solid principles, because those principles explain why things work or don't. Without them, design feels like opinion. With them, the PM can have grounded conversations about why a design is or isn't serving users well.

This article covers the principles we use most often in product work. They come from cognitive psychology, decades of usability research, and writers like Don Norman, Jakob Nielsen, and Steve Krug. None are new. Most are well known by name in design circles and rarely applied consistently. PMs who internalise them have a structural advantage in design discussions and ship better products as a result.

Principle One: Recognition Over Recall

Humans are much better at recognising things than at recalling them from memory. We can recognise thousands of faces but struggle to describe even a close friend's face in detail. We can recognise a thousand product names from a list but only recall a dozen or so from memory.

The implication for design is direct. When users need to do something, give them options to choose from rather than asking them to remember what to type. A dropdown is easier than a free-text field. A list of recently used items is easier than typing the name. Search results listed below the search box are easier than just a search box.

Where This Comes Up

  • Forms that ask users to remember information they already told you (e.g., asking for the same address twice).
  • Search results that appear after typing rather than suggesting as you type.
  • Settings buried in menus that users would recognise if they saw them but can't recall where they are.
  • Empty states that don't suggest what the user could do next.

When you find your product asking users to remember things, consider whether you could show them options instead. The shift from recall to recognition reduces cognitive load and makes the product feel easier.

Principle Two: Feedback

Users need to know that their actions had an effect. Click a button, something visible should change. Save a form, something should confirm the save. Wait for a long action, something should indicate progress. Without feedback, users feel uncertain. They may click again, doubling actions. They may give up. They lose trust.

Levels of Feedback

Different actions deserve different feedback. A button click needs immediate visual response (the button changes state, even briefly). A save action needs a confirmation (a checkmark, a toast message, a state change). A long action needs progress (a spinner with estimated time, or stages showing progress). The level of feedback should match the duration and importance of the action.

When Feedback Is Missing

Common failures: a button that does nothing visible when clicked, leaving the user wondering if it worked. A save that doesn't confirm, leaving the user wondering if their data was kept. A page load that shows nothing, leaving the user wondering if they should refresh. Each is a small thing; in aggregate they make a product feel untrustworthy.

Principle Three: Hick's Law (Choices Slow Decisions)

The more choices presented to a user, the longer they take to decide. This is well-documented in psychology and matters in product design. A menu with twenty items is slower to navigate than a menu with five. A page with fifteen calls to action is harder to act on than a page with two.

Implications

  • Don't give the user every option you have. Show the few they most likely need.
  • When there are many options, group them so the user can narrow down quickly.
  • Highlight the primary action; let secondary actions be visible but less prominent.
  • Empty states should suggest one or two actions, not a menu of possibilities.
  • Onboarding should focus on the most important first step, not on showing the full breadth of features.

The Counter-Balance

Hick's Law doesn't mean removing all choice. Users with specific needs should be able to get to specific features. The principle is to surface the common path prominently and let the less common paths be discoverable but not in the way. Defaults handle the common case; settings handle the edge cases.

Principle Four: Fitts's Law (Target Size and Distance)

The time to click a target depends on its size and how far away it is. Bigger targets, closer to where the user already is, are faster. Small targets in inconvenient corners are slow and error-prone. This sounds obvious; many designs violate it.

Implications

  • Important actions should have generous click targets, not tiny links.
  • The most common actions should be near where the user is looking, not in distant corners.
  • On mobile, touch targets should be at least forty-four pixels (Apple's recommendation) to forty-eight pixels (Google's recommendation).
  • Edges and corners of the screen are easy to reach with a cursor (because the cursor stops at the edge); important global actions can live there.
  • Submenus that require precise mouse movement to navigate are slow and frustrating; consider alternatives.

Principle Five: Consistency

Within a product, similar things should look and behave similarly. Across products in a category, conventions should be respected. Users learn a product by recognising patterns. Inconsistency forces them to learn each part separately.

Internal Consistency

If clicking a row in one table opens a detail view, clicking a row in another table should do the same. If primary actions are blue buttons in one section, they should be blue buttons in others. Breaking these patterns without strong reason confuses users.

External Consistency

Conventions exist for a reason. Logo top-left links to home. Search has a magnifying glass icon. Account is in the top right corner. Following these reduces cognitive load. Breaking them requires very strong reason and usually produces frustrated users.

When to Break Consistency

Sometimes inconsistency is intentional and right. A destructive action (delete, reset) is sometimes styled differently to signal danger. A new feature may deliberately stand out to drive adoption. Inconsistency with purpose is fine; inconsistency by accident is harmful.

Principle Six: Forgiveness

Users will make mistakes. The product should make mistakes easy to recover from. Confirm destructive actions. Allow undo. Preserve work in progress. Provide clear paths back from dead ends.

Specific Practices

  • Undo over confirm. Where possible, let users undo an action rather than asking them to confirm before doing it. Undo is faster and less interruptive. Confirm only when undo is genuinely impossible.
  • Save automatically. Don't rely on users to save. Auto-save preserves work and reduces anxiety.
  • Validate gently. Show errors as users move through a form, not all at once at the end. Make errors specific and constructive, not just invalid input .
  • Provide clear back paths. Users who go down the wrong branch should be able to back out easily. Trapped users churn.
  • Tolerate imperfect input. Phone numbers in any format. Trim whitespace. Suggest corrections rather than rejecting.

Principle Seven: Visual Hierarchy

On any screen, some things matter more than others. Visual hierarchy makes this clear. The most important element is biggest, brightest, or most prominent. Less important elements recede. Without hierarchy, every element fights for attention and the user's eye has nowhere to land.

How It Is Created

  • Size: bigger things draw the eye first.
  • Colour: bright or contrasting colours draw attention; muted colours recede.
  • Position: top-left and centre tend to be looked at first in left-to-right languages.
  • Whitespace: elements with space around them stand out; crowded elements blend.
  • Weight: bold text and saturated colours feel more important than thin or pale ones.

A Common Failure

Pages where everything is bold, big, or highlighted have no hierarchy. Everything competes; nothing wins. The user's eye darts around with nowhere to land. The fix is to demote things; the most important element should be visually dominant, others supporting.

Principle Eight: Match the User's Mental Model

Users come to your product with mental models from elsewhere. From other products. From their work. From the physical world. The closer your product matches their existing models, the easier it is to learn. The further it deviates, the more friction users experience.

Examples

  • A folder icon represents a place to store things, because that's what folders do in the physical world.
  • A trash can represents deletion, because that's where discarded items go physically.
  • A flag or star represents marking something for later attention, because that's how people mark physical items.
  • Drag-and-drop represents physically moving things, because that's how people move physical objects.

When designing, ask what mental model your user is bringing. If your design fits that model, learning is fast. If it doesn't, you need a strong reason for the deviation. Sometimes the deviation is justified (the new model is better). Often it isn't, and the design will struggle for adoption.

Principle Nine: Don't Make Me Think

Steve Krug's book of this title captures something important. Users should not have to think about how to use the product. Thinking is friction. Every moment of wait, what do I do here is a small frustration that adds up over time. The best products feel obvious; they let users focus on what they are trying to accomplish, not on the product's mechanics.

Where Thinking Creeps In

  • Buttons whose labels are unclear: Submit ? Continue ? Save ? Different verbs for the same action across pages.
  • Multi-step flows where the steps aren't numbered or where the progression is unclear.
  • Forms with unclear validation rules: users have to guess what format is expected.
  • Pages where the primary action isn't obvious; the user has to scan to figure out what to do next.
  • Settings that don't explain what they do; the user has to guess or experiment.

How to Reduce Thinking

Use clear, specific labels. Make the primary action visually dominant. Provide helpful defaults. Show, don't tell. Test with real users; the moments where they pause are the moments where they were thinking. Eliminate as many of those moments as you can.

Principle Ten: Affordances

An affordance is a property of an object that suggests how it can be used. A button looks clickable. A handle looks graspable. A field looks fillable. Good design has clear affordances; users know what to do because the elements look like what they are.

Where Affordances Fail

Flat design (popularised in the 2010s) often removed visual cues that suggested clickability. The result: users couldn't tell what was a button and what was decoration. Some flat design has good affordances; some doesn't. The principle matters more than the visual style.

Common failures: text that is clickable but looks like body text. Buttons that look identical to background elements. Drag handles that aren't visible until you hover. Each forces users to discover behaviour through trial and error, which is friction.

Tests

Show your design to a fresh user and ask them to identify what is clickable. The mistakes reveal where affordances are weak. Strong affordances produce nearly perfect identification.

Principle Eleven: Performance Is a UX Feature

Slow products feel broken even when they work correctly. Pages that take three seconds to load lose a meaningful share of users before content appears. Animations that stutter make the product feel cheap. Interactions that lag make users doubt whether their action registered.

Perceived vs. Actual Performance

Sometimes you can't make something faster. You can make it feel faster. Show partial content while the rest loads. Show progress indicators for long actions. Use optimistic updates (show the result immediately even if the server hasn't confirmed). The perceived speed is what users experience; sometimes it matters more than the actual.

When to Invest

Performance is often the cheapest way to improve UX in mature products. Users notice. Conversion rates improve. The investment is in engineering rather than design, but the UX impact is real. PMs should advocate for performance work even when there's no specific feature to ship.

Common Mistakes That Violate Multiple Principles

The Power-User Trap

Designs that pack many features into a small space because experienced users can handle complexity. New users can't. Hick's Law and visual hierarchy both suffer. The fix is to show simple by default and reveal advanced features as users grow.

The Documentation Substitute

Features so complex that they need documentation to use. Don't Make Me Think and affordances both suffer. Users shouldn't need to read help articles to perform common actions. If they do, the design has failed.

The Hidden Action

Important actions buried in menus or behind hover states. Recognition over recall and affordances both suffer. Users can't do what they want because they can't find how. Surface common actions visibly.

The Inconsistent Pattern

Same kind of action behaves differently in different parts of the product. Consistency suffers. Users can't transfer learning across the product. The fix is a design system and the discipline to follow it.

The Confirmation Storm

Every action requires a confirmation dialog. Forgiveness (through undo) would be more user-friendly. Confirmations have a place; overusing them trains users to click OK automatically, which then causes accidents on the rare important confirmation.

A Final Word

These principles are not exhaustive but they cover most of what PMs need to engage productively with UX. Internalise them and you will see things in your product you didn't see before. The designer brings craft; you bring user and business context; together you produce designs that work better than either alone.

If you take one practice from this article, take this: every time you review a design or prototype, walk through these principles as a checklist. Where does the design rely on recall instead of recognition? Where is feedback missing? Are choices appropriately limited? Is hierarchy clear? Does it match user mental models? The checklist is mechanical at first; over time it becomes intuitive, and your judgement of UX work will sharpen for the rest of your career.

Key Takeaways

  • Recognition is easier than recall. Show options instead of asking users to remember.
  • Every action needs feedback. Without it, users feel uncertain and lose trust.
  • Limit choices to reduce decision time (Hick's Law) and make targets big and reachable (Fitts's Law).
  • Consistency, forgiveness, visual hierarchy, mental model matching, and clear affordances are foundational.
  • Don't Make Me Think captures it all: the best designs feel obvious. Performance is part of UX; slow products feel broken even when they work.
↑ Back to the index