UX Fundamentals

Users can't tell you why a product feels cheap, but they know within seconds. It's almost never the colours. It's structure, states, and whether the thing does what they expected.

The concept

UX is not visual design. It's the answer to three questions:

1. Can they find it? (information architecture)
2. Can they do it? (flows and affordances)
3. Do they know what happened? (feedback and states)

Get those right with plain grey boxes and you have a usable product. Get them wrong with beautiful visuals and you have a beautiful product nobody can operate.

Information architecture

IA is how content and functions are organised. Two rules carry most of the weight:

Match the user's mental model, not your database schema. Your tables are not categories. If users think in "projects" and you organise by "workspaces → boards → lists," you've exported your data model as navigation.

Depth vs breadth. Broad-and-shallow beats narrow-and-deep on small screens. Three taps to anything is a reasonable ceiling; more than four and people give up. If you need five levels, you probably need search instead.

Navigation patterns and when each fits:

Flows

A flow is a sequence with a goal. Design the whole sequence, not screens in isolation.

For every flow, know: the entry points (there's always more than one), the happy path, the branches, the exits (including cancel, always provide one), and where it resumes if interrupted.

Interruption is the default on mobile. A call arrives, the app is backgrounded, the battery dies. If your five-step flow loses everything at step four, it will lose everything at step four constantly.

States: the 30% everyone forgets

Every screen has more than one state. Design them all:

  EMPTY      first-run, nothing yet    ← most-seen, least-designed
  LOADING    skeleton > spinner
  PARTIAL    some data, some pending
  IDEAL      the state you designed
  ERROR      what happened + what to do next
  OFFLINE    what still works
  PERMISSION denied camera/notifications/location
  MAXIMUM    10,000 items, a very long name

The empty state is the most important screen in most products. It's what every new user sees, and "No items yet" is a dead end. A good empty state explains the value, shows an example, and gives one obvious action.

Error messages need three parts: what happened, why (if useful), and what to do now. "Something went wrong" fails all three.

Feedback and latency

Perceived speed matters more than actual speed:

• < 100ms, feels instant. Acknowledge every tap within this window.
• < 1s, no indicator needed, but keep the UI responsive
• 1-3s, show a skeleton or progress
• > 3s, show progress and what's happening; let them leave and come back

Optimistic UI, show the result immediately, reconcile with the server after, is the single biggest perceived-performance win available. It requires you to handle the failure case honestly (revert and explain).

Accessibility is not optional

It's a legal requirement in many markets, a store-review item, and it makes the product better for everyone.

The non-negotiable floor: 4.5:1 contrast for body text (3:1 for large), 44×44pt minimum touch targets, visible focus states for keyboard users, labels on every icon-only control, never colour as the only signal, and support for system text scaling.

Most of this is free if you do it from the start and expensive to retrofit.

📐 Best practice

Map the IA before designing screens. A simple tree. If you can't draw it, users can't navigate it.

Design flows end to end, including entry points, cancel, and resume.

Design all eight states for every meaningful screen. Put it on your definition of done (Chapter 08).

Acknowledge every interaction within 100ms, even if the work takes longer.

Prefer recognition over recall. Show options rather than requiring memory.

Make destructive actions hard and reversible. Confirmation for irreversible things; undo for everything else. Undo beats confirmation, it doesn't interrupt the 99% who meant it.

Keep one primary action per screen. If everything is emphasised, nothing is.

Write the copy before the UI. Interface text is the interface (Chapter 43).

Test with 5 people who've never seen it. Watch, don't help. Five people find most usability problems.

💀 Common mistakes

Exporting your data model as navigation.

Designing only the ideal state. Then production is full of empty screens and unhandled errors.

Spinners instead of skeletons. Skeletons feel faster and reduce layout shift.

Confirmation dialogs everywhere. They train people to click through without reading. Use undo.

No cancel path. Every flow needs an exit.

Icon-only controls without labels. Ambiguous and inaccessible.

Requiring perfect input. Accept messy input and normalise it, phone numbers with spaces, dates in any order, trailing whitespace.

Losing work on interruption. Autosave drafts.

Retrofitting accessibility. Cheap at the start, expensive later.

Designing for a full account. Everything looks great with 20 items and breaks at 0 or 5,000.

The professional workflow

 1. IA: draw the tree. Group by the user's mental model.
 2. FLOWS: map each core task end to end — entry, happy path,
    branches, cancel, resume.
 3. WIREFRAME low-fidelity. Grey boxes. Structure only.
 4. STATES: for each screen, design all eight.
 5. COPY: write real text. No lorem ipsum — it hides problems.
 6. VISUAL: only now (Chapter 12).
 7. ACCESSIBILITY PASS: contrast, targets, focus, labels, scaling.
 8. TEST with 5 unfamiliar people. Watch silently.
 9. INSTRUMENT the flow (Chapter 38).

Tools, websites & costs

Alternatives & trade-offs

Platform conventions vs custom. Following iOS/Material conventions makes your app instantly learnable and slightly generic. Custom patterns can differentiate and always cost comprehension. Deviate deliberately and rarely, and never on navigation.

Mobile-first vs desktop-first. Design for the harder constraint first. If most usage is mobile, mobile-first. For B2B tools where real work happens on a laptop, desktop-first is correct and mobile becomes a companion view.

Progressive disclosure vs everything visible. Hiding complexity helps beginners and frustrates experts. Power users want density and shortcuts. Serve both: simple default, discoverable depth.

Design system first vs ship first. Building a system before you know your patterns is premature. Extract one after 3-4 screens repeat the same components (Chapter 12).

Checklist

• IA drawn as a tree, grouped by user mental model
• Every core flow mapped end to end, including cancel and resume
• All eight states designed for every meaningful screen
• Empty state treated as a real screen with an action
• Errors say what happened and what to do
• Every interaction acknowledged in under 100ms
• One primary action per screen
• Destructive actions reversible (prefer undo)
• Work survives interruption
• Contrast 4.5:1, targets 44pt, focus visible, icons labelled
• Tested with 5 unfamiliar people

📓 Case Study: "it's very dry"

Project: SOLIS, designing a reading experience for a lesson-based app.

The reader went through three complete rebuilds, and the sequence teaches more than the endpoint.

v1, tap to advance. Read a paragraph, tap, page changes. Rejected on day 2: "it should all be in 1 page and as i scroll down the data should present itself… make it as smooth as possible."

v2, one scrolling page. Mechanically correct. The verdict: "its very dry."

That two-word critique is the most useful thing in this case study. Nothing was broken. Nothing failed a usability test. It was structurally fine and emotionally flat, and that is a real UX defect, not a cosmetic one. Most products ship in exactly this state because nothing objective flags it.

The fix was a state mechanic: the next section shows dimmed at the bottom of the current one, brightens as it becomes yours, and dims again once passed. A reading-position indicator built out of opacity:

.beat         { opacity:.42 }   /* ahead — a peek */
.beat.active  { opacity:1   }   /* yours */
.beat.peeked  { opacity:.28 }   /* behind */

v3, paged snap-scroll. Free scrolling still felt loose: "instead of normal scrolling, i want it to behave like pages… when i scroll (little or more doesnt matter) it will put me on next page." Four lines of CSS, with scroll-snap-stop: always doing the critical work, without it a fast flick sails past several pages.

⚠️ Deviation: states were designed reactively, one bug report at a time.

Best practice is to design all eight states up front. Instead they arrived as defects:

• Re-entry into an animated screen showed its end state, the loss→gain animation had no reset, so a user navigating back saw the punchline first.
• A disabled button had no disabled styling. The Oath screen gates its continue button until you draw a signature, but .btn:disabled had no style anywhere in the app, so a blocked button looked enabled. A gate the user can't see is a bug, and it existed because "disabled" was never on a state list.
• Scroll position on screen change was wrong for two days (Chapter 18).

Each is a standard entry on the eight-state checklist. Five minutes per screen would have caught all three.

Lessons

1. "It's dry" is a real UX defect. Structurally correct and emotionally flat is the state most products ship in.
2. Design all eight states, up front. They arrive as bugs otherwise.
3. The empty state is your most-viewed screen. Treat it as a real design.
4. Interruption is the default on mobile. Autosave and resume.
5. Undo beats confirmation. It doesn't punish the 99% who meant it.
6. Deviate from platform conventions deliberately and rarely, never on navigation.
7. Accessibility from the start is free; retrofitted it's expensive.
8. Five unfamiliar testers find most usability problems. Watch; don't help.

Next: Chapter 12: UI Design and Design Systems →