Why UX laws matter more in business software than consumer apps

Enterprise and business applications are often complex by nature — a user is rarely just browsing, they're trying to close a ticket, submit a report, or process an order under time pressure. UX laws are a curated set of findings from cognitive psychology, popularized for product teams by Jon Yablonski's Laws of UX. They describe consistent patterns in how people perceive, decide, and act — and applying them helps business software feel simple even when the underlying task isn't.

Reduce cognitive load

Business users often juggle multiple screens and tasks at once. Applying Miller's Law (chunking information into small groups) prevents overwhelm and reduces data-entry errors in forms and dashboards.

Guide user behavior

Laws like the Goal-Gradient Effect and the Peak-End Rule shape workflows that motivate users to finish multi-step tasks and leave them with a positive read on the experience, even a long one.

The core UX laws behind intuitive business software

Doherty Threshold

Law: Productivity rises when a system responds to user input within about 400ms — under that threshold, neither side is waiting on the other.

Application: Aim for sub-400ms interactions where possible. For anything slower, use progress indicators or skeleton screens so perceived speed stays high even when actual latency can't drop further.

Seen in: Tools like Trello and Asana move a dragged card or checked-off task on screen immediately, then sync to the server in the background — an "optimistic UI" update that keeps the interaction feeling instant even on a slow connection.

Hick's Law

Law: Decision time increases with the number and complexity of choices on screen.

Application: Simplify menus and forms; use progressive disclosure to surface advanced options only when needed. In dashboards, sensible defaults plus a small set of primary actions beat an exhaustive toolbar.

Seen in: Slack, Linear, Notion, and GitHub all ship a Cmd/Ctrl+K command palette — instead of scanning a deep menu tree, the user types a few letters and the choice set narrows instantly.

Fitts's Law

Law: The time to reach a target is a function of its size and distance from the user's starting position.

Application: Make primary actions (Save, Submit, Approve) large and positioned where the hand or cursor naturally rests. Reserve screen edges for critical, frequently used navigation.

Seen in: Gmail keeps its "Send" button large and fixed at the bottom-left of every compose window, in the exact same spot regardless of message length — no hunting for it on a long email.

Jakob's Law

Law: Users' expectations are shaped by the other products they already use, and they carry those expectations into yours.

Application: Lean on familiar patterns for navigation, icons, and terminology rather than inventing new conventions. Familiarity shortens the learning curve and cuts avoidable errors.

Seen in: Notion, Asana, and Slack all converge on the same left-sidebar-plus-main-canvas layout — a team that's used one can open another for the first time and already know where to look.

Miller's Law

Law: Working memory comfortably holds around 7 (±2) items at once.

Application: Group related fields under clear headings, use tabs to split long settings screens, and keep primary navigation to a small, memorable set of top-level items.

Seen in: Stripe's checkout groups card number, expiry, and CVC into a single visual field-set instead of three separate inputs — one chunk to scan, not three.

Goal-Gradient Effect

Law: Motivation to finish a task increases the closer someone gets to completing it.

Application: Show progress in multi-step flows — onboarding, checkout, multi-page forms — with progress bars or "Step X of Y" labels to keep momentum toward completion.

Seen in: HubSpot and Salesforce onboarding checklists show a percentage-complete ring that fills in as setup tasks are ticked off, nudging admins to finish the last few steps.

A note on scope: these are descriptive patterns from cognitive psychology and interaction research, not rigid rules. They compete with each other at times (Fitts's Law can push toward bigger targets while Hick's Law pushes toward fewer of them) — use them as a shared vocabulary for design trade-offs, not a checklist to satisfy blindly.

Four of these laws, visualized

A quick visual reference for the laws that are easiest to misjudge from text description alone.

400ms threshold 0–400ms 400–1000ms 1000ms+ Feels instant Noticeable lag Attention drifts
The Doherty Threshold's response-time zones — stay left of the dashed line where possible.
far + small slower to reach near + large faster to reach
Fitts's Law: a closer, larger target (like a well-placed Save button) beats a small one far from the cursor.
Ungrouped — 9 items to scan individually Chunked — 3 groups of 3, one glance per group
Miller's Law: the same 9 fields feel lighter once they're chunked into three visual groups.
4 Step 1 Step 5 — done Motivation rises as the finish line gets closer →
The Goal-Gradient Effect: users push harder to finish "Step 4 of 5" than they did at step 1.

