UX Principles

Overview

A lightweight decision-support layer. This page names a small set of well-known UX laws so that a product or component decision — which component, which pattern, how many options, how fast a response needs to feel — can be made against shared evidence and written down with a reason.

It is a companion to the Design Approach, not a peer of it. Those five principles are the system's authority: every token, foundation, and component answers to them. The laws below are evidence you weigh, not rules you obey. When a law and a principle disagree, the principle wins. When a law and a component's documented contract disagree, the contract wins.

What This Page Is Not

Not automatic authority. A law is a reason to prefer one option; it is never the last word. Content, data shape, accessibility requirements, and the existing contract can all outweigh it.
Not a redefinition of anything. Applying a law here never changes semantics, token naming, component naming, variants, states, or shadcn-style conventions. Those are fixed elsewhere and stay fixed.
Not a site-wide retrofit. Do not walk this framework through every component page. Reach for it on a specific decision, record the rationale where that decision lives, and move on.
Not a substitute for testing. A law predicts how people will behave. A usability test tells you whether they actually did.

How to Use It

Name the decision. State it as a choice between concrete options — "inline radios or a Select", "spinner or no spinner", "one screen or a wizard".
Find the relevant law(s) below. Read Use when, Avoid when, and Consider instead. More than one law often applies; they can also pull in opposite directions.
Weigh it against the constraints. The real content, the accessibility bar, the component contract, the effort. A law can lose this step.
Record the why next to the what. Per Every choice carries its rationale, write the decision and cite the law as support for it — not as the reason by itself.

A law cited without a decision is decoration. If you cannot state the choice it informed, it does not belong in the doc.

The Principles

Hick's Law

The time to make a decision grows with the number and complexity of the choices.

Use when: deciding how many options, actions, or paths to show at once — menus, toolbars, navigation, settings, empty-state calls to action.
Avoid when: the choices are not comparable (a destructive action next to a routine one is a hierarchy problem, not a count problem), or when hiding options would bury something people genuinely need.
Consider instead: promote the few primary choices, defer the rest to an overflow menu or a secondary view; group and order so the common choice is the obvious one.
Why: every visible option is scanned and dismissed before the user acts. Fewer, well-ordered options make the fast choice the default one.
Supporting principle: Restraint.

Fitts's Law

The time to acquire a target depends on its size and its distance from the pointer or focus.

Use when: sizing and placing interactive targets — primary buttons, icon-only controls, tap targets on touch, controls that sit at a screen edge.
Avoid when: it would push a target past its documented size or spacing tokens, or crowd unrelated controls together just to shorten travel.
Consider instead: use the larger size step for the primary action, keep frequent controls close to where attention already is, and give small targets enough padding to meet the touch minimum without a token change.
Why: small or far targets cost time and cause mis-taps. The primary action should be the easiest thing on screen to hit.
Supporting principle: Accessible by default.

Jakob's Law

People spend most of their time on other products, and expect yours to work the same way.

Use when: choosing a pattern for something users have done a thousand times elsewhere — a select, a date field, pagination, a search box, a settings layout.
Avoid when: the familiar pattern is genuinely worse for this case, or when "familiar" is really just "what we shipped last time" rather than a broad convention.
Consider instead: start from the conventional pattern (and the shadcn-style structure this system already follows), then diverge only where you can name the reason.
Why: meeting expectations spends the user's attention on their task instead of on learning your interface.
Supporting principle: Consistency through templates.

Cognitive Load

Working memory is small. Every element competing for attention spends some of it.

Use when: a screen feels busy, a form is long, or a flow asks the user to hold several things in their head at once.
Avoid when: "reduce load" is being used to justify hiding information the user needs to make the decision in front of them.
Consider instead: split the task into steps, show only what is relevant to the current step, use spacing and grouping to build hierarchy before adding boxes or lines, and prefer plain defaults over configuration.
Why: load spent on the interface is load not spent on the task. Under enough of it, people make errors or give up.
Supporting principle: Restraint.

Choice Overload

Too many options at once makes people slower to choose, less satisfied, and more likely not to choose at all.

Use when: presenting a set the user must pick from — plans, templates, filters, a long list of settings.
Avoid when: the full set genuinely needs to be visible (a data table, a complete list of countries), where the fix is search and structure, not fewer items.
Consider instead: offer a sensible default, show a curated short list with a path to "see all", or add filtering and categories so the user compares a few items at a time.
Why: a smaller, well-framed set gets a confident decision; an undifferentiated wall of options gets abandonment.
Supporting principle: Restraint.

Gestalt Principles

People perceive grouping from visual relationships — proximity, similarity, alignment, enclosure, common region.

Use when: laying out related controls, form fields, card content, list items, or any group that should read as belonging together.
Avoid when: reaching for a border or a box to signal grouping that spacing and alignment could carry on their own.
Consider instead: group with proximity and alignment first; add a Separator or a surface only when spacing alone is not enough.
Why: structure the user can see without reading is structure that costs nothing to parse.
Supporting principle: the Proximity rule in Spacing.

Peak-End Rule

People judge an experience mostly by its most intense moment and its ending, not by the average of every moment.

