Web UI/UX Engineering: Usability and Reliable Client Behavior

A comprehensive engineering note on usability, information architecture, accessibility, responsive design, data tables, forms, reliable client behavior, and a Zen approach to critical work applications.

Approach: I do not use the word “Zen” here as a reduction of a historical or religious teaching into a design rule. In this text, Zen means reducing unnecessary decisions, keeping attention on the actual task, refusing to place form ahead of function, giving feedback quietly but visibly, and not disrupting behavior that already works merely because something newer looks more modern. This is not an aesthetic slogan. It should be treated as an engineering discipline tested against standards, measurement, error cost, and the context of the real task.

When working on a web interface, color, spacing, and icons are the most visible layer, yet production failures usually originate elsewhere. Information architecture, the user's mental model, accessibility, network latency, data integrity, input devices, authorization boundaries, and habits accumulated over years are all parts of the same interaction. If the interface ignores one of them, the result can look clean while remaining operationally fragile.

For that reason, I place this note not only in the visual-design side of UI and UX, but at the intersection of human-computer interaction and software engineering. A screen is good first because it lets the user complete the job correctly, predictably, accessibly, and safely—not because it looks attractive. Speed and learnability matter as well, but speed obtained at the expense of correctness or data safety is not a real gain.

The note distinguishes four kinds of evidence:

Normative requirement: standards such as W3C WCAG/WAI-ARIA and HTTP.
Research-based finding: usability research and peer-reviewed studies.
Design system/pattern: recommendations from widely used systems such as GOV.UK, IBM Carbon, Apple HIG, and Material.
Industry example: interaction patterns observed in Facebook, X, Amazon, Hepsiburada, Trendyol, Canvas, Moodle, and university information systems.

The fact that a large company or popular product uses a particular interface does not prove that the same decision is correct for every product. Large products are designed within their own user population, business model, experiments, technical debt, and backward-compatibility constraints. Examples should therefore be treated as decisions to examine, not templates to copy.

Unit 1: UI, UX, and Usability

UI and UX are not the same concept

User Interface (UI) is the visual and interactive surface through which the user directly operates the system: buttons, menus, tables, forms, search fields, tabs, dialogs, colors, typography, spacing, icons, and state indicators.

User Experience (UX) is broader. It covers the complete experience of pursuing a goal: whether the user can find the required function, understand what to do, complete the task in reasonable time, avoid errors, recover from them, understand system feedback, tolerate waiting, maintain a sense of trust and control, use the product accessibly, and encounter consistent behavior across devices.

A visually impressive screen can produce poor UX. Conversely, a plain screen can be highly usable when its task flow is correct.

The engineering meaning of usability

It is useful to evaluate usability along several axes:

Learnability: How easily can a new user learn the basic task?
Efficiency: How little cognitive and physical effort does an experienced user need to complete the same task?
Memorability: After time away from the system, must the user learn it again?
Error rate and severity: How often do errors occur, and how serious are their consequences?
Recoverability: Can an error be undone or corrected easily?
Satisfaction: Does the user experience the system as a tool under control?
Accessibility: Can the task still be completed despite visual, auditory, motor, or cognitive differences?

The user's mental model

A good interface does not force the user to learn the system's real technical architecture. The user should not need to think about which microservice is being called, which table is being updated, or which state machine is running.

The user should instead be able to answer:

Where am I?
What can I do here?
What is the next step?
Did the action I initiated actually happen?
If I made a mistake, how do I return?
Has my data been saved?
Is the system currently working, waiting, or failing?

If these answers are not visible in the interface, the cognitive burden has been transferred to the user.

Unit 2: Nielsen's Usability Heuristics and the Modern Web

The Nielsen Norman Group's ten usability heuristics are not a formal standard. They are evaluation principles that remain useful across a broad range of problem classes.

1. Visibility of system status

The result of an action must be visible.

Save → “Saving…” → “Saved”.
A filter changes → a loading state is shown.
A file is uploading → when actual progress is known, show a percentage or progress bar.
A long query runs → the interface must not look frozen.
The session has expired → the user should not continue entering data into a dead session without warning.

Silence is one of the worst forms of system-status feedback.

2. Match between the system and the real world

Technical terminology should be used only when the audience is genuinely technical. The language of the user's domain matters more than backend class names or database identifiers.

3. User control and freedom

Especially around mistakes, the product should provide safe exits such as Back, Cancel, Undo, Revert Changes, and Restore Defaults where appropriate.

4. Consistency and standards

Within one product, the same concept should use the same name, icon, positioning logic, shortcut, and state language. Established web behavior should be changed only when there is a clear benefit.

5. Error prevention

The best error message is often the design decision that prevented an avoidable error from occurring. Examples include disabling invalid dates, preventing impossible combinations, making the scope of a destructive action explicit, and preventing duplicate submission on both client and server.

6. Recognition rather than recall

Users should be able to recognize options instead of memorizing codes or commands. Recent items, autocomplete, visible filters, breadcrumbs, explicit tab titles, and shortcut hints reduce cognitive cost.

7. Flexibility and efficiency of use

A new user may follow visible controls while an experienced user reaches the same result faster through keyboard shortcuts, batch operations, saved filters, and quick search.

8. Aesthetic and minimalist design

Minimalism does not mean “few features.” It means removing noise that does not contribute to the task. If a dense operational screen genuinely requires thirty columns, reducing the table to five columns is not minimalism; it is information loss.

9. Help users recognize and recover from errors

“Operation failed” is usually insufficient. An error message should explain what happened, what the user can do next, and whether the user's data was preserved.

10. Help and documentation

A good product should explain itself as far as practical, but contextual help, field-level guidance, example values, shortcut lists, and process documentation remain valuable for complex tasks.

Unit 3: Established Web Conventions

Why conventions matter

Users do not arrive at a web application with an empty mind. They bring expectations learned elsewhere:

the logo returns to the home page,
a magnifying glass implies search,
profile/avatar opens account-related actions,
a gear suggests settings,
a trash can suggests deletion,
a left arrow suggests going back,
tabs are different views of the same context,
breadcrumbs show location in a hierarchy.

These expectations allow knowledge learned in one product to transfer to another.

A strong layout convention for LTR desktop web

┌─────────────────────────────────────────────────────────────────────────┐
│ Logo   Primary Navigation          Search        Help  Alerts   Profile │
└─────────────────────────────────────────────────────────────────────────┘

Not every position in this layout has the same evidential strength.

Logo/home in the upper-left: This is strongly supported by long-standing web convention and Nielsen Norman Group research. In LTR interfaces, upper-left placement is advantageous for brand recognition and returning home. In RTL interfaces, the logical leading side may reverse.

Profile/account in the upper-right: Many web applications place account utilities on the trailing side of the utility area. This is a strong industry convention, but it should not be treated as an experimental requirement as strong as the upper-left home/logo convention.

Search: If searching is central to the product's primary task, it should be visible and prominent. If it is secondary, a smaller position in the upper utility area can be sufficient.

Content-heavy site:

Logo | Home | Articles | Resources | About | Search | Profile

Dense work application:

┌───────────────────────────────────────────────┐
│ Top bar: title / global search / utilities    │
├──────────────┬────────────────────────────────┤
│ Left menu    │ Workspace                      │
│ Module A     │ Table / form / detail          │
│ Module B     │                                │
│ Module C     │                                │
└──────────────┴────────────────────────────────┘

NN/g identifies visible left navigation as a strong option for broad or growing information architectures on desktop. Making the hamburger menu the default on a spacious desktop can reduce discoverability.

Global navigation: the product's primary sections.
Local navigation: subareas inside the active section.
Utility navigation: account, help, notifications, language, sign-out, and similar secondary but frequently accessed functions.

Giving all three layers the same visual weight blurs the information architecture.

When are breadcrumbs useful?

Breadcrumbs are particularly useful in deep hierarchies, large category systems, or when users can enter a middle-level page from an external link.

Home > Administration > Users > User Details

The “three-click rule” is not a rule

There is no general empirical rule saying that any task requiring more than three clicks automatically has poor UX. What matters is strong information scent, clear location, meaningful steps, and an easy path back from a wrong turn.

Unit 4: Visual Hierarchy, Layout, and Attention

A screen should make the following order understandable within the first few moments:

What is this screen?
What is the primary task?
Which action is primary?
Which information is secondary?
Which actions are destructive or otherwise risky?

Hierarchy is created through size, weight, contrast, spacing, alignment, color, grouping, and position.

Spacing is not decoration; it is information architecture

Spacing groups related elements, separates different groups, and establishes visual priority. Giving every element equal space is not the same as good design.

A consistent spacing scale

Instead of arbitrary values, a scale can be used:

4, 8, 12, 16, 24, 32, 48

These numbers are not universal laws. The valuable property is consistency through design tokens.

Alignment

Form labels, numeric table values, action buttons, card headings, and icon-text pairs should align to shared axes where practical.

Color must not carry meaning alone

[!] Error: Record could not be saved
[✓] Saved

Color, iconography, and text should work together.

Icons

An icon can stand alone only when its meaning is broadly established. Search, close, back, play, and pause are comparatively safer; ambiguous actions should use an icon with a visible label.

Unit 5: The Golden Ratio — Design Principle or Design Myth?

The golden ratio is:

φ = (1 + √5) / 2 ≈ 1.618

It can be approximated as a 61.8% / 38.2% distribution.

Where can it be useful?

It can be tested as a compositional hypothesis for a hero/text area, image cropping, heading scale, card proportions, or decorative composition.

Where should it not drive the decision?

It should not be the sole determinant of functional choices such as sidebar width, breakpoints, table columns, touch-target size, form columns, modal size, or accessible font size.

What does the research say?

In a web information-retrieval experiment with 98 participants by Paul van Schaik and Jonathan Ling, screen ratio affected task performance and subjective outcomes, yet the condition using the Golden Section produced the weakest screen-ratio result.

In an experiment with 91 participants by Tractinsky, David, and Krupnik, the golden-ratio hypothesis received support for mobile-device form factors but not for web-page designs.

Therefore:

The golden ratio is not a scientifically established universal optimum for web UX.

Golden ratio → sketch / aesthetic hypothesis
User task + content + accessibility + measurement → design decision

Menus should be grouped around user goals rather than the institution's internal organization.

Ambiguous:

Operations
Other
Services
More

More descriptive:

Leave Requests
Payment History
Access Permissions
Export

Mega menus

On very broad content sites, a mega menu can expose several category levels at once instead of relying on long chains of hover-driven submenus. In a dense work application, persistent left navigation plus section headings and tabs is often more stable.

What should a tab represent?

Tabs should represent closely related, mutually exclusive views of the same context.

User
├─ Profile
├─ Permissions
├─ History
└─ Sessions

Tabs should not be mixed with actions such as Save, Delete, and Export. Apple HIG likewise separates the role of tab bars as navigation from action controls.

Too many tabs

A large number of tabs leads to overflow, horizontal scrolling, truncated names, and loss of visibility of the active tab. Beyond a certain point, a sidebar, selector, or split view can be more appropriate.

Unit 7: Search, Discovery, Filtering, and Sorting

A mature search experience is not merely a text box. It may include:

a visible search affordance,
search history,
autocomplete,
spelling correction,
synonyms and related queries,
filters,
sorting,
a summary of active filters,
result counts,
recovery suggestions for zero-result queries.

Amazon's search improvements explicitly use autocomplete, spelling correction, and related search. Hepsiburada's official 20-F disclosures describe product discovery through text search as well as categories, filters, barcodes, images, and speech-to-text.

