Foundational Principles

The difference between interfaces that people tolerate and interfaces people love comes down to a handful of principles applied consistently. These aren't abstract ideals, they're practical rules that drive every design decision.

The Core UX Pillars

Every successful interface rests on six foundational pillars:

Applying the Pillars: A Real Example

Consider a file upload feature:

The User-Centered Design Process

┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│   Research   │ →  │   Design    │ →  │  Prototype  │ →  │    Test     │
│  & Discover  │    │  & Ideate   │    │   & Build   │    │  & Iterate  │
└─────────────┘    └─────────────┘    └─────────────┘    └─────────────┘
       ↑                                                        │
       └────────────────────────────────────────────────────────┘
                         (Continuous Cycle)

Phase 1: Research & Discover

What you do: Understand users, their goals, and their pain points before designing anything.

• Interview 5-8 real users (not stakeholders guessing what users want)
• Review analytics to see where users drop off or struggle
• Audit competitors. What patterns do users already expect?
• Define user personas based on research data, not assumptions

Common mistake: Skipping research because "we already know our users." You don't. Even a 30-minute conversation with 3 users will surface surprises.

Phase 2: Design & Ideate

What you do: Generate multiple solutions, then pick the strongest approach.

• Sketch 3-5 different approaches on paper before opening Figma
• Use wireframes to test structure before investing in visual design
• Design for the primary use case first, then handle edge cases
• Get stakeholder alignment on wireframes before high-fidelity work

Common mistake: Jumping straight to high-fidelity mockups. You'll anchor on the first idea and resist changes.

Phase 3: Prototype & Build

What you do: Create something testable. It doesn't have to be code.

Common mistake: Building the full feature before testing. A clickable Figma prototype takes hours; rebuilding a coded feature takes weeks.

Phase 4: Test & Iterate

What you do: Watch real users attempt real tasks. Fix what breaks.

• Test with 5 users (catches ~85% of usability issues per Nielsen)
• Give users a goal, not instructions ("Find and buy a gift for a friend who likes cooking", not "Click the search button")
• Watch what they do, not what they say. Users often say "that was easy" while struggling
• Prioritize fixes by severity: blockers first, polish last

Common mistake: Testing with colleagues or friends. They know too much about the product. Test with people who match your target user profile.

The Golden Rules

1. Users Don't Read, They Scan

People don't read web pages word by word. They scan for headings, bold text, links, and anything that looks relevant to their immediate goal.

Practical application:

• Use clear headings that describe what follows (not clever/vague ones)
• Front-load the most important word in every heading and link
• Use bullet points instead of paragraphs for lists of items
• Bold key terms so scanners can extract meaning without reading every word
• Break long text blocks. No paragraph should exceed 3-4 lines on screen

Before:

Our company offers a range of solutions designed to help businesses 
streamline their operations and improve efficiency across multiple 
departments including sales, marketing, customer service, and logistics.

After:

We help businesses work faster across:
• Sales — automate proposals and pipeline tracking
• Marketing — schedule campaigns and measure ROI
• Customer service — route tickets and track resolution time
• Logistics — optimize delivery routes and inventory

2. Users Want Control

People panic when they feel trapped. Every screen should answer: "How do I go back? How do I undo this? How do I get out?"

Practical application:

• Always provide a visible back button or cancel option
• Support Ctrl+Z / Cmd+Z for reversible actions
• Confirm destructive actions ("Delete this project? This cannot be undone.")
• Let users dismiss modals by clicking outside or pressing Escape
• Never auto-advance without giving users time to read and react

3. Users Bring Expectations

Every user arrives with a mental model built from every other app and website they've used. Fighting those expectations costs you.

Practical application:

4. Users Make Mistakes

Design to prevent errors first, then make recovery painless when errors happen anyway.

Error prevention strategies:

• Disable the "Submit" button until the form is valid
• Use input masks for phone numbers and dates
• Show confirmation dialogs for destructive actions
• Constrain input (dropdowns instead of free text where possible)
• Provide inline validation before submission

Error recovery strategies:

• Preserve user input when errors occur (never clear the form)
• Scroll to the first error and focus the field
• Explain what went wrong in plain language
• Tell users how to fix it ("Enter a date in MM/DD/YYYY format")
• Provide an undo option for at least 5-10 seconds after destructive actions

5. Users Have Limited Attention

Every element on screen competes for a finite resource. The more you show, the less any individual thing gets noticed.

Practical application:

• One primary action per screen. If everything is bold, nothing is.
• Remove elements that don't serve the user's current task
• Use progressive disclosure: show basics first, details on demand
• Reduce choices at decision points (Hick's Law, see Chapter 2)
• Group related items so the brain processes them as a single unit, not 8 separate ones

Mental Models vs. Implementation Models

A mental model is how users think something works. An implementation model is how it actually works technically. Good UX bridges this gap.

Example: deleting files:

• Implementation model: File reference is removed from the directory table; data blocks are marked as free space on disk
• Mental model: "I put it in the trash. I can get it back if I need to."
• Good UX: Trash/recycle bin that matches the mental model

Example: saving a document:

• Implementation model: Data serialized, written to disk, file handle closed
• Mental model: "I clicked save, my work is safe"
• Good UX: Auto-save with a "Saved" indicator. No save button needed.

When the interface matches the mental model, users don't need instructions.

Don Norman's Design Principles

These come from The Design of Everyday Things and apply to digital interfaces just as much as door handles:

Heuristic Evaluation: Quick Audit Framework

When reviewing any interface, check these 10 heuristics (adapted from Nielsen):

1. Visibility of system status: Does the user always know what's happening?
2. Match between system and real world: Does it use the user's language, not developer jargon?
3. User control and freedom: Can users undo, redo, and escape?
4. Consistency and standards: Do similar things look and work the same way?
5. Error prevention: Does the design prevent errors before they happen?
6. Recognition over recall: Can users see their options instead of remembering them?
7. Flexibility and efficiency: Are there shortcuts for experienced users?
8. Aesthetic and minimalist design: Is every element necessary?
9. Help users recognize, diagnose, and recover from errors: Are error messages helpful?
10. Help and documentation: Is help available when needed, ideally unnecessary?

Common Mistakes

Key Takeaways

• Start with user research. Assumptions are the enemy of good UX.
• Apply the six pillars (clarity, simplicity, consistency, feedback, accessibility, efficiency) to every decision.
• Design for scanning, not reading. Front-load important information.
• Match user mental models. Don't force users to learn your system's internal logic.
• Test early, test with real users, test often. Five users catch 85% of problems.
• Every screen should answer: Where am I? What can I do? What just happened? How do I go back?