More patterns worth knowing

Beyond the six above, a handful of related principles show up constantly in business-app design reviews:

Principle What it says Business application example Seen in the wild
Serial Position Effect People best remember the first and last items in a list. Put the most important actions at the start or end of a toolbar or menu, not buried in the middle. Google Docs and Microsoft Word keep Undo/Redo and Save at the far-left of the toolbar — the two actions used most, in the position remembered best.
Von Restorff Effect An item that visually stands out from similar items is more likely to be noticed and remembered. Give the primary call-to-action (e.g. "Submit") a distinct, consistent color that nothing else on the screen uses. GitHub's "Merge pull request" button is a solid green against an otherwise gray/white review screen — it's the one action on the page you can't miss.
Law of Proximity Objects placed close together are perceived as related. Group related form fields under one heading with shared spacing, separated clearly from unrelated fields. Google Analytics and most BI dashboards cluster related KPI cards (e.g. all traffic metrics) into one visual block, with clear gutters before the next metric group.
Peak-End Rule People judge an experience mainly by its most intense moment and how it ends. Close a completed workflow with a clear success state and an obvious next step, not a silent redirect. Mailchimp's send flow ends with a short celebratory animation — a small, deliberate positive note at the exact moment the task (and any pre-send anxiety) is over.
Occam's Razor Among equally effective options, the simplest one should be preferred. If a UI element or extra step can be removed without hurting the user's goal, remove it. Basecamp has built its product identity around shipping fewer features than competitors, arguing explicitly that most teams are better served by less surface area, not more.

How to apply these laws in your own projects

1

Identify user goals and mental models. Understand what your users are actually trying to accomplish and what behavior they expect from the system. Interviews, journey maps, and early prototype testing surface this faster than guessing.

2

Prototype and test against the laws. Check a menu against Hick's Law, check a key action button's size and placement against Fitts's Law, before either ships to users.

3

Measure and iterate. Track task completion time, error rate, and support-ticket volume tied to the flow you changed. Use these numbers, not intuition alone, to decide whether a simplification actually helped.

A practical design checklist

  • Interactions respond in well under 400ms, or show a progress indicator when they can't.
  • Menus and primary navigation stay within roughly 5–7 items.
  • Primary action buttons are large, high-contrast, and placed within easy reach.
  • Icons and terminology follow familiar, widely used conventions rather than custom ones.
  • Multi-step workflows show visible progress toward completion.
  • Related fields and controls are grouped with clear visual separation from unrelated ones.
  • Completed tasks end with clear, positive feedback and an obvious next step.
  • Anything that doesn't serve the user's goal has been questioned for removal.

Illustrative example: simplifying an overloaded dashboard

Before

  • Dozens of metrics competing for attention on one screen
  • No visual hierarchy between critical and nice-to-have data
  • Several buttons of equal visual weight, no clear primary action
  • Users hesitate and ask support for help finding what they need

After applying these laws

  • A handful of key metrics highlighted, the rest moved behind a "View all" link
  • Related data grouped into clearly separated cards (Law of Proximity)
  • One visually distinct primary action, e.g. "Generate Report" (Von Restorff Effect)
  • Fewer, faster decisions — and fewer "where do I click" support questions

Key takeaways

  • UX laws are descriptive psychology, not prescriptive rules — use them to frame trade-offs, not to check boxes.
  • Doherty Threshold, Hick's Law, and Fitts's Law address speed, choice, and reach — three of the most common friction points in business software.
  • Jakob's Law and Miller's Law reward familiar, chunked interfaces over novel or dense ones.
  • The Goal-Gradient Effect and Peak-End Rule shape how motivated and satisfied users feel across a multi-step process.
Need a second opinion on a specific screen or workflow? A short, focused UX review — checked against these laws — is usually enough to surface the two or three changes that matter most.