Search as the user types

Instead of calling the backend for every keystroke:

input
  ↓
debounce
  ↓
cancel previous request
  ↓
new request
  ↓
apply only the latest request result to the UI

Filters

Filters should make the selected value, active-filter count, individual removal, clear-all action, and result count visible. Baymard's e-commerce finding about keeping applied filters visible should be validated against the task context before being transferred to enterprise data grids.

Sorting

Sorting should clearly show direction and, where possible, use human language such as “Newest / Oldest.”

Unit 8: Data Tables and Data-Grid Design

Nielsen Norman Group emphasizes four fundamental tasks around data tables:

finding records that match criteria,
comparing records,
viewing, editing, or adding a single record,
acting on records.

A table and a grid are not the same thing

For static or read-only data, semantic HTML <table> is often the right and accessible choice. If an interactive data grid adds application behaviors such as keyboard cell navigation, selection, editing, and virtualization, the WAI-ARIA grid pattern may become relevant.

A common work-table surface

Title                    [Search.............] [Filter] [⋯]
Active filters: [State: Active ×] [Date: Today ×] [Clear]

┌────┬──────────────┬─────────────┬──────────┬────────────┐
│ □  │ Record       │ Date ↕      │ State    │ Actions    │
├────┼──────────────┼─────────────┼──────────┼────────────┤
│ □  │ ...          │ ...         │ ...      │ ⋯          │
└────┴──────────────┴─────────────┴──────────┴────────────┘

1–50 / 12,480                       [‹] [1] [2] [3] [›]

Depending on the task, the table may include search, filters, sorting, pagination, page size, row selection, multi-select, batch actions, column visibility, resizing, sticky headers, detail panels, export, copy, and explicit empty/loading/error states. Adding every capability to every table is not good design.

In IBM Carbon's data-table approach, the toolbar provides a common area for search, filtering, and global actions. Batch actions can appear contextually when rows are selected.

Mobile tables

Responsive behavior does not require every table to become a stack of cards. Hiding low-priority columns, using a detail panel, controlled horizontal scrolling, sticky key columns, or a task-specific card view may all be valid. In dense engineering and administration tables, horizontal scrolling is often preferable to discarding important information.

Pagination or infinite scroll?

Infinite scroll works well for exploration and homogeneous social feeds. Pagination is often stronger for returning to a known record, comparison, administration, and reporting. NN/g likewise notes weaknesses of infinite scrolling for goal-directed tasks such as locating a specific item.

Virtualization

Placing 100,000 rows in the DOM is not responsive design. Virtual scrolling reduces rendering cost, but screen-reader semantics, browser find behavior, row counts, keyboard navigation, and scroll-position stability must be handled deliberately.

Unit 9: Form Design

The user's goal is not to fill in a form; it is to obtain the result behind that form. For every field, ask: “Is this information really required now?”

Eliminate → Automate → Simplify

remove fields that do not contribute to the task,
do not ask again for data the system already knows,
derive or prefill what can be obtained reliably,
simplify what remains.

Baymard's checkout research likewise shows that the burden of fields presented to the user can matter more than the raw number of steps.

Labels

Prefer:

Email address
[________________________]

A placeholder should not replace a label because it disappears when the user starts typing.

Required and optional fields

In long forms, required fields should be unambiguous. A red * without an explanation is weak communication.

Input semantics

<input type="email" autocomplete="email">
<input type="tel" inputmode="tel">
<input type="date">

These semantics support appropriate virtual keyboards and browser behavior.

Validation

Client-side validation exists for fast feedback; server-side validation remains the authority for security and data integrity. Client validation is not a security boundary.

A reasonable timing model is often:

untouched field → remain quiet,
after blur/touch → validate,
submit → validate the complete form.

Error summary

The form could not be submitted. Correct 3 fields:
- Start date
- Email
- Department

For a long form, a summary near the top plus field-level detail is useful.

Form state

The browser Back button should not erase fifteen minutes of form work. History state, drafts, or suitable storage can be considered; client-side persistence of sensitive data requires a separate security analysis.

Unit 10: Wizards, Steppers, Task Lists, and Progressive Disclosure

A wizard can be useful when the process is naturally sequential, later steps depend on earlier answers, new users struggle with too many simultaneous choices, or high-risk decisions need staged verification.

1. Basic Information
      ↓
2. Scope
      ↓
3. Permissions
      ↓
4. Review
      ↓
5. Confirmation

When is a wizard the wrong choice?

If users perform the same task very frequently, need to compare fields simultaneously, or move back and forth between steps, a wizard may slow experienced users down.

Properties of a good wizard

the current step is visible,
total progress is understandable,
the previous step remains reachable,
data is preserved when moving back,
locked steps do not look accidentally active,
each step focuses on one logical subject,
the final step provides a review.

Review answers

GOV.UK notes that in small and medium-sized transactions, a review screen immediately before confirmation can increase confidence and help users correct errors.

Review

Name            Ali Koker      [Change]
Unit            ...            [Change]
Permission      ...            [Change]

[Confirm and Save]

Task lists

For a long process completed across multiple sessions, a task list may be more suitable than a linear wizard:

Application

[✓] Identity information
[✓] Contact details
[ ] Documents
[ ] Preferences
[-] Final review

GOV.UK uses this pattern for long, multipart transactions, while also recommending that the process first be challenged to see whether it can be simplified at all.

Progressive disclosure

Basic Settings
...
[ Show advanced options ]

Hiding advanced options can be useful, but hiding a frequently used critical function under the label “advanced” is poor information architecture.

Facebook Privacy Checkup

Meta's Privacy Checkup turns privacy and security settings into a topic-oriented guided flow. It is a useful example of managing complex settings through a guided review/wizard rather than a single oversized form.

A modal dialog:

interrupts the primary flow,
moves focus into itself,
temporarily makes the background unavailable,
forces the user to make a decision.

It should therefore be reserved for genuinely temporary work that requires focused attention.

In the WAI-ARIA modal dialog pattern:

focus moves into the dialog when it opens,
Tab cycles within the dialog,
Escape closes it where appropriate,
after closing, focus returns to a meaningful triggering element,
a visible close or cancel mechanism is available.

A visually centered <div> is not, by itself, an accessible modal. Focus management is part of the behavior.

Confirmation dialogs

Asking:

Are you sure?

for every action eventually teaches users to confirm reflexively. Confirmation is most valuable for actions that are:

irreversible,
high impact,
infrequent,
easy to trigger accidentally.

Where practical, a reversible action followed by Undo can produce a better experience.

Side panels

A side or detail panel is useful when:

the user needs details without losing list context,
a quick edit is required,
filters need a dedicated surface,
a record must be inspected briefly.

Deep, multi-section, validation-heavy forms should not be forced into a narrow side panel merely to avoid navigation.

Popovers

Popovers work for short contextual choices such as:

row actions,
quick filters,
small option lists,
secondary explanations.

A critical function must not be reachable only through hover; touch and keyboard users must have an equivalent path.

Unit 12: System Feedback, Loading States, and Perceived Performance

Actual speed and perceived speed

To the user:

Click → nothing → screen changes 1.5 s later

and:

Click → immediate pressed/loading state → result 1.5 s later

are different experiences even when backend time is identical.

web.dev's INP documentation explicitly discusses how delayed visual feedback can cause users to activate the same control repeatedly.

Choose the loading indicator according to the work

Skeleton

when the page structure is already known,
while content is being loaded.

Spinner

for a short operation,
when duration is unknown.

Progress bar

when actual progress can be measured.

Determinate progress

when a percentage or remaining work can be reported reliably.

Fabricating a percentage to make an operation look measurable damages trust.

Optimistic UI

For an action such as a “like” that is:

low risk,
easy to reverse,

the UI can update immediately and reconcile with the backend afterward.

The same approach is inappropriate for:

money transfers,
permission changes,
critical deletion,
creation of an official record,
security settings.

For such actions, the interface must not report success before the server has established success.

Toasts

A toast is appropriate for a state that is:

temporary,
low importance,
not requiring further user action.

A critical error should not disappear in a toast after a few seconds.

Empty states

Instead of a generic empty table:

No records

distinguish the reason:

No record has been created yet.             [New record]

or:

No records match these filters.             [Clear filters]

The result set is empty in both cases, but the user's next task is different.

Unit 13: Preventing Duplicate Requests and Race Conditions

This is where UI/UX directly meets data integrity. In high-traffic production systems, a double-click or a late search response is not merely a cosmetic defect. It can become a duplicate record, stale data overwriting a newer result, or an operator acting on the wrong record.

Problem 1: Double-click / repeated submission

A user can press Save twice:

POST /save
POST /save

Temporarily locking the action on the client is useful:

if (saving) return;
saving = true;

try {
    await save();
} finally {
    saving = false;
}

But this is not a data-integrity guarantee. The same logical action can be repeated:

from two tabs,
from another device,
by a retrying proxy or client.

Problem 2: Search request storms

Calling the backend on every character can produce:

a    → request 1
al   → request 2
ali  → request 3
alik → request 4

and waste network, CPU, and database capacity.

Debounce

let timer;

function scheduleSearch(value) {
    clearTimeout(timer);
    timer = setTimeout(() => search(value), 250);
}

250 ms is only an example. The delay should be selected from the real task and actual measurement.

Problem 3: An older request overwrites a newer result

request("a")      slow
request("alik")   fast

result for "alik" arrives
result for "a" arrives later
UI incorrectly returns to the stale result

Protection can use two layers:

cancel the previous request with AbortController,
also guard the result with a generation/sequence number.

let controller;
let generation = 0;

async function search(value) {
    controller?.abort();
    controller = new AbortController();
    const current = ++generation;

    const response = await fetch(`/search?q=${encodeURIComponent(value)}`, {
        signal: controller.signal
    });

    const data = await response.json();
    if (current !== generation) return;

    render(data);
}

This does more than reduce load: it ensures that the most recent user intent remains dominant in the UI.

Problem 4: Retrying mutations

Under HTTP semantics, GET, HEAD, OPTIONS, and TRACE are safe methods; safe methods plus PUT and DELETE have idempotent semantics. POST is not generally assumed to be idempotent.

That makes this sequence important:

POST sent
connection lost
did the operation happen on the server?

Idempotency keys

A common approach, especially in payment and ordering APIs, is:

POST /orders
Idempotency-Key: 550e8400-e29b-41d4-a716-446655440000

The server should not create the same logical operation twice when the same key is retried. Stripe's API is a well-known example of this model.

The protection layers belong at different levels

UI in-flight guard
        ↓
debounce / cancel
        ↓
idempotency key
        ↓
business invariant / transaction
        ↓
optimistic concurrency or unique constraint, when available

Disabling a button alone is not data safety.

Retry

Retry is safer when the operation is:

safe or idempotent,
failing transiently,
retried only a bounded number of times,
using exponential backoff,
using jitter.

Blindly retrying a non-idempotent POST without understanding its semantics can create duplicate data. RFC 9110 makes this distinction explicit.

Unit 14: Responsive and Adaptive Design

The goal of responsive design

Responsive design does not mean:

shrink the same desktop screen.

The goal is:

preserve the same user task across different viewports and input capabilities.

Viewport

A basic mobile-web declaration is:

<meta name="viewport" content="width=device-width, initial-scale=1">

A breakpoint is not a device name

Weak thinking:

iPhone breakpoint
iPad breakpoint
Laptop breakpoint

A better question is:

At what width does the content stop working well?

The content should determine the breakpoint.

Mobile-first and desktop