Use when: designing a multi-step flow, an onboarding sequence, an error path, or any completion or confirmation moment.
Avoid when: it tempts you to add celebration or animation that slows the task down; a fast, clean finish is usually the better "end".
Consider instead: make the ending unambiguous and reassuring — a clear success state, a summary of what happened, an obvious next step — and smooth the hardest step rather than polishing the easy ones.
Why: the moments people remember shape whether they come back, more than the minutes they have forgotten.
Supporting principle: none direct; pairs with the flow-level thinking behind Every choice carries its rationale.

Tesler's Law

Every system has an irreducible amount of complexity. The only question is who absorbs it — the system or the user.

Use when: deciding whether to expose a setting, ask a question, or add a step, versus handling it with a smart default.
Avoid when: "the system will handle it" hides a decision the user actually needs to own, or pushes the complexity onto whoever maintains the component instead of removing it.
Consider instead: absorb what can be inferred (sensible defaults, format detection, auto-save), and for what is left, make the necessary step as small and clear as possible.
Why: complexity that the system does not take on does not vanish — the user pays it, every time.
Supporting principle: Restraint.

Doherty Threshold

Interaction stays engaging when the system responds in under ~400 ms. Past that, attention and productivity drop.

Use when: deciding how to handle latency — whether to show a loading indicator, how optimistic to be, when to paginate or defer work.
Avoid when: it pushes you toward a spinner for something that is already fast; a loader that flashes for 150 ms reads as slower, not faster.
Consider instead: for sub-400 ms work show nothing; for longer work show immediate acknowledgement (optimistic UI, a disabled control, inline Progress or Skeleton); keep individual responses under the threshold by doing less per step.
Why: perceived speed is part of whether an interface feels usable at all, the same way contrast and focus are — a baseline, not a nicety.
Supporting principle: Accessible by default.

Examples

Short walk-throughs of the framework in use. Each states a decision, the laws in play, and the call — and none of them redefine a Monogem contract.

Decision: show nine equally-weighted icon buttons in a row, or restructure. Laws: Hick's Law (nine comparable choices slow every use), Cognitive Load (a flat row has no hierarchy to lean on), Gestalt (related actions should read as a set). Call: keep the two or three primary actions visible, group them with spacing, and move the rest into an overflow menu. This is a composition choice — Button variants, sizes, and states are unchanged; the overflow trigger is an existing icon-only Button.

Inline Radios or a Select

Decision: how to present a single-choice field. Laws: Hick's Law and Choice Overload (scan cost rises with the option count), Jakob's Law (users expect long lists to collapse). Call: up to about five options, use Radio Group inline — every option visible, one interaction to choose. More than that, use a Select so the list is scannable and matches the pattern users know from elsewhere. Neither component's contract changes; this is a selection between two documented patterns.

Decision: where a field's supporting instruction should live. Laws: Cognitive Load (hidden content the user must find adds load), Fitts's Law (a hover target is a target to acquire; touch has no hover at all). Call: if the user cannot complete the field without the instruction, render it as visible helper text near the Input. Reserve Tooltip for non-essential clarification — which is what the Tooltip page already requires. The framework here just names why the line is drawn where it is.

Whether to Show a Loading Indicator

Decision: a form submit that usually resolves in 200–600 ms. Laws: Doherty Threshold (the ~400 ms line), Peak-End Rule (the finish is what gets remembered). Call: put the submit Button into its documented loading state immediately on click — it acknowledges the action without a layout shift — and make the success state clear and specific when the response lands. No full-screen spinner for work this short. The Button loading prop and its behavior are as documented; nothing new is introduced.

References and Origins

The laws on this page come from decades of human–computer interaction and cognitive-psychology research. The one-line summaries under each heading are Monogem's own paraphrases, kept short on purpose; the Use when / Avoid when / Consider instead framing and every worked example are Monogem's. For the primary or most-cited source behind each law:

Hick's Law — W. E. Hick, On the rate of gain of information (1952), with related work by R. Hyman (1953).
Fitts's Law — P. M. Fitts, The information capacity of the human motor system in controlling the amplitude of movement (1954).
Jakob's Law — named by Jakob Nielsen, Nielsen Norman Group (2000).
Cognitive Load — J. Sweller's cognitive load theory (1988); the working-memory limit traces to G. A. Miller, The Magical Number Seven, Plus or Minus Two (1956).
Choice Overload — S. Iyengar and M. Lepper, When choice is demotivating (2000); popularized by B. Schwartz, The Paradox of Choice (2004). Later replications and meta-analyses find the effect smaller and more condition-dependent than the popular version suggests.
Gestalt Principles — Gestalt psychology (Wertheimer, Koffka, Köhler), 1920s.
Peak-End Rule — D. Kahneman and colleagues (1993); see also Kahneman, Thinking, Fast and Slow (2011).
Tesler's Law — the Law of Conservation of Complexity, attributed to Larry Tesler (c. 1984).
Doherty Threshold — W. J. Doherty and A. J. Thadhani, The Economic Value of Rapid Response Time (IBM, 1982).

Laws of UX and Nielsen Norman Group articles are useful secondary overviews of several of these. This page reproduces none of their text, diagrams, or illustrations.

Boundaries

Evidence, not authority. The Design Approach and each component's documented contract outrank anything on this page.
No redefinition. This framework never changes semantics, token naming, component naming, variants, states, or shadcn-style conventions.
No blanket rollout. Apply it to a named decision and record the rationale there. Do not thread it through every component doc.
No replacement for testing. A law is a hypothesis about behavior; a usability test is the check.