# UI/UX Engineering in Web Applications: Usability, Responsive Design, 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. - Author: Muhammet Ali Köker - Language: en - Canonical: https://alikoker.com.tr/en/ui-ux-engineering-in-web-applications - Translation: https://alikoker.com.tr/web-uygulamalarinda-ui-ux-muhendisligi - Published: 2023-12-01T00:00:00+03:00 - Modified: 2026-08-26T11:10:00+03:00 - Verified: 2026-08-26T11:10:00+03:00 - Type: article > **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: 1. **Learnability:** How easily can a new user learn the basic task? 2. **Efficiency:** How little cognitive and physical effort does an experienced user need to complete the same task? 3. **Memorability:** After time away from the system, must the user learn it again? 4. **Error rate and severity:** How often do errors occur, and how serious are their consequences? 5. **Recoverability:** Can an error be undone or corrected easily? 6. **Satisfaction:** Does the user experience the system as a tool under control? 7. **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 ```text ┌─────────────────────────────────────────────────────────────────────────┐ │ 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. ### A content site and an application do not need the same navigation Content-heavy site: ```text Logo | Home | Articles | Resources | About | Search | Profile ``` Dense work application: ```text ┌───────────────────────────────────────────────┐ │ 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, local, and utility navigation - **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. ```text 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: 1. What is this screen? 2. What is the primary task? 3. Which action is primary? 4. Which information is secondary? 5. 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: ```text 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 ```text [!] 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: ```text φ = (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. ```text Golden ratio → sketch / aesthetic hypothesis User task + content + accessibility + measurement → design decision ``` --- ## Unit 6: Information Architecture and Navigation Menus should be grouped around user goals rather than the institution's internal organization. Ambiguous: ```text Operations Other Services More ``` More descriptive: ```text 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. ```text 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: 1. a visible search affordance, 2. search history, 3. autocomplete, 4. spelling correction, 5. synonyms and related queries, 6. filters, 7. sorting, 8. a summary of active filters, 9. result counts, 10. 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: ```text 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: 1. finding records that match criteria, 2. comparing records, 3. viewing, editing, or adding a single record, 4. acting on records. ### A table and a grid are not the same thing For static or read-only data, semantic HTML `` 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 ```text 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 1. remove fields that do not contribute to the task, 2. do not ask again for data the system already knows, 3. derive or prefill what can be obtained reliably, 4. 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: ```text 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 ```html ``` 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 ```text 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. ```text 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. ```text 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: ```text 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 ```text 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. ## Unit 11: Dialogs, Side Panels, Popovers, and Modal Dialogs ### A modal is an expensive interaction 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. ### Accessibility in modal dialogs 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 `
` 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: ```text Click → nothing → screen changes 1.5 s later ``` and: ```text 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: ```text No records ``` distinguish the reason: ```text No record has been created yet. [New record] ``` or: ```text 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: ```text POST /save POST /save ``` Temporarily locking the action on the client is useful: ```javascript 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: ```text a → request 1 al → request 2 ali → request 3 alik → request 4 ``` and waste network, CPU, and database capacity. #### Debounce ```javascript 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 ```text 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: 1. cancel the previous request with `AbortController`, 2. also guard the result with a generation/sequence number. ```javascript 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: ```text POST sent connection lost did the operation happen on the server? ``` ### Idempotency keys A common approach, especially in payment and ordering APIs, is: ```text 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 ```text 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: ```html ``` ### A breakpoint is not a device name Weak thinking: ```text 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. ```css .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: ```css 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: ```css @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: ```text [Title] [Search................] [Filter] [Export] [New] ``` Mobile: ```text [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: ```text | 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%`. --- ## Unit 15: Mobile Navigation and Screen Space ### Bottom navigation 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: ```text [Home] [Search] [Tasks] [Notifications] [Profile] ``` Not appropriate: ```text [Save] [Delete] [Export] [Refresh] ``` The second group contains actions, not destinations. ### Less visible does not mean less functional A useful priority is: 1. keep the primary task visible, 2. place secondary tasks in overflow, 3. place infrequent advanced settings in an appropriate panel or sheet. ### Sidebar to compact navigation A wide layout may use a sidebar; a narrow layout can move to a compact top or bottom navigation model. ```text 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 ```css :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 ```css @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: ```html ``` Better: ```html ``` ### Live announcements Dynamic status: ```html
Saved
``` Critical error: ```html
The record could not be saved.
``` 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: ```text 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 ```text if (!admin) hideDeleteButton(); ``` is only a presentation decision. The backend must still: ```text authenticate ↓ authorize action ↓ authorize resource scope ↓ validate invariant ↓ mutate ↓ audit ``` ### Sending unauthorized data and hiding it on the client is wrong Poor: ```text Server → all records Client → hide unauthorized records with CSS ``` Correct: ```text Server → authorized records only ``` ### Destructive actions A deletion control should make clear: - the object name, - the scope, - whether recovery is possible. ```text “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: ```text 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: ```text [ 125 ] [ 98 ] [ 72 ] [ 41 ] ``` The numbers have neither context nor action. Better: ```text 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: ```text 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 ```text Name [____________________] Surname [____________________] Email [____________________] [Cancel] [Save] ``` ### When should two columns be used? Prefer two columns for short, closely related fields: ```text Start [____] End [____] City [____] District [____] ``` Splitting a long form into two columns merely to fill empty space can make visual scanning harder. ### Mobile ```text 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 ### 1. Hiding everything behind a hamburger menu 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. ### 6. Making everything a modal 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: ```text IDLE ↓ LOADING ├── SUCCESS + DATA ├── SUCCESS + EMPTY └── ERROR ``` For a mutation: ```text 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: ```text 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 ```css :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: ```text default hover focus active disabled loading ``` An input may be: ```text 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: ```text 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: ```text 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: ```text 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: ```text [New Record — with visible guidance] ``` while an expert reaches the same function with: ```text 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: ```text 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: ```text 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: ```text 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? ### Screen reader - 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 ```text ┌──────────────────────────────────────────────────────────────────────┐ │ Logo / Product Global Search ? 🔔 User ▾ │ ├───────────────┬──────────────────────────────────────────────────────┤ │ Primary nav │ Breadcrumb / Location │ │ │ Page Title Primary Action │ │ Dashboard │ │ │ Records │ Search / Filter / Toolbar │ │ Reports │ │ │ Administration│ Main workspace │ │ │ │ │ │ │ └───────────────┴──────────────────────────────────────────────────────┘ ``` ### Mobile ```text ┌───────────────────────────┐ │ ← 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: ```text 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: 1. **Build information architecture around user tasks.** 2. **Shorten high-frequency paths.** 3. **Let users continue from where they left off.** 4. **Treat search as a real discovery system.** 5. **Support the same task on desktop and mobile with layouts appropriate to each environment.** 6. **Make system state visible.** 7. **Do not treat accessibility as a layer added after component design.** 8. **For irreversible operations, place security and data integrity ahead of cosmetic convenience.** 9. **Preserve expert users' muscle memory.** 10. **Do not adopt a new pattern merely because it is fashionable; validate it with task testing or measurement.** 11. **Do not confuse hiding functionality with simplifying it.** 12. **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: 1. **Remove:** eliminate a function or information that contributes nothing to the real task. 2. **Organize:** group necessary complexity into understandable structures. 3. **Hide:** move infrequent but necessary capabilities to a second layer with the right cues. 4. **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: ```text Saving… Saved ``` is often enough, while: ```text 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. ```text 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: ```text 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. More useful questions include: - How do you perform this task today? - Where do you most often get stuck? - Which information do you copy from elsewhere? - Which step are you afraid of skipping? - Which action do you repeat continuously? - On which screen do you most often need to go back? - Which error causes the most rework? ### 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: ```text 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 1. System state is visible. 2. A path back exists. 3. Destructive actions are separated from ordinary navigation. 4. Temporary selection and persistent mutation are clearly distinct. 5. Form data is not discarded unnecessarily. 6. When undo is impossible, the consequence is stated in advance. ### Preview For a high-impact operation, preview can precede mutation: ```text 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: ```text Archived. [Undo] ``` is often more fluid than: ```text 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: ```text 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: ```text 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: ```text A → B → C ``` and a redesign changes it to: ```text 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: ```text 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: ```text What do you want to do? [Open File] ``` and only later, when needed: ```text [Advanced options] ``` ### Three conditions for progressive disclosure Before hiding a feature, verify that: 1. it is used infrequently, 2. it does not block the primary task, 3. 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: ```text 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: ```text 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: ```text 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: ```text 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: ```text remember the code from the previous page → enter it on this page ``` keep the context visible: ```text Selected record: 10428 — ... ``` ### Grouping Long sequences of information should be divided into meaningful groups. Poor: ```text 30 fields in one undifferentiated form ``` Better: ```text 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: ```text 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: ```text 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: ```text 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? ```text [Export 24 records] ``` provides more useful feedforward than: ```text [OK] ``` ### Feedback After the action, answer: > What happened? ```text 24 records exported. ``` ### Better action labels Instead of a generic: ```text [Submit] ``` use a label that reflects the result when possible: ```text [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: ```text 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: ```text 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: ```text (555) 123-45-67 5551234567 555 123 45 67 ``` But: ```text 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: ```text Advanced ``` But discoverability must remain through: - signifiers, - hints, - search, - correct labels. ### 4. Displace Complexity can move to another layer. For example: ```text Do not ask the user to select a date format every time → apply locale/system preference. ``` or: ```text 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: ```text 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: ```text STAT_CD ``` Better: ```text 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: ```text 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: ```text click row = select only ``` or: ```text 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: ```text 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: ```text Operations ``` Better: ```text User Permissions ``` ### Buttons Button text should describe the result. Instead of: ```text [OK] ``` prefer, where appropriate: ```text [Save Changes] ``` ### Empty states An empty state should explain not only that data is absent, but also what the user can do. ```text No records yet. [Create new record] ``` or: ```text No records match these filters. [Clear filters] ``` ### Errors A good error message answers, where possible: 1. What happened? 2. What can the user do? 3. 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: ```text fake data + one user + zero latency ``` is not equivalent to production with: ```text 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 ```text Token ↓ Primitive ↓ Component ↓ Pattern ``` For example: ```text 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: ```text 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: ```text 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: ```text golden ratio ``` nor: ```text three clicks ``` nor: ```text mobile-first ``` nor: ```text Amazon does it this way ``` is sufficient by itself to justify a design decision. A more reliable decision sequence, in my view, is: ```text 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: ```text 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 1. W3C, **Web Content Accessibility Guidelines (WCAG) 2.2** https://www.w3.org/TR/WCAG22/ 2. W3C WAI, **ARIA Authoring Practices Guide — Tabs Pattern** https://www.w3.org/WAI/ARIA/apg/patterns/tabs/ 3. W3C WAI, **ARIA Authoring Practices Guide — Grid Pattern** https://www.w3.org/WAI/ARIA/apg/patterns/grid/ 4. W3C WAI, **ARIA Authoring Practices Guide — Table Pattern** https://www.w3.org/WAI/ARIA/apg/patterns/table/ 5. W3C WAI, **ARIA Authoring Practices Guide — Dialog Modal Pattern** https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/ 6. IETF, **RFC 9110 — HTTP Semantics**, §9.2 Safe and Idempotent Methods https://www.rfc-editor.org/rfc/rfc9110.html ## Nielsen Norman Group 7. Nielsen Norman Group, **Web UX: Study Guide** https://www.nngroup.com/articles/web-ux-study-guide/ 8. Nielsen Norman Group, **Information Architecture: Study Guide** https://www.nngroup.com/articles/ia-study-guide/ 9. Nielsen Norman Group, **The 3-Click Rule for Navigation Is False** https://www.nngroup.com/articles/3-click-rule/ 10. Nielsen Norman Group, **Horizontal Attention Leans Left** https://www.nngroup.com/articles/horizontal-attention-leans-left/ 11. Nielsen Norman Group, **Universal Navigation: Connecting Subsites to Main Sites** https://www.nngroup.com/articles/universal-navigation/ 12. Nielsen Norman Group, **The Risks of Imitating Designs (Even from Successful Companies)** https://www.nngroup.com/articles/risks-imitating-designs/ 13. Nielsen Norman Group, **Data Tables: Four Major User Tasks** https://www.nngroup.com/articles/data-tables/ 14. Nielsen Norman Group, **Animation for Attention and Comprehension** https://www.nngroup.com/articles/animation-usability/ 15. Nielsen Norman Group, **Application Design Showcase** resources https://www.nngroup.com/reports/best-applications-1/ ## GOV.UK Design System 16. GOV.UK Design System, **Question Pages** https://design-system.service.gov.uk/patterns/question-pages/ 17. GOV.UK Design System, **Check Answers** https://design-system.service.gov.uk/patterns/check-answers/ 18. GOV.UK Design System, **Complete Multiple Tasks** https://design-system.service.gov.uk/patterns/complete-multiple-tasks/ 19. GOV.UK Design System, **Back Link** https://design-system.service.gov.uk/components/back-link/ 20. GOV.UK Design System, **Step by Step Navigation** https://design-system.service.gov.uk/patterns/step-by-step-navigation/ ## IBM Carbon / Apple / Android 21. IBM Carbon Design System, **Data Table — Usage** https://carbondesignsystem.com/components/data-table/usage/ 22. IBM Carbon Design System, **Pagination — Usage** https://carbondesignsystem.com/components/pagination/usage/ 23. Apple Human Interface Guidelines, **Tab Bars** https://developer.apple.com/design/human-interface-guidelines/tab-bars 24. Apple Human Interface Guidelines, **Sidebars** https://developer.apple.com/design/human-interface-guidelines/sidebars 25. Apple Human Interface Guidelines, **Toolbars** https://developer.apple.com/design/human-interface-guidelines/toolbars 26. Android Developers / Material 3, **NavigationBar** https://developer.android.com/reference/kotlin/androidx/compose/material3/NavigationBar ## Responsive Design / Performance / Client 27. web.dev, **Responsive Web Design Basics** https://web.dev/articles/responsive-web-design-basics 28. MDN, **CSS Container Queries** https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_containment/Container_queries 29. MDN, **clamp()** https://developer.mozilla.org/en-US/docs/Web/CSS/clamp 30. MDN, **AbortController** https://developer.mozilla.org/en-US/docs/Web/API/AbortController 31. web.dev, **Web Vitals** https://web.dev/articles/vitals 32. web.dev, **Interaction to Next Paint (INP)** https://web.dev/articles/inp 33. web.dev, **Optimize Input Delay** https://web.dev/articles/optimize-input-delay ## API Reliability 34. Stripe API Reference, **Idempotent Requests** https://docs.stripe.com/api/idempotent_requests ## Golden-Ratio Research 35. 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/ 36. 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 37. Amazon, **Enhanced Homepage Features** https://www.aboutamazon.com/news/retail/amazon-homepage-redesign-features 38. 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 39. Meta, **How We're Making It Easier to Navigate Settings** https://about.fb.com/news/2021/08/facebook-settings-redesign/ 40. Meta, **Guiding You Through Your Privacy Choices** https://about.fb.com/news/2020/01/privacy-checkup/ 41. X Help, **Accessibility Features of X** https://help.x.com/en/using-x/accessibility-features 42. 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 43. 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 44. MoodleDocs 5.2, **Dashboard** https://docs.moodle.org/502/en/Dashboard 45. 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 46. Istanbul University, **AKSIS User Guide — Document Requests** https://cdn.istanbul.edu.tr/FileHandler2.ashx?f=aksis-kullanim-kilavuzu-omyo.pdf 47. 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 48. Tidwell, J.; Brewer, C.; Valencia, A. **Designing Interfaces, 3rd Edition.** O'Reilly. https://www.oreilly.com/library/view/designing-interfaces-3rd/9781492051954/ 49. Norman, D. **The Design of Everyday Things, Revised and Expanded Edition.** https://mitpress.mit.edu/9780262525671/the-design-of-everyday-things/ 50. Krug, S. **Don't Make Me Think, Revisited.** New Riders, 3rd edition. https://sensible.com/dont-make-me-think/ 51. Wroblewski, L. **Web Form Design: Filling in the Blanks.** https://www.lukew.com/resources/web_form_design.asp 52. 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 53. Tidwell, J.; Brewer, C.; Valencia, A. **Designing Interfaces: Patterns for Effective Interaction Design, 3rd Edition.** O'Reilly, 2020. 54. Norman, D. A. **The Design of Everyday Things, Revised and Expanded Edition.** Basic Books, 2013. 55. Weinschenk, S. M. **100 Things Every Designer Needs to Know About People.** New Riders, 2011. 56. Whalen, J. **Design for How People Think: Using Brain Science to Build Better Products.** O'Reilly, 2019. 57. Norman, D. A. **The Design of Future Things.** Basic Books, 2007/2009. 58. Enders, J. **Designing UX: Forms.** SitePoint, 2016. 59. Coleman, B.; Goodwin, D. **Designing UX: Prototyping.** SitePoint, 2017. 60. Krug, S. **Don't Make Me Think, Revisited: A Common Sense Approach to Web Usability.** New Riders, 2014. 61. Anderson, J.; McRee, J.; Wilson, R.; EffectiveUI Team. **Effective UI.** O'Reilly, 2010. 62. Norman, D. A. **Emotional Design: Why We Love (or Hate) Everyday Things.** Basic Books, 2004. 63. 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. 64. Weinschenk, S. M. **Neuro Web Design: What Makes Them Click?** New Riders. 65. MacDonald, D. **Practical UI Patterns for Design Systems: Fast-Track Interaction Design for a Seamless User Experience.** Apress. 66. Colborne, G. **Simple and Usable: Web, Mobile, and Interaction Design, 2nd Edition.** New Riders, 2018. 67. Podmajersky, T. **Strategic Writing for UX: Drive Engagement, Conversion, and Retention with Every Word, 2nd Edition.** O'Reilly, 2025. 68. Shariat, J.; Savard Saucier, C. **Tragic Design: The Impact of Bad Product Design and How to Fix It.** O'Reilly, 2017. 69. Garrett, J. J. **The Elements of User Experience: User-Centered Design for the Web and Beyond, 2nd Edition.** New Riders, 2011. 70. 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. ## Cite This Work Köker, M. A. (2023). UI/UX Engineering in Web Applications: Usability, Responsive Design, and Reliable Client Behavior. alikoker.com.tr. https://alikoker.com.tr/en/ui-ux-engineering-in-web-applications - BibTeX: https://alikoker.com.tr/en/ui-ux-engineering-in-web-applications.bib - RIS: https://alikoker.com.tr/en/ui-ux-engineering-in-web-applications.ris - CSL-JSON: https://alikoker.com.tr/en/ui-ux-engineering-in-web-applications.csl.json