Mobile-first CSS is a useful engineering technique, but it should not turn desktop into an oversized phone. A wide screen can exploit:

comparison space,
multi-column data,
persistent navigation,
simultaneous detail panels.

NN/g likewise warns that mechanically scaling mobile patterns up to desktop can create unnecessary whitespace and fragmented information density.

Container queries

The viewport is not always the right signal for a component.

The same card may be:

800 px wide on a full page,
300 px wide inside a sidebar.

.card-container {
    container-type: inline-size;
}

@container (min-width: 40rem) {
    .card {
        grid-template-columns: 1fr 1fr;
    }
}

The component can then respond to its own available space rather than the device width.

`clamp()`

Fluid typography or spacing can be expressed as:

h1 {
    font-size: clamp(1.75rem, 1rem + 2vw, 3rem);
}

Using only vw can create extreme values on very small or very large screens. Minimum and maximum bounds matter.

Input capability

Screen width alone is insufficient:

@media (pointer: coarse) { ... }
@media (hover: none) { ... }
@media (prefers-reduced-motion: reduce) { ... }

A touch laptop, stylus, trackpad, and phone do not expose the same interaction capabilities.

Reflow

WCAG 2.2 Reflow aims, subject to defined exceptions, for content and functionality to remain available at the equivalent of 320 CSS px without requiring two-dimensional scrolling.

Content whose meaning genuinely requires a two-dimensional layout—such as some data tables, maps, and complex diagrams—must be evaluated separately.

Responsive prioritization

Desktop:

[Title] [Search................] [Filter] [Export] [New]

Mobile:

[Title]                          [⋯]
[Search............................]
[Filter 3]

The function remains; its placement and priority change.

A practical resolution test matrix

The following are test cases, not universal breakpoints:

| Class | Example CSS viewport | |---|---:| | Very narrow phone | 320 × 568 | | Phone | 360 × 800 | | Modern phone | 390 × 844 | | Large phone | 412 × 915 | | Small tablet | 768 × 1024 | | Tablet / landscape | 1024 × 768 | | Small laptop | 1366 × 768 | | Laptop | 1440 × 900 | | Desktop | 1920 × 1080 | | Wide display | 2560 × 1440 |

Also test:

200% browser zoom,
larger system fonts,
landscape orientation,
touch input,
keyboard-only operation,
dark mode,
reduced motion.

4K displays

A 4K monitor does not require content to span the entire screen.

Long-form text can remain inside a controlled readable measure:

|                     readable text column                     |

A data grid, timeline, or graphical workspace can use the additional width when the task benefits from it.

Responsive design is not equivalent to setting every component to width: 100%.

Material 3 NavigationBar is designed for three to five primary destinations on small screens. Apple similarly positions the tab bar as navigation among top-level areas of an application.

Appropriate:

[Home] [Search] [Tasks] [Notifications] [Profile]

Not appropriate:

[Save] [Delete] [Export] [Refresh]

The second group contains actions, not destinations.

Less visible does not mean less functional

A useful priority is:

keep the primary task visible,
place secondary tasks in overflow,
place infrequent advanced settings in an appropriate panel or sheet.

A wide layout may use a sidebar; a narrow layout can move to a compact top or bottom navigation model.

Desktop: persistent left navigation rail
Tablet: collapsible rail
Phone: 3–5 primary destinations in bottom navigation + More

If the information architecture has more than five equally important top-level areas, forcing all of them into bottom navigation is usually the wrong solution.

Unit 16: Accessibility — WCAG 2.2 and Keyboard Operation

WCAG target

W3C recommends WCAG 2.2 for new work. For enterprise web applications, WCAG 2.2 AA is a strong baseline target.

Keyboard access

Every important function should, where its interaction model requires it, be operable with:

Tab,
Shift+Tab,
Enter,
Space,
arrow keys,
Escape.

Focus must remain visible

:focus-visible {
    outline: 2px solid currentColor;
    outline-offset: 2px;
}

Removing focus indication only for aesthetic reasons is a serious usability defect.

WCAG 2.2 also addresses cases where a focused component becomes entirely hidden by sticky or fixed layers.

Target size

Under WCAG 2.2 Target Size (Minimum) at AA level, targets generally need to be at least 24 × 24 CSS px or satisfy one of the criterion's spacing or exception conditions.

That is an accessibility floor. On mobile, larger operational targets are often safer.

Tab pattern

In the WAI-ARIA tabs pattern:

Tab enters the tablist,
Left/Right Arrow can move between tabs,
automatic activation is suitable only when changing panels is effectively latency-free,
otherwise manual activation with Enter/Space can be better.

This is a direct point of contact between performance and accessibility.

Grid keyboard model

When an ARIA grid is genuinely required, application-level keyboard behavior may include:

Arrow keys between cells,
Home/End within a row,
Ctrl+Home/Ctrl+End across the grid.

Turning a semantic HTML table into an ARIA grid without need creates additional obligations.

Reduced motion

@media (prefers-reduced-motion: reduce) {
    *, *::before, *::after {
        animation-duration: 0.01ms;
        animation-iteration-count: 1;
        transition-duration: 0.01ms;
    }
}

A real product can apply this more selectively.

X also exposes accessibility preferences such as:

reduced motion,
autoplay control,
font size,
high contrast,
dark/dim themes,
keyboard shortcuts.

Screen readers and accessible names

Poor:

<button><i class="fa fa-trash"></i></button>

Better:

<button aria-label="Delete record">
    <i aria-hidden="true" class="fa fa-trash"></i>
</button>

Live announcements

Dynamic status:

<div role="status" aria-live="polite">
    Saved
</div>

Critical error:

<div role="alert">
    The record could not be saved.
</div>

Unnecessary use of aria-live, however, can make a screen-reader experience noisy.

Unit 17: Performance Is a UX Property

Core Web Vitals

Google's current Core Web Vitals thresholds classify performance as “good” at the 75th percentile when:

LCP ≤ 2.5 s
INP ≤ 200 ms
CLS ≤ 0.1

These are field-metric targets primarily for general web experiences; they do not replace an end-to-end SLA for a critical internal application.

INP and repeated activation

Poor responsiveness can produce:

Click
(no feedback)
Click
Click
...
event queue catches up

This is not merely a feeling of slowness. Multiple activations of the same event can become a functional defect.

CLS

If a banner appears above existing content after load and shifts the page downward:

the user may activate the wrong control,
reading position can be lost.

Space should be reserved in advance or the layout should remain predictable.

Lazy loading

Lazy loading can help for:

heavy off-screen images,
distant tabs,
large modules.

But over-splitting JavaScript required for the primary interaction can lengthen time to the first useful task. The objective is not merely “fewer initial bytes”; it is to make the critical user path usable earlier.

Unit 18: Security, Privacy, and Data Integrity Are Part of UX

Hiding UI is not authorization

if (!admin) hideDeleteButton();

is only a presentation decision.

The backend must still:

authenticate
    ↓
authorize action
    ↓
authorize resource scope
    ↓
validate invariant
    ↓
mutate
    ↓
audit

Sending unauthorized data and hiding it on the client is wrong

Poor:

Server → all records
Client → hide unauthorized records with CSS

Correct:

Server → authorized records only

Destructive actions

A deletion control should make clear:

the object name,
the scope,
whether recovery is possible.

“August 2026 Report” will be permanently deleted.
This action cannot be undone.

[Cancel] [Delete Report]

Dirty forms

When the user has made unsaved changes, the risk must be managed during:

closing a tab,
switching records,
navigating away.

Prompting on every navigation is also exhausting. The warning should appear only when a real dirty state exists.

Autosave

When autosave is appropriate, state should be visible:

Changed → Saving → Saved 09:41

In multi-user editing, autosave without:

revisioning,
optimistic concurrency,
conflict handling

can cause data loss.

Session timeout

Losing an entire long form at the end because “session expired” is both a UX and data-loss problem.

Without weakening the security policy, consider:

warning before timeout,
reauthentication,
preserving non-sensitive drafts.

Unit 19: What Can Be Learned from Large-Scale Products

When examining large products, it is more useful to ask which problem is being solved by a behavior than to copy its pixel layout. The same interface choice can fail under a different user population, revenue model, or critical internal workflow. The following examples are therefore design decisions to test, not ready-made recipes.

Facebook / Meta

When Meta reorganized Facebook settings, it described broader category grouping, closer placement of related options, improved settings search, and more visible access to Privacy Checkup. What matters here is not the exact menu shape but the refusal to make one navigation technique carry all complexity. Information architecture, search, and topic-oriented guided review can work together so that users do not need to memorize a deep settings tree.

Privacy Checkup provides another useful idea: high-impact privacy and security decisions are not simply stacked in one large form; they are divided into meaningful review topics. A similar approach can be considered for critical enterprise settings, provided that measurement shows which steps genuinely need guidance.

X

X publishes accessibility options including keyboard shortcuts, high contrast, reduced motion, autoplay control, font sizing, dark/dim themes, alternative text, and captions. The important lesson is that responsive design is not only a response to screen width. Motion, visual presentation, input capability, and content-consumption preferences are also variables to which the interface can adapt.

Amazon

Amazon's 2024 homepage work highlights personalized continuation points, related product groups, horizontal exploration, shortcuts for recurring tasks such as “Buy Again,” and measured iterative rollout of design variants. Its search experience similarly combines autocomplete, spelling correction, related queries, and image-plus-text discovery.

A more general principle is that users should not have to reconstruct the same context from zero in every session. “Recent,” “do again,” and “continue where you left off” paths can save substantial time when applied to the right tasks. I see the same effect in dense work applications: preserving context that operators repeatedly rebuild is often more valuable than adding another feature.

Hepsiburada

Hepsiburada's SEC annual reports describe several product-discovery paths working together: category and subcategory navigation, text search, detailed category search, barcode, image, and speech-to-text. Its 2025 report also states that roughly %90 of traffic came from mobile channels.

That figure belongs to Hepsiburada's own platform and should not be generalized to every Turkish web application. It still provides a concrete reminder of how risky it can be to treat mobile as a reduced secondary version of the desktop experience in consumer products.

Trendyol

A Trendyol Tech article on homepage architecture describes a page assembled from different component types that can be personalized, assigned to user groups, used in A/B tests, and fall back to default content. The architectural idea is to model a large homepage as independently measurable and orderable content units rather than one monolithic page.

That model should not be copied directly into a transactional enterprise interface. Dynamically moving a control that an operator expects in the same place every day damages spatial and muscle memory. Personalizing a dashboard and preserving placement stability in a high-frequency transaction UI are different problems.

Canvas and Moodle

The Canvas Student mobile application keeps destinations such as Dashboard, Calendar, To Do, Notifications, and Inbox in bottom navigation. Moodle 5.2 brings Course overview, Timeline, and Calendar together on a customizable dashboard.

Read together, these examples suggest a useful criterion for educational systems: the home screen should answer “What do I need to do now?” before it explains the institution to the user. The course list matters, but upcoming tasks, calendar, notifications, and communication often have equal operational value.

Istanbul University AKSIS and Sakarya University SABIS

Istanbul University's official AKSIS guide presents document requests through a task-oriented path such as Document Requests → New Request, followed by a table for existing requests. The useful point is not its current visual styling, but the clear separation between reviewing existing work and starting a new operation.

Sakarya University's official SABIS guides show a hub for student information, mail, educational information, library services, and other institutional applications. Inside the student-information domain, tasks such as courses, transcripts, and applications are separated through local navigation. For large multi-module systems, first choosing the work domain and then the task within that domain can produce a comprehensible two-layer structure.

These university guides should be used as field examples of real institutional task decomposition, not as contemporary UX standards.

Unit 20: Dashboard Design

A dashboard is not a report dump

A dashboard should answer:

What matters now?
What is waiting?
What changed?
What should I do?
Where is the risk?

Numbers need meaning and action

Poor:

[ 125 ]
[ 98 ]
[ 72 ]
[ 41 ]

The numbers have neither context nor action.

Better:

Pending Applications      125
+18 since yesterday
Oldest: 3 days
[Review]

Dashboard personalization

Platforms such as Moodle allow users to rearrange dashboard blocks.

In an enterprise system, personalization may help according to:

user role,
task frequency,
available screen space.

However, critical warnings that must be visible for safety or compliance should not be completely removable by the user.

Unit 21: Keyboard-First and High-Intensity Work Applications

A consumer website and an operator application do not have the same UX objective. For an experienced user who spends hours in the same record flow, a few hundred milliseconds of latency, focus that moves after every record, or a lost selection may look small in isolation yet accumulate into real productivity loss and error cost over a shift.

In systems used continuously by experienced users, the following matter:

mouse travel,
context switching,
repeatedly opening and closing modal dialogs,
tab order,
selection preservation,
scroll position.

Shortcuts

A good shortcut should be:

related to the task,
free of harmful conflicts,
discoverable,
reversible where relevant,
protected from accidental activation while typing into input fields.

Example:

Enter       → primary action on selected record
Esc         → close contextual panel
Ctrl+S      → save
F1 / ?      → shortcut help

Browser and operating-system shortcuts should not be captured without a strong reason.

Roving tabindex and composite widgets

In dense composite widgets such as tables, tablists, and toolbars, making every child control a separate Tab stop can create hundreds of stops.

Where the WAI-ARIA pattern calls for it, a better model can be:

Tab once into the composite widget,
Arrow keys within the widget.

Preserve selection

If a user is working on row 700, saving a detail, opening a side panel, or performing a short refresh should not throw the user back to row one.

State worth preserving may include:

selected record,
scroll position,
active tab,
filters,
sort order,
column widths.

Unit 22: Designing Responsive Forms and Tables Together

Desktop form

Name              [____________________]
Surname           [____________________]
Email             [____________________]

                         [Cancel] [Save]

When should two columns be used?

Prefer two columns for short, closely related fields:

Start [____]   End [____]
City  [____]   District [____]

Splitting a long form into two columns merely to fill empty space can make visual scanning harder.

Mobile

Name
[____________________]

Surname
[____________________]

Email
[____________________]

[Save]

Sticky action bar

On a long mobile form, the primary action may be pinned near the bottom.

Make sure that it:

does not cover content,
does not collide with the virtual keyboard,
does not obscure focused controls,
respects safe-area insets.

Unit 23: Design Anti-Patterns

On desktop, hiding primary navigation despite ample space can reduce discoverability.

2. Placeholder-only forms

The label disappears as soon as the user types.

3. Ambiguous icon-only actions

The user is forced to guess the meaning.

4. Critical functionality available only on hover

Touch and keyboard users may not be able to discover or reach it.

5. Color-only state

Meaning can disappear under color-vision differences, low contrast, or display conditions.

The user's context is interrupted continuously.

7. Infinite scrolling in administrative screens

Position, comparison, and returning to a known record become difficult.

8. Turning every screen into cards

Dense comparison data becomes visually inflated.

9. Disabled submit button with no explanation

The control is unavailable, but the user cannot tell why.

10. Solving duplicate submission only by disabling the button

The server can still receive duplicate logical operations.

11. Applying a filter without making it visible

The user may believe data is missing.

12. Skeleton forever

A backend failure remains hidden behind a perpetual loading state.

13. Resetting scroll position continuously

This causes serious productivity loss in dense work applications.

14. Treating desktop as an enlarged mobile screen

Wide screens can end up with excessive whitespace and unnecessary scrolling.

15. “Golden ratio = correct UX”

Research does not support this as a universal rule.

16. “Three clicks is the limit”

This is not a general empirical law.

17. Blindly copying a successful company

As NN/g emphasizes, a very large product may tolerate some design defects because of brand strength, habit, traffic, or other advantages. The same pattern can cause substantial loss in a smaller product or one with different tasks.

Unit 24: UI State Models

A data component does not have only “data” and “no data.”

A minimal state machine is:

IDLE
  ↓
LOADING
  ├── SUCCESS + DATA
  ├── SUCCESS + EMPTY
  └── ERROR

For a mutation:

CLEAN
  ↓ edit
DIRTY
  ↓ save
SAVING
  ├── SAVED
  ├── CONFLICT
  └── ERROR

Each of these states needs a deliberate UI representation.

Why does this matter?

Without an explicit model:

empty data and failure can look identical,
users cannot tell whether loading finished,
users may leave with unsaved changes,
a conflict may be displayed as an ordinary error,
duplicate submission may be triggered.

Unit 25: A Reliable Pattern for Form and Transaction State

An example record-edit flow:

GET entity + revision
        ↓
render
        ↓
user edits
        ↓
DIRTY
        ↓
Save clicked
        ↓
prevent duplicate submission
        ↓
PUT/PATCH + expected revision
        ↓
server validates authentication + scope + revision
        ├─ OK        → SAVED
        ├─ conflict  → CONFLICT UI
        └─ error     → ERROR + preserve entered data

The UI is not merely responsible for issuing a request; it must represent server-side state truthfully.

Unit 26: Design Systems

A design system is not just a component library

A mature design system includes:

design tokens,
components,
patterns,
content guidance,
accessibility behavior,
interaction states,
responsive behavior,
code standards.

Tokens

:root {
    --space-xs: .25rem;
    --space-sm: .5rem;
    --space-md: 1rem;
    --space-lg: 1.5rem;

    --radius-sm: .25rem;
    --radius-md: .5rem;
}

Tokens allow visual changes to be applied consistently and controllably across a product.

Component states

A button has more than a default state:

default
hover
focus
active
disabled
loading

An input may be:

empty
filled
focused
invalid
disabled
read-only

Every state belongs to the component's design contract.

Pattern level

A “form” is not one component; it is a pattern.

Structures such as a user picker, bulk editing, filter bar, wizard, or command palette coordinate behavioral contracts across multiple components.

Unit 27: User Habits and Muscle Memory

In a heavily used application, users do not only see the interface; they learn movement sequences. Keyboard flows that remain stable in production for a long time can become an almost automatic work rhythm.

For example:

Enter → open record
Right → next record
Ctrl+S → save

can become muscle memory after sustained use.

Why can a small change have a large effect?

Moving a button from:

bottom-right → upper-left

is technically simple but can affect hundreds of daily actions.

Therefore, in a dense production system with established behavior:

adding a new feature and changing an existing behavior do not belong to the same risk class.

UX regression testing

Screenshot tests alone are not sufficient.

End-to-end task scenarios should also be verified, for example:

1. Search
2. Select record 17
3. Move forward three records using the keyboard
4. Change a detail
5. Save
6. Return to the previous list position

Unit 28: Role- and User-Profile-Aware UX

Within the same system, the following users do not have identical needs:

a new user,
an expert operator,
an administrator,
a read-only user,
a mobile user.

Progressive expertise

A new user may use:

[New Record — with visible guidance]

while an expert reaches the same function with:

Ctrl+N

Role-aware interfaces

An action the user cannot perform may, depending on product requirements:

be hidden,
remain disabled with an explanation.

But server-side authorization remains mandatory.

Risky administrator actions

Administrative screens may contain many actions. Destructive actions should:

be visually distinct,
not be placed accidentally adjacent to the primary action,
make their scope explicit.

Unit 29: UX Principles for Educational Platforms

In an LMS or student information system, users usually want to complete time-bound tasks rather than simply “explore content.”

Core questions include:

What do I need to do today?
Which class do I have?
What is the deadline?
Has my grade been published?
Which application is still pending?
Is my document ready?

Dashboard

A useful academic dashboard might show:

Today
- 10:00 Class
- 16:00 Assignment deadline

Upcoming
- Friday exam
- Application deadline

My Courses
- ...

Notifications
- ...

Academic information density

Some student-information screens are naturally dense:

transcripts,
course registration,
examination schedules,
curricula.

Instead of expanding them into large cards, the following may be more efficient:

tables,
group headings,
sticky columns,
totals,
descriptive states.

Transaction history

For processes such as applications and documents, a traceable table can create confidence:

Request Date
Document Type
State
Last Action
Download / Details

Unit 30: Measuring UI/UX

“This design looks good” is not a measurement.

Task metrics

task-completion rate,
time on task,
error rate,
recovery time,
abandonment rate.

Interaction metrics

search success,
zero-result queries,
filter usage,
repeated clicks,
rage clicks,
backtracking,
validation errors,
use of undo.

Performance

LCP,
INP,
CLS,
API latency,
render latency.

Additional metrics for expert applications

keyboard-only completion,
mouse clicks per transaction,
time per record,
rate of acting on the wrong record,
number of context switches.

Usability testing

A test with a small number of users does not prove behavior for the entire population, but small tests can still expose severe defects early.

A stronger evaluation loop is:

heuristic review
      ↓
prototype test
      ↓
task-based usability test
      ↓
production telemetry
      ↓
field feedback
      ↓
iteration

Unit 31: Responsive Design and Accessibility Acceptance Matrix

A screen should not be declared “responsive” merely because it looks acceptable in a phone preset inside Chrome DevTools.

Visual

Can the primary task be completed at 320 CSS px?
Is any content lost at 200% zoom?
Is text clipped?
Does the toolbar overlap itself?
Does a sticky header cover focused elements?
Does landscape orientation work?

Keyboard

Is the tab order logical?
Is focus visible?
Is focus trapping inside a modal correct?
Does Escape work as intended?
Is arrow-key navigation inside a tablist correct?

Touch

Are targets large enough?
Is any function available only on hover?
Is the risk of accidental activation high?

Is the heading structure correct?
Are form labels associated correctly?
Are table/header relationships correct?
Are state changes announced when necessary?

Performance and network

Under simulated high latency, is there a visible loading state?
Are requests repeated unnecessarily?
Can an old request overwrite a newer result?
Can repeated submission create duplicate mutations?

Unit 32: A Baseline Layout for a Web Application

Dense desktop work application

┌──────────────────────────────────────────────────────────────────────┐
│ Logo / Product       Global Search           ?   🔔   User ▾       │
├───────────────┬──────────────────────────────────────────────────────┤
│ Primary nav   │ Breadcrumb / Location                                │
│               │ Page Title                       Primary Action      │
│ Dashboard     │                                                        │
│ Records       │ Search / Filter / Toolbar                              │
│ Reports       │                                                        │
│ Administration│ Main workspace                                         │
│               │                                                        │
│               │                                                        │
└───────────────┴──────────────────────────────────────────────────────┘

Mobile

┌───────────────────────────┐
│ ←  Page Title         ⋯   │
├───────────────────────────┤
│ [ Search................] │
│ [Filter 2]                │
│                           │
│ Main content              │
│                           │
├───────────────────────────┤
│ Home Records Tasks Profile│
└───────────────────────────┘

This is not a product requirement. It is only a starting point derived from established conventions.

Unit 33: Data-Table Checklist

Structure

[ ] The table title explains the task.
[ ] Total/result scope is visible.
[ ] Search is visible when needed.
[ ] Active filters are visible.
[ ] Sort direction is visible.
[ ] Column names are unambiguous.
[ ] Numeric values are aligned for comparison.
[ ] Date formatting is consistent.
[ ] State is not communicated by color alone.
[ ] Empty, loading, and error states are distinct.

Interaction

[ ] Row selection is visible.
[ ] Multi-select has a clear scope.
[ ] Batch actions are visible/active only when selection exists.
[ ] Destructive actions are separated.
[ ] Pagination/scrolling matches the task.
[ ] Refresh does not unnecessarily reset selection.
[ ] Keyboard behavior is defined.

Responsive behavior

[ ] The most important columns remain available on narrow screens.
[ ] Horizontal scrolling, when used, is discoverable.
[ ] Row actions remain accessible.
[ ] Sticky toolbar/first-column behavior does not overlap.
[ ] 200% zoom has been tested.

Unit 34: Form Checklist

[ ] Every field is genuinely necessary.
[ ] Known data is not requested again.
[ ] Labels remain visible.
[ ] Placeholder text is used only for examples or hints.
[ ] Required/optional state is understandable.
[ ] Field order is natural.
[ ] Input type is appropriate.
[ ] Autocomplete has been considered.
[ ] Help text is available before an error occurs.
[ ] Client- and server-side validation are separated.
[ ] Error messages explain what to correct and how.
[ ] Entered data survives validation errors.
[ ] Submission is protected from accidental repetition.
[ ] Server-side mutations are protected from duplicate logical requests.
[ ] Success is visible.
[ ] Dirty-state loss has been considered.
[ ] Keyboard-only use works.
[ ] The mobile keyboard does not hide required content.

Unit 35: Wizard Checklist

[ ] The task is genuinely multi-step.
[ ] A single form would not be better.
[ ] Step titles are meaningful.
[ ] Progress is visible.
[ ] Back does not lose data.
[ ] Skip exists only for truly optional steps.
[ ] Users understand why a locked step is locked.
[ ] A final review is available.
[ ] It is clear when the mutation actually occurs.
[ ] Resume/draft behavior has been considered for long processes.
[ ] Expert users are not slowed down without need.

Unit 36: Application Top-Bar Checklist

[ ] In an LTR web interface, brand/home is on the logical leading side and returns home.
[ ] Primary navigation is visible or available in a task-appropriate sidebar.
[ ] Utility actions are not confused with primary navigation.
[ ] Account/profile placement is consistent in the trailing utility area.
[ ] Search is visible when it is central to the product.
[ ] Help is accessible.
[ ] Notification badges are reserved for meaningful events.
[ ] Critical destinations do not disappear on mobile.
[ ] The top bar does not consume an excessive portion of the screen.
[ ] Focus is not hidden under a sticky header.

Unit 37: An Evidence Hierarchy for Design Decisions

A useful order for evaluating a design decision is:

1. Data integrity / security
2. Normative accessibility
3. Task correctness
4. Real user research
5. Product telemetry
6. Established platform convention
7. Design system
8. Aesthetic preference
9. Trend

For example:

“The golden ratio looks better.”

and:

“The operation cannot be completed at 320 CSS px reflow.”

are not claims of equal weight.

Likewise:

“This toolbar looks more modern.”

cannot invalidate the finding:

“An experienced user now needs 11 interactions instead of 4 to complete the same task.”

Unit 38: The Real Lessons to Take from Large-Scale Systems

The value of Facebook, X, Amazon, Trendyol, Hepsiburada, Canvas, or Moodle is not a particular pixel arrangement.

The recurring principles are more useful:

Build information architecture around user tasks.
Shorten high-frequency paths.
Let users continue from where they left off.
Treat search as a real discovery system.
Support the same task on desktop and mobile with layouts appropriate to each environment.
Make system state visible.
Do not treat accessibility as a layer added after component design.
For irreversible operations, place security and data integrity ahead of cosmetic convenience.
Preserve expert users' muscle memory.
Do not adopt a new pattern merely because it is fashionable; validate it with task testing or measurement.
Do not confuse hiding functionality with simplifying it.
Measure real use.

Unit 39: The Zen Approach — Simplicity Is Not Emptiness, but the Absence of Unnecessary Burden

The first mistake in applying a Zen perspective to web interfaces is equating simplicity with white space and a small number of components. A complex work application may contain hundreds of genuine business rules, record types, and actions. Removing them visually does not make the system simple; it merely hides complexity from the user and often moves it to the wrong place.

The source material, especially Simple and Usable, Designing Interfaces, The Design of Everyday Things, and Don't Make Me Think, approaches the same idea from different directions: the purpose of an interface is not to display itself, but to help the user achieve a goal.

From a Zen perspective, a good interface repeatedly asks:

What is the user actually trying to accomplish, and what unnecessary burden does this screen place in front of that work?

That burden is not only visual. It includes:

unnecessary decisions,
data entered repeatedly,
meaningless confirmations,
lost selection,
filters that must be rebuilt every time,
no feedback while waiting,
codes the user is forced to memorize,
controls whose positions keep changing,
performing the same task differently on two screens,
unnecessary network requests,
misleading error messages,
small actions that cannot be undone,
menus that merely expose the system's internal architecture.

Simplicity and subtraction are not the same thing

Four classes of simplification can be useful:

Remove: eliminate a function or information that contributes nothing to the real task.
Organize: group necessary complexity into understandable structures.
Hide: move infrequent but necessary capabilities to a second layer with the right cues.
Displace: move work to a more suitable device, time, layer, or automation mechanism.

Simple and Usable distinguishes these strategies explicitly. The important point is not to confuse “hide” with “remove.”

The quiet interface

A quiet interface is not silent. It speaks only as much as the task requires.

For example:

Saving…
Saved

is often enough, while:

SUCCESS!
YOUR OPERATION HAS BEEN COMPLETED SUCCESSFULLY!!!
[OK]

wastes attention.

On the other hand, if a critical record truly failed to save, hiding that fact in a small disappearing toast is an equally harmful form of excessive quietness.

Few components ≠ simple system
Few decisions + clear context + stable behavior + low error cost = simple experience

Unit 40: The User's Goal — The Interface Is a Tool, Not the Goal

Designing Interfaces treats the reason a user opens an interface as the starting point for design. Users do not really want to press buttons, look at tables, or fill forms. They want to:

find a record,
complete work,
compare something,
produce a result,
verify a condition,
finish an application or transaction.

Keep asking “Why?”

A feature request may arrive as:

Add a quick filter here.

The underlying need may be:

Why a quick filter?
→ Because every morning the user selects the same three scopes.

Why every morning?
→ Because the screen does not preserve the previous work context.

Actual problem:
→ Not a missing filter, but repeated loss of context.

Understanding the root task before implementing the first requested control can lead to a simpler solution.

User research is not marketing research

Simply asking:

Would you like this feature?

is not enough.

Direct observation

Especially in expert-operator systems, observed behavior can differ from reported behavior.

A user may say:

I use the mouse.

while observation reveals a learned sequence such as:

Enter → Right → Right → Ctrl+S → Down

If that behavior has formed over years in production, changing it merely to make the product look “modern” can create a serious UX regression.

The center of design is the task, not the screen. A component has value only to the extent that it advances the task.

Unit 41: Safe Exploration — Users Should Not Be Afraid to Try

The Safe Exploration pattern in Designing Interfaces emphasizes that the cost of experimentation should be low enough for users to learn the interface.

Users should be able to:

open the wrong tab,
try a filter,
change a view,
make a temporary selection,
undo an action when that is realistically possible,

without losing data in most of these cases.

Preconditions for safe exploration

System state is visible.
A path back exists.
Destructive actions are separated from ordinary navigation.
Temporary selection and persistent mutation are clearly distinct.
Form data is not discarded unnecessarily.
When undo is impossible, the consequence is stated in advance.

Preview

For a high-impact operation, preview can precede mutation:

Select scope
   ↓
Preview
   ↓
37 records will be affected
   ↓
Confirm
   ↓
Mutation

This does not mean adding confirmation to every minor action. Seeing scope in advance, especially for batch operations, aligns the user's mental model with the system's actual effect.

Undo versus confirmation

Confirmation asks the user to predict a future result.

Undo lets the user see the result and then reverse it.

For a reversible, low-risk operation:

Archived. [Undo]

is often more fluid than:

Are you sure you want to archive this?

Safe exploration and security

For permissions, money, official data, permanent deletion, or forensic records, freedom to experiment cannot outrank data safety. In those domains, safe exploration may mean making scope unmistakable and preventing the wrong action before it starts, not merely making the action easy to undo.

Give users room to move, but do not draw an invisible path along the edge of a cliff.

Unit 42: Satisficing, Expertise, and the “Good Enough” Path

People usually do not search for the theoretically optimal route through an interface. They find the first route that completes the job adequately and reuse it. This behavior is commonly described as satisficing.

Consequence

A function may be:

shorter,
faster,
more powerful,

and still remain undiscovered.

The existing route may be perceived as:

works
learned
low risk

New and expert users are different

A new user may benefit from:

explicit labels,
explanation,
guidance,
a wizard,
a visible primary action.

An expert may value:

keyboard shortcuts,
batch operations,
quick filters,
recent items,
saved views,
direct navigation.

The same product can support both:

New user:
[Visible Save button]

Expert:
Ctrl+S

Progressive expertise

The interface can remain learnable at first while allowing users to discover faster paths over time.

“Easy” and “fast” do not have to be opposing goals.

Satisficing and change risk

If users have followed this path for years:

A → B → C

and a redesign changes it to:

A → X → C

the new path may save one click and still damage learned behavior.

Step count alone is not enough without measuring the actual gain.

Do not force users to learn the shortest route. Keep the known route safe and make the better route discoverable.

Unit 43: Deferred Choices and Progressive Disclosure

Users do not need to make every decision at the beginning. The Deferred Choices and Progressive Disclosure patterns in Designing Interfaces support postponing decisions that are not yet necessary.

The cost of early decisions

A poor starting screen might be:

Output format
Encoding
Advanced option
Compression
Cache
Sort
View
Theme
Detail level
...
[Start]

The user is being asked to resolve technical options before even seeing the primary task.

A better start may be:

What do you want to do?
[Open File]

and only later, when needed:

[Advanced options]

Three conditions for progressive disclosure

Before hiding a feature, verify that:

it is used infrequently,
it does not block the primary task,
users can still find it when needed.

Without discoverability, progressive disclosure becomes feature loss.

Progressive disclosure across stages

A wizard can reveal information only at the relevant step:

1. Scope
2. Parameters
3. Review
4. Confirmation

The user does not need to process all choices simultaneously.

The danger of “advanced” settings

Moving a setting used every day under:

Advanced > Other > More > Options

is not simplification.

Frequency and task importance must be evaluated together.

Show as much information as the task needs, at the time it needs it—neither too early nor too late.

Unit 44: Habit, Spatial Memory, and Stable Layout

Designing Interfaces treats habit formation and spatial memory as important interaction patterns.

Over time, users learn not only what an icon means but where it lives. In an operational screen that already works, a few pixels of cosmetic adjustment and a spatial change that alters the work flow should not be treated as the same risk class.

For example:

Upper-left → primary navigation
Upper-right → account / utilities
Rightmost table column → row actions
Bottom-right → primary form action

can create strong spatial memory.

The hidden cost of moving things

Moving a button for purely visual reasons can affect:

mouse travel time,
visual scanning,
error rate,
disruption of learned habits.

Dynamic layout risk

If new content appears just as the user is about to click and moves the target, this is not only a CLS problem; it is also a motor-memory problem.

Continuity in record selection

In a dense grid application:

row 812 selected
→ open detail
→ save
→ grid refreshes
→ return to row 1

destroys working context.

Where possible, preserve:

selected key,
scroll position,
active tab,
focus,
filters,
sorting.

Continuity while changing course

The Changes in Midstream idea accepts that users may change their mind or context during a task.

The interface should tolerate:

going back,
changing a field,
revising a filter,
looking at another record and returning.

Stability is an invisible usability property. Once the user has learned something, changing it requires a real reason.

Unit 45: Attention, Working Memory, and Cognitive Budget

100 Things Every Designer Needs to Know About People, Design for How People Think, and Laws of UX all emphasize that interfaces are used through limited attention and memory resources.

Users do not see everything

Being present on the screen does not guarantee being noticed.

Items especially likely to be missed include:

a right column that resembles advertising,
a small icon inside a dense toolbar,
status color that blends into the background,
critical information below the fold.

Externalize working memory

Instead of asking users to:

remember the code from the previous page
→ enter it on this page

keep the context visible:

Selected record: 10428 — ...

Grouping

Long sequences of information should be divided into meaningful groups.

Poor:

30 fields in one undifferentiated form

Better:

Identity
Contact
Permissions
Validity

Simply putting visual cards around fields is not meaningful grouping. The groups should match the user's understanding of the domain.

Hick's principle

As the number and complexity of choices increases, decision time can also increase. This matters for:

menus,
categories,
filters,
initial actions.

The solution is not always to reduce the number of options. Good grouping and search can make a large choice space manageable.

Do not misuse Miller's number

The claim “people remember only 7 ± 2 items, therefore a menu may contain at most seven choices” is not a reliable UI rule.

Menu use involves:

recognition,
categorization,
visual scanning,

which differs from a working-memory recall task.

Do not use the user's memory as a database or their attention as an unlimited processor.

Unit 46: Affordance, Signifier, Mapping, Constraint, and Conceptual Model

Don Norman's design approach considers not only whether a control exists, but whether the user can understand how it should be used.

Affordance

An affordance is an interaction that an object makes possible.

Signifier

A signifier communicates that the interaction is possible.

On the web, signifiers can include:

borders,
underlines,
button shape,
hover/focus state,
labels,
icons.

Invisible clickability

Text may technically have a click handler while looking like an ordinary paragraph. The interaction exists, but the signifier is insufficient.

Mapping

The relationship between a control and its effect should be natural.

For an audio example:

Left-channel control → left channel
Right-channel control → right channel

If the mapping is reversed, the user must perform a mental transformation every time.

Constraints

It is often safer to narrow the available action space than to accept an invalid action and explain it afterward.

For example, if:

End date < Start date

is invalid, the design can consider preventing impossible selections rather than waiting until submission to report the error.

Conceptual model

The user's mental model does not need to match the real architecture exactly, but it must be sufficient to predict behavior.

For example, “Draft” should support a clear model such as:

Draft → temporary work visible only to me
Publish → others can see it

Good design embeds as much of the operating manual as possible into the behavior of the object itself.

Unit 47: Interaction as Conversation — Feedforward and Feedback

Designing Interfaces frames interaction as a conversation between the user and the system. Strategic Writing for UX treats the words in that conversation as a systematic design problem.

Feedforward

Before an action, answer:

What will happen if I do this?

[Export 24 records]

provides more useful feedforward than:

[OK]

Feedback

After the action, answer:

What happened?

24 records exported.

Better action labels

Instead of a generic:

[Submit]

use a label that reflects the result when possible:

[Submit Application]
[Generate Report]
[Save Changes]

The rhythm of system communication

Opening a modal for every small state change is like constantly interrupting the other person in a conversation.

A more natural rhythm is:

minor status → inline/state area,
important but transient → notification,
action required from the user → persistent visible message,
critical decision → modal or dedicated step.

The interface should speak sparingly, but never ambiguously when it does speak.

Unit 48: Designing for Human Error — Slips, Mistakes, and Recovery

Don Norman treats human error not as an isolated defect in the user, but as part of the design problem between people and systems.

Slip

The goal is correct but execution is wrong.

Examples:

clicking Delete on the wrong row,
touching the adjacent menu item,
pressing Enter instead of Ctrl+Enter.

Mistake

The user's mental model or decision is wrong.

Examples:

interpreting “Archive” as “Delete,”
misunderstanding the scope of a date filter,
assuming inactive records will not be visible.

Different error, different remedy

For slips, useful protections include:

larger targets,
separating destructive actions,
undo,
correct focus behavior,
stable layout.

For mistakes, the solution may require:

better labels,
clearer scope,
preview,
a better conceptual model,
help.

Forcing functions

Some critical operations should make an invalid sequence impossible.

For example:

The mutation API cannot execute until permission scope has been validated.

Hiding a button in the UI is not a forcing function for security; the rule must exist as a server-side invariant.

Confirmation fatigue

If every action triggers confirmation, users learn to confirm without reading.

Confirmation is meaningful mainly when there is:

high impact,
low frequency,
irreversibility,
unclear scope.

“Do not make mistakes” is not design. Narrow the path to error, make errors visible, and make the resulting harm reversible whenever possible.

Unit 49: How to Use the “Laws” of UX Psychology

Laws of UX makes psychological findings accessible under memorable headings. These are not context-free laws of physics.

Jakob's Law

Users spend most of their time in other products, so established conventions shape expectations in a new one.

Result:

Breaking standard behavior requires a measurable reason.

Fitts's Law

Time to reach a target is related to its:

distance,
size.

A frequent action should not be tiny and far away.

Hick's Law

As the decision space grows more complex, selection time can increase.

Possible responses include:

grouping,
defaults,
search,
progressive disclosure.

Postel-style tolerance

Tolerance in parsing user input can be useful, but unlimited tolerance in security or data semantics can produce incorrect results.

These phone representations may normalize to the same semantic value:

(555) 123-45-67
5551234567
555 123 45 67

But:

invalid date
unauthorized scope

must not be accepted in the name of tolerance.

Peak–End Rule

People's evaluation of an experience can be disproportionately affected by intense moments and the ending, not only by the average moment.

That makes the following especially important:

final confirmation,
success screen,
recovery from error,
transaction closure.

Aesthetic–Usability Effect

An attractive interface may initially feel easier to use. That does not remove real usability defects.

Von Restorff Effect

An element that differs from its surroundings attracts attention.

Reserve strong differentiation for genuinely primary or critical elements. If everything is emphasized, nothing is emphasized.

Tesler's Law / conservation of complexity

Some business complexity cannot be eliminated; it can only be shifted among:

the user,
the UI,
the backend,
the process.

The system should absorb complexity where it can do so correctly. If correctness cannot be guaranteed, fake automation is not simplification.

Doherty Threshold

Fast feedback helps preserve flow. The important implication is:

a heavy operation may not be able to finish immediately,
but initial feedback should still be fast.

Use psychological principles as design hypotheses, not decorative “laws”; validate them against the real task.

Unit 50: Four Strategies for Simplification — Remove, Organize, Hide, Displace

One of the most practical frameworks in Simple and Usable treats complexity through four different strategies.

1. Remove

Candidates include:

unused functionality,
duplicate controls,
meaningless explanations,
fields that ask for data the system already knows,
dashboard metrics that support no decision.

Critical information must not be removed merely to make the screen look sparse.

2. Organize

When complexity is real, organization matters:

chunking,
sections,
hierarchy,
prioritizing frequent work,
ordering around user behavior,
consistent grids.

3. Hide

An infrequent but necessary feature may move under:

Advanced

But discoverability must remain through:

signifiers,
hints,
search,
correct labels.

4. Displace

Complexity can move to another layer.

For example:

Do not ask the user to select a date format every time
→ apply locale/system preference.

or:

Use mobile for a short task and desktop for detailed administration.

“Leave the decision to the user” is also a form of displacement, and sometimes a poor one. If the system can make a safe, reliable default, it should not force an unnecessary decision.

Smart defaults

A good default should be:

likely,
safe,
reversible,
context-appropriate.

A dangerous default cannot be:

Delete all records

Simplicity is not a sequence of cutting first and hiding later. Understand the task first; then determine which complexity genuinely needs to exist.

Unit 51: A Form Is Not a List of Questions; It Is a Controlled Conversation

Designing UX: Forms treats form experience not merely as label placement, but as a chain in which the user understands the question, finds the answer, judges whether the answer is appropriate, and physically enters it.

Every question has a cost

Adding a field creates costs in:

reading,
understanding,
remembering,
deciding,
entering data,
validation.

Therefore:

“This field exists on the backend” is not sufficient reason to put it in the form.

Language of the question

Ask for the real-world meaning, not the institution's internal data model.

Poor:

STAT_CD

Better:

Record status

Do not ask again for an answer the system already knows

If the system reliably knows:

user identity,
role,
previous preference,
context,

it should not ask again without a reason.

Smart prefill

Prefilling is useful when:

the value is very likely to be correct,
the user can correct it,
privacy constraints permit it.

A wrong prefilled value can be more dangerous than an empty field because users may submit it without noticing.

Format tolerance

Data that people naturally write in different valid forms can be normalized where possible.

Normalization must not destroy meaning.

Review

For a critical form, a final sequence such as:

Input → Review → Confirm

can reduce errors, especially in multi-field mutations.

Every question is a small debt collected from the user. Do not ask unnecessary questions.

Unit 52: Complex Data and Actions — Separate “Show” from “Do”

Designing Interfaces describes different pattern families for lists, complex data, actions, and commands. That separation is important in dense web applications.

Data-viewing tasks

The user:

finds,
compares,
sorts,
filters,
opens details.

Action tasks

The user:

changes,
saves,
performs batch operations,
undoes,
exports.

When these two task families are mixed indiscriminately in the same toolbar, operational risk increases.

Selection model

A table must be consistent about whether:

click row = select only

or:

click row = open details

Legacy desktop behaviors such as double-click should be used carefully on the web and on touch interfaces.

Cancelability

If a long operation can truly be cancelled:

Generating report...
[Cancel]

user control increases.

But if Cancel merely hides the loading indicator while server-side work continues, the control is semantically dishonest.

Command history and undo

In expert tools, making past actions visible can improve:

auditability,
recovery,
learnability.

Viewing data and mutating data should not carry the same visual weight.

Unit 53: UI Text Design — Words Are Components Too

The source material from Strategic Writing for UX treats interface text not as an empty field filled at the end, but as a functional part of the experience.

Headings

A heading tells the user location and task.

Ambiguous:

Operations

Better:

User Permissions

Buttons

Button text should describe the result.

Instead of:

[OK]

prefer, where appropriate:

[Save Changes]

Empty states

An empty state should explain not only that data is absent, but also what the user can do.

No records yet.
[Create new record]

or:

No records match these filters.
[Clear filters]

Errors

A good error message answers, where possible:

What happened?
What can the user do?
Was any data lost?

Notifications

A notification should explain:

what happened,
why it matters,
the next action if one is required.

Voice and tone

The same product does not need the same emotional tone for:

success,
critical failure,
first-time guidance,
security warnings.

A critical error should not sound like:

“Oops! Something went wrong :)”

Brevity

The goal is not the shortest possible text. The goal is the shortest sufficient text that communicates the result clearly.

Remove words that do not clear the user's path; do not withhold the words needed at a decision point.

Unit 54: Prototyping — Make Behavior Visible Before Debating Design

Designing UX: Prototyping and Figma-oriented material treat prototypes not simply as visual mockups, but as tools for testing hypotheses.

Fidelity should match the question

Low fidelity:

information architecture,
task flow,
comparing ideas.

High fidelity:

real navigation,
micro-interactions,
responsive behavior,
usability testing.

When is a coded prototype necessary?

A static design tool may not represent reality when the important variables include:

actual keyboard behavior,
scrolling,
virtualized grids,
audio/video,
performance,
API states,
touch input.

A prototype is not production

A prototype that works with:

fake data + one user + zero latency

is not equivalent to production with:

high latency + authorization + concurrency + duplicate data + failure

Test scenarios

Instead of asking:

Do you like this design?

give a task such as:

Find an incomplete application from the last three months and open its details.

Move design discussion away from a contest of opinions and toward observation of behavior.

Unit 55: Emotional Design, Trust, and Perceived Quality

Don Norman's Emotional Design considers emotional response alongside functional correctness.

Three simplified levels

initial perception: appearance, composition, feel,
use: control, performance, comprehensibility,
reflection: meaning and trust over the longer term.

Aesthetics must not hide failure

A visually pleasing interface can improve:

initial trust,
willingness to use,
perceived ease.

But aesthetics cannot compensate for:

data loss,
unauthorized visibility,
slow operations,
ambiguous state.

Designing trust

In an enterprise system, trust grows from:

consistent behavior,
correct results,
a clear audit trail,
visible record timestamps,
recoverability,
predictable failure behavior.

Calmness is not merely a color palette. A system that keeps its promises is the strongest source of calm.

Unit 56: Tragic Design — Sometimes the Cost of Bad UX Is More Than Annoyance

Tragic Design centers cases where design failure produces not only conversion loss or dissatisfaction, but serious real-world harm.

High-risk products

In domains such as:

healthcare,
public safety,
finance,
transportation,
industrial control,
authorization,
critical infrastructure,

a UX decision can also be a safety decision.

Dangerous simplification

Hiding critical status to create a “clean interface” can exchange aesthetic gain for operational risk.

Dark patterns

Patterns that steer users toward:

accidental consent,
inability to unsubscribe,
difficulty finding privacy controls,
unnecessary sharing,

are manipulation, not usability.

Error budget

The acceptable probability of user error in a high-risk operation is not the same as for a social-media Like button.

Human factors

In a critical system, “the user should have paid attention” is a weak defense. An operator performing the same task at high frequency will never have zero probability of error. The interface should systematically reduce both probability and consequence by:

reducing wrong selection,
making state visible,
explaining critical outcomes clearly,
providing a second safety layer where appropriate.

Do not hide reality in the name of simplicity. Critical information may be quiet; it must not be invisible.

Unit 57: Design Systems — Infrastructure for Consistency

A common lesson across Designing Interfaces, Figma resources, and works such as Practical UI Patterns for Design Systems is that a design system is not merely a component repository.

Four layers

Token
  ↓
Primitive
  ↓
Component
  ↓
Pattern

For example:

space-md
  ↓
button padding
  ↓
Button
  ↓
Save Form pattern

Behavioral contract

A component is more than CSS.

A Button also needs defined behavior for:

focus,
loading,
disabled state,
keyboard operation,
accessible name,
duplicate-submission guard.

Pattern contract

A modal dialog standardizes behavior such as:

focus entry,
focus trap,
Escape,
close button,
return focus,
backdrop behavior.

Consistency and product speed

A standardized component can reduce:

repeated decisions on every screen,
accessibility defects,
small behavioral inconsistencies.

A design system is not dogma

A real business problem should not be forced into an existing component when it does not fit.

When a new pattern is necessary, a traceable process can be:

problem → evidence → pattern → documentation

Solving the same problem again on every screen is noise. A good system quietly removes repeated decisions.

Unit 58: Continuity Across Devices — A Broader Problem Than Responsive Layout

Responsive design changes layout. Multi-device experience preserves the task.

The “displace” strategy in Simple and Usable and mobile-design literature shows that some work can move to a different device or context.

Not every task is equally suitable for every device

A phone can be strong for:

quick checking,
notifications,
short approvals,
barcode/camera tasks,
location-aware work.

A desktop can be strong for:

large-data comparison,
multi-column grids,
keyboard-intensive work,
long editing sessions.

Feature parity is not always the right target

“If desktop exposes 47 features, all 47 must be visible on the phone at once” is often the wrong model.

A better target is:

Can users complete the tasks that genuinely matter on mobile, completely and safely?

Continuity

For example:

See notification on phone
→ save the task
→ continue from the same context on desktop

State transfer

Context such as:

drafts,
recent items,
saved searches,
task state,

can be preserved safely across devices.

For sensitive data and shared-device scenarios, continuity must be evaluated together with privacy.

Do not force every device into the same screen. Preserve the same goal in a form appropriate to the device.

Unit 59: Recommended Books

The following works are especially valuable for extending this note through book-based study.

1. Designing Interfaces, 3rd Edition

Jenifer Tidwell, Charles Brewer, Aynne Valencia — O'Reilly

Priority: Very high

Coverage:

interaction patterns,
information architecture,
navigation,
layout,
forms,
data,
responsive/mobile design,
complex application patterns.

This is the book most likely to deepen the application-pattern layer of this note.

2. The Design of Everyday Things — Revised and Expanded Edition

Don Norman

Priority: Very high

Coverage:

affordance,
signifier,
feedback,
mapping,
constraints,
conceptual models,
human error,
human-centered design.

It provides a more fundamental design framework than any individual UI component.

3. Don't Make Me Think, Revisited

Steve Krug — New Riders, 3rd edition

Priority: High

A concise but strong foundation for web/mobile usability, scannability, navigation, and usability testing.

4. Web Form Design: Filling in the Blanks

Luke Wroblewski

Priority: High for form-heavy applications

Focuses on form flow, labels, actions, errors, and data-entry problems.

5. Information Architecture, 4th Edition

Louis Rosenfeld, Peter Morville, Jorge Arango — O'Reilly

Priority: High for large content/module hierarchies

Addresses organization, labeling, navigation, search, and findability above the individual interface-component layer.

6. 100 Things Every Designer Needs to Know About People

Susan M. Weinschenk

Priority: High for cognition and behavioral design

Covers the effect of attention, memory, perception, reading, decision-making, error, and social behavior on design. It supports the sections in this note dealing with cognitive budget, visibility, recognition, and recall.

7. Design for How People Think

John Whalen

Priority: High for connecting research to design decisions

Focuses not only on what users do but on how they think and process information in context. It is useful for connecting design choices to user tasks and research.

8. Designing UX: Forms

Jessica Enders

Priority: Very high for form-heavy applications

Treats forms as a sequence of understanding the question, finding an answer, judging applicability, and physically entering the result—not merely as field layout. Especially relevant to government, healthcare, and enterprise forms.

9. Designing UX: Prototyping

Ben Coleman, Dan Goodwin

Priority: High for validating application behavior before production

Covers low/high-fidelity prototypes, test goals, tool selection, and behavioral validation with real users.

10. Laws of UX

Jon Yablonski — notes from the 1st and 2nd editions

Priority: High for turning psychological principles into design hypotheses

Collects ideas such as Jakob, Fitts, Hick, Peak–End, aesthetic–usability, von Restorff, and Tesler in an accessible form. In this note they are treated as hypotheses to validate in task context, not universal laws.

11. Simple and Usable

Giles Colborne — 2nd edition

Priority: Very high as a practical engineering counterpart to the Zen perspective

Explains simplification through remove, organize, hide, and displace. It is especially useful for avoiding the misconception that simplicity means fewer visible elements.

12. Strategic Writing for UX, 2nd Edition

Torrey Podmajersky

Priority: Very high for UI text, errors, confirmations, empty states, and content design

Treats headings, labels, buttons, notifications, errors, and transition text as systematic interface patterns. The referenced edition also covers 2025-era updates and content design in LLM-based experiences.

13. Tragic Design

Jonathan Shariat, Cynthia Savard Saucier

Priority: Very high for critical systems and ethical UX

Examines cases where bad design causes real harm rather than mere dissatisfaction. It directly informs the sections on safety, error prevention, and visibility of critical information.

14. The Elements of User Experience

Jesse James Garrett — 2nd edition

Priority: High for holistic UX architecture from strategy to visual surface

Structures UX across strategy, scope, structure, skeleton, and surface planes, clarifying why visual decisions should not be detached from lower-level user needs and scope decisions.

15. Emotional Design

Donald A. Norman

Priority: Medium/high for trust, perceived quality, and emotional response

Helps evaluate initial perception, use, and longer-term meaning in addition to functional usability.

16. Effective UI

Jonathan Anderson, John McRee, Robb Wilson, and the EffectiveUI team

Priority: Medium/high for process and implementation practice in large interactive applications

Supports the view that user experience is not only a screen-design problem but also a problem of team process, engineering, and continuous evaluation.

I include these sources not merely as a reading list. Each explains a different decision layer: interaction patterns, human error, form design, information architecture, cognition, interface writing, prototyping, and error cost in critical systems. Throughout the note, source-supported claims and my engineering synthesis are kept separate as far as possible; details that are not verified in a source are not presented as if they were the author's claims.

Unit 60: Conclusion

No single design formula remains at the end of this note, and none should. UI/UX engineering is less about choosing one fashionable shortcut over another than about defining the boundaries of the task and its risk correctly.

Neither:

golden ratio

nor:

three clicks

nor:

mobile-first

nor:

Amazon does it this way

is sufficient by itself to justify a design decision.

A more reliable decision sequence, in my view, is:

User task
      ↓
Information architecture
      ↓
Established convention
      ↓
Accessible semantics
      ↓
Visual and interaction hierarchy
      ↓
Reliable request/state model
      ↓
Responsive behavior
      ↓
Performance
      ↓
Real-user measurement
      ↓
Iteration

The fundamental objective of UI/UX engineering is not to draw attention to the design itself, but to let the user perform the work correctly and predictably.

Breaking behavior that already works merely to look modern is not UX. But preserving a familiar behavior when it creates correctness, accessibility, or data-loss risk is not justified by habit either.

The strongest interface is one in which the user:

knows where they are,
sees what can be done,
understands what the system is doing,
can recover from error,
trusts that data will not disappear,
can work faster as expertise grows.

Through the Zen lens, the final equation can be shorter:

Remove what is unnecessary.
Make what is necessary visible.
Place complexity where it belongs.
Use the system instead of the user's memory.
Do not disrupt working habits without reason.
Do not push error responsibility onto the user.
Do not delay feedback.
Never trade data safety or authorization boundaries for aesthetic gain.
Do not call something “better” before measuring it.

This is broader than visual minimalism. The real objective is low cognitive noise, high task correctness, and stable behavior.

# References and Technical Verification Sources

W3C / Standards

W3C, Web Content Accessibility Guidelines (WCAG) 2.2

https://www.w3.org/TR/WCAG22/

W3C WAI, ARIA Authoring Practices Guide — Tabs Pattern

https://www.w3.org/WAI/ARIA/apg/patterns/tabs/

W3C WAI, ARIA Authoring Practices Guide — Grid Pattern

https://www.w3.org/WAI/ARIA/apg/patterns/grid/

W3C WAI, ARIA Authoring Practices Guide — Table Pattern

https://www.w3.org/WAI/ARIA/apg/patterns/table/

W3C WAI, ARIA Authoring Practices Guide — Dialog Modal Pattern

https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/

IETF, RFC 9110 — HTTP Semantics, §9.2 Safe and Idempotent Methods

https://www.rfc-editor.org/rfc/rfc9110.html

Nielsen Norman Group

Nielsen Norman Group, Web UX: Study Guide

https://www.nngroup.com/articles/web-ux-study-guide/

Nielsen Norman Group, Information Architecture: Study Guide

https://www.nngroup.com/articles/ia-study-guide/

Nielsen Norman Group, The 3-Click Rule for Navigation Is False

https://www.nngroup.com/articles/3-click-rule/

Nielsen Norman Group, Horizontal Attention Leans Left

https://www.nngroup.com/articles/horizontal-attention-leans-left/

Nielsen Norman Group, Universal Navigation: Connecting Subsites to Main Sites

https://www.nngroup.com/articles/universal-navigation/

Nielsen Norman Group, The Risks of Imitating Designs (Even from Successful Companies)

https://www.nngroup.com/articles/risks-imitating-designs/

Nielsen Norman Group, Data Tables: Four Major User Tasks

https://www.nngroup.com/articles/data-tables/

Nielsen Norman Group, Animation for Attention and Comprehension

https://www.nngroup.com/articles/animation-usability/

Nielsen Norman Group, Application Design Showcase resources

https://www.nngroup.com/reports/best-applications-1/

GOV.UK Design System

GOV.UK Design System, Question Pages

https://design-system.service.gov.uk/patterns/question-pages/

GOV.UK Design System, Check Answers

https://design-system.service.gov.uk/patterns/check-answers/

GOV.UK Design System, Complete Multiple Tasks

https://design-system.service.gov.uk/patterns/complete-multiple-tasks/

GOV.UK Design System, Back Link

https://design-system.service.gov.uk/components/back-link/

GOV.UK Design System, Step by Step Navigation

https://design-system.service.gov.uk/patterns/step-by-step-navigation/

IBM Carbon / Apple / Android

IBM Carbon Design System, Data Table — Usage

https://carbondesignsystem.com/components/data-table/usage/

IBM Carbon Design System, Pagination — Usage

https://carbondesignsystem.com/components/pagination/usage/

Apple Human Interface Guidelines, Tab Bars

https://developer.apple.com/design/human-interface-guidelines/tab-bars

Apple Human Interface Guidelines, Sidebars

https://developer.apple.com/design/human-interface-guidelines/sidebars

Apple Human Interface Guidelines, Toolbars

https://developer.apple.com/design/human-interface-guidelines/toolbars

Android Developers / Material 3, NavigationBar

https://developer.android.com/reference/kotlin/androidx/compose/material3/NavigationBar

Responsive Design / Performance / Client

web.dev, Responsive Web Design Basics

https://web.dev/articles/responsive-web-design-basics

MDN, CSS Container Queries

https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_containment/Container_queries

MDN, clamp()

https://developer.mozilla.org/en-US/docs/Web/CSS/clamp

MDN, AbortController

https://developer.mozilla.org/en-US/docs/Web/API/AbortController

web.dev, Web Vitals

https://web.dev/articles/vitals

web.dev, Interaction to Next Paint (INP)

https://web.dev/articles/inp

web.dev, Optimize Input Delay

https://web.dev/articles/optimize-input-delay

API Reliability

Stripe API Reference, Idempotent Requests

https://docs.stripe.com/api/idempotent_requests

Golden-Ratio Research

Van Schaik, P.; Ling, J. The effects of screen ratio and order on information retrieval in web pages. Displays, 24(4–5), 187–195.

DOI: 10.1016/j.displa.2004.01.005 https://research.tees.ac.uk/en/publications/the-effects-of-screen-ratio-and-order-on-information-retrieval-in/

Tractinsky, N.; David, E.; Krupnik, A. Exploring the Aesthetic Effects of the Golden Ratio in the Design of Interactive Products. AMCIS 2013.

https://aisel.aisnet.org/amcis2013/HumanComputerInteraction/GeneralPresentations/12/

E-Commerce and Large-Scale Product Examples

Amazon, Enhanced Homepage Features

https://www.aboutamazon.com/news/retail/amazon-homepage-redesign-features

Amazon, 5 Ways Amazon Is Making It Easier to Search and Shop

https://www.aboutamazon.com/news/retail/amazon-makes-it-easier-to-search-and-shop

Meta, How We're Making It Easier to Navigate Settings

https://about.fb.com/news/2021/08/facebook-settings-redesign/

Meta, Guiding You Through Your Privacy Choices

https://about.fb.com/news/2020/01/privacy-checkup/

X Help, Accessibility Features of X

https://help.x.com/en/using-x/accessibility-features

Trendyol Tech, Trendyol Homepage: How Did We Implement a Nearly Real-Time Homepage? — Part 1

https://medium.com/trendyol-tech/trendyol-homepage-how-did-we-implement-a-nearly-real-time-homepage-dc2dcb5eb0e4

D-MARKET / Hepsiburada, 2025 Form 20-F, SEC

https://www.sec.gov/Archives/edgar/data/1850235/000110465926053195/heps-20251231x20f.htm

LMS and University Information Systems

MoodleDocs 5.2, Dashboard

https://docs.moodle.org/502/en/Dashboard

Instructure Canvas, Canvas Student Guide / Canvas Student iOS Guide, updated 2025-06-27

https://community.canvaslms.com/html/assets/Canvas_Student_Guide.pdf https://community.canvaslms.com/html/assets/Canvas_Student_iOS_Guide.pdf

Istanbul University, AKSIS User Guide — Document Requests

https://cdn.istanbul.edu.tr/FileHandler2.ashx?f=aksis-kullanim-kilavuzu-omyo.pdf

Sakarya University, SABIS / Student Information System User Guides

https://iletisim.sakarya.edu.tr/sites/iletisim.sakarya.edu.tr/file/2023-2024_YKS_KAYIT_KILAVUZU_1.pdf

Books

Tidwell, J.; Brewer, C.; Valencia, A. Designing Interfaces, 3rd Edition. O'Reilly.

https://www.oreilly.com/library/view/designing-interfaces-3rd/9781492051954/

Norman, D. The Design of Everyday Things, Revised and Expanded Edition.

https://mitpress.mit.edu/9780262525671/the-design-of-everyday-things/

Krug, S. Don't Make Me Think, Revisited. New Riders, 3rd edition.

https://sensible.com/dont-make-me-think/

Wroblewski, L. Web Form Design: Filling in the Blanks.

https://www.lukew.com/resources/web_form_design.asp

Rosenfeld, L.; Morville, P.; Arango, J. Information Architecture, 4th Edition. O'Reilly.

https://www.oreilly.com/library/view/information-architecture-4th/9781491913529/

Additional Books Used in the Source Notes

Tidwell, J.; Brewer, C.; Valencia, A. Designing Interfaces: Patterns for Effective Interaction Design, 3rd Edition. O'Reilly, 2020.

Norman, D. A. The Design of Everyday Things, Revised and Expanded Edition. Basic Books, 2013.

Weinschenk, S. M. 100 Things Every Designer Needs to Know About People. New Riders, 2011.

Whalen, J. Design for How People Think: Using Brain Science to Build Better Products. O'Reilly, 2019.

Norman, D. A. The Design of Future Things. Basic Books, 2007/2009.

Enders, J. Designing UX: Forms. SitePoint, 2016.

Coleman, B.; Goodwin, D. Designing UX: Prototyping. SitePoint, 2017.

Krug, S. Don't Make Me Think, Revisited: A Common Sense Approach to Web Usability. New Riders, 2014.

Anderson, J.; McRee, J.; Wilson, R.; EffectiveUI Team. Effective UI. O'Reilly, 2010.

Norman, D. A. Emotional Design: Why We Love (or Hate) Everyday Things. Basic Books, 2004.

Yablonski, J. Laws of UX: Using Psychology to Design Better Products & Services. O'Reilly, 2020; the source collection also includes notes from the second edition.

Weinschenk, S. M. Neuro Web Design: What Makes Them Click? New Riders.

MacDonald, D. Practical UI Patterns for Design Systems: Fast-Track Interaction Design for a Seamless User Experience. Apress.

Colborne, G. Simple and Usable: Web, Mobile, and Interaction Design, 2nd Edition. New Riders, 2018.

Podmajersky, T. Strategic Writing for UX: Drive Engagement, Conversion, and Retention with Every Word, 2nd Edition. O'Reilly, 2025.

Shariat, J.; Savard Saucier, C. Tragic Design: The Impact of Bad Product Design and How to Fix It. O'Reilly, 2017.

Garrett, J. J. The Elements of User Experience: User-Centered Design for the Web and Beyond, 2nd Edition. New Riders, 2011.

Staiano, F. Designing and Prototyping Interfaces with Figma. Packt, 2022.

Last updated: August 2026 Last technical verification: 26 August 2026

Normative accessibility requirements in this note were checked against W3C WCAG 2.2 and WAI-ARIA APG; HTTP idempotency semantics against RFC 9110; and performance metrics against current web.dev documentation. Product examples were evaluated through official documentation, engineering publications, or SEC filings from the relevant organizations. The golden-ratio section is intentionally limited to experimental academic evidence rather than popular design narratives.

Unit 1: UI, UX, and Usability

UI and UX are not the same concept

The engineering meaning of usability

The user's mental model

Unit 2: Nielsen's Usability Heuristics and the Modern Web

1. Visibility of system status

2. Match between the system and the real world

3. User control and freedom

4. Consistency and standards

5. Error prevention

6. Recognition rather than recall

7. Flexibility and efficiency of use

8. Aesthetic and minimalist design

9. Help users recognize and recover from errors

10. Help and documentation

Unit 3: Established Web Conventions

Why conventions matter

A strong layout convention for LTR desktop web

A content site and an application do not need the same navigation

Global, local, and utility navigation

When are breadcrumbs useful?

The “three-click rule” is not a rule

Unit 4: Visual Hierarchy, Layout, and Attention

Spacing is not decoration; it is information architecture

A consistent spacing scale

Alignment

Color must not carry meaning alone

Icons

Unit 5: The Golden Ratio — Design Principle or Design Myth?

Where can it be useful?

Where should it not drive the decision?

What does the research say?

Unit 6: Information Architecture and Navigation

Mega menus

What should a tab represent?

Too many tabs

Unit 7: Search, Discovery, Filtering, and Sorting

Search as the user types

Filters

Sorting

Unit 8: Data Tables and Data-Grid Design

A table and a grid are not the same thing

A common work-table surface

Mobile tables

Pagination or infinite scroll?

Virtualization

Unit 9: Form Design

Eliminate → Automate → Simplify

Labels

Required and optional fields

Input semantics

Validation

Error summary

Form state

Unit 10: Wizards, Steppers, Task Lists, and Progressive Disclosure

When is a wizard the wrong choice?

Properties of a good wizard

Review answers

Task lists

Progressive disclosure

Facebook Privacy Checkup

Unit 11: Dialogs, Side Panels, Popovers, and Modal Dialogs

A modal is an expensive interaction

Accessibility in modal dialogs

Confirmation dialogs

Side panels

Popovers

Unit 12: System Feedback, Loading States, and Perceived Performance

Actual speed and perceived speed

Choose the loading indicator according to the work

Optimistic UI

Toasts

Empty states

Unit 13: Preventing Duplicate Requests and Race Conditions

Problem 1: Double-click / repeated submission

Problem 2: Search request storms

Debounce

Problem 3: An older request overwrites a newer result

Problem 4: Retrying mutations

Idempotency keys

`clamp()`