agentsclimarketplace

Laws of ux

Skill imikailoby/claude-skills/skills/laws-of-ux

Apply the Laws of UX — psychology and Gestalt heuristics used as lenses on interface work. Use when designing or building any frontend a human will look at and use, when auditing or critiquing UX (heuristic evaluation, "is this good UX?", design review), or when a specific law is named (Hick's, Fitts's, Jakob's, Peak-End, the Gestalt grouping laws, …).From its SKILL.md

Install
npx -y skills add imikailoby/claude-skills --skill laws-of-ux

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 20 days oldThe repository was created 20 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

6.5 KB, ~1.4k tokens by cl100k_base, as published. Nobody here has run it

Laws of UX

Heuristic lenses for designing and critiquing interfaces. A lens is a default, not a mandate: apply the ones that fit, name each lens you use so feedback is concrete and teachable, and stay anchored to the user's actual goal — when their context or research contradicts a lens, the context wins; say so explicitly.

Load references/laws-catalog.md for a law's full takeaways, examples, and origins — reach for it when a finding needs depth or the user asks why.

Designing / building

Pick the 3–5 lenses most relevant to the surface (a form → Tesler's, Postel's, Working Memory, Doherty; a landing page → Hick's, Von Restorff, Serial Position, Aesthetic-Usability) and let them shape the choices as you make them. Done when the delivered design names the lenses that shaped it.

Auditing / reviewing

Walk every group below. Cite a lens only where there's a real issue or a real win. Done when all six groups have been walked and every finding carries three parts: the law by name, a severity (critical / important / nice-to-have), and a concrete fix.

Decisions & choices (reduce friction to act)

  • Hick's Law — Too many choices at once? Break into steps, group, defer. Decision time grows with number/complexity of options.
  • Choice Overload — Long undifferentiated lists (plans, products)? Add filtering, a recommended/featured default, side-by-side comparison.
  • Miller's Law — Are items chunked into ~5–9 groups rather than one flat dump? (Chunking guidance, not a quota — never cite "7±2" to justify an arbitrary limit.)
  • Occam's Razor — Can any element be removed without losing function? Remove it. Simplest sufficient design wins.
  • Tesler's Law — Irreducible complexity exists — is the system absorbing it, or is it dumped on the user (e.g. asking for data you could infer/autofill)?

Targets & interaction (make actions easy to hit)

  • Fitts's Law — Are interactive targets large enough, well-spaced, and near the user's focus? Primary actions shouldn't be tiny or far.
  • Postel's Law — Inputs liberal in what they accept (phone/date formats, casing, whitespace), strict/clear in what they emit and validate? Forgiving + clear feedback.
  • Doherty Threshold — Feedback under ~400ms? Use optimistic UI, skeletons, progress, and perceived-performance tricks where work is slow.
  • Flow — Does the path keep the user in focused momentum (clear feedback, minimal friction), matching challenge to skill?

Attention & emphasis (guide the eye)

  • Von Restorff (Isolation) Effect — Does the single most important action/element stand out visually — with one emphasis, not competing ones, and not styled like an ad?
  • Selective Attention — Anything important styled like/next to ads (banner blindness)? Any critical change that could go unnoticed (change blindness)?
  • Serial Position Effect — Are key items first/last in lists & nav (primacy/recency), least-important in the middle?
  • Aesthetic-Usability Effect — Is it visually polished? Pleasing design raises perceived usability and buys tolerance — and can mask real usability bugs in testing, so verify usability separately.

Grouping & layout (Gestalt — structure perception)

  • Law of Proximity — Related things near each other; unrelated things spaced apart. Spacing communicates relationship.
  • Law of Common Region — Use a shared boundary/background (card, panel) to bind a group.
  • Law of Uniform Connectedness — Visually connect related controls (shared color/line/frame); connect with a line/arrow when showing relationships.
  • Law of Similarity — Similar appearance implies similar function; make links/nav visually distinct from body text.
  • Law of Prägnanz — Resolve ambiguity toward the simplest form; simple shapes are processed and remembered better.

Memory & cognition (don't overload the user)

  • Cognitive Load — Cut extraneous load (decorative noise, irrelevant info); respect intrinsic load. Is every element earning its mental cost?
  • Working Memory — Recognition over recall: carry context across screens (breadcrumbs, visited states, comparison tables) so users never hold info in their head.
  • Chunking — Is content grouped into scannable, hierarchical modules (e.g. formatted phone/card numbers, sectioned forms)?
  • Mental Model / Jakob's Law — Does it match conventions users already know from other sites/apps? Innovate on value, conform on patterns. On big changes, let users opt into the new version.

Motivation & memory of the experience (completion & feeling)

  • Zeigarnik Effect — Use progress indicators, clear signifiers of more content, and (honest) head-start progress to motivate completion.
  • Goal-Gradient Effect — Show proximity to the goal; people accelerate near the finish. Visible progress + a small head start works.
  • Parkinson's Law — Keep task duration at or under expectation — speed it up with autofill and smart defaults before it expands to fill the time.
  • Peak-End Rule — Invest in the emotional peak and the final moment (confirmations, success states, waits). Negatives are remembered more vividly — defuse them.
  • Pareto Principle — Are you investing effort in the ~20% of features/flows that drive ~80% of value? Prioritize there.
  • Paradox of the Active User — Users dive in without reading docs. Put guidance in-context (tooltips, inline hints) along whatever path they take.
  • Cognitive Bias — Watch for biases (e.g. confirmation bias) in both users and your own design/research decisions; design safeguards against them.

Tensions & guardrails

  • Lenses conflict (Jakob's familiarity vs. a novel differentiator; Occam's minimalism vs. Tesler's irreducible complexity). Surface the tension and make a reasoned call.
  • The motivation lenses (Goal-Gradient, Zeigarnik, Peak-End, Cognitive Bias) can manipulate. Use them to help users finish their goals — a dark pattern is a critical finding, never a recommendation.

What ships with it: 1 file

17.7 KB alongside SKILL.md

references/

Gives 0 of the 12 instructions most design frontend skills give in ~1.4k tokens

Counted across 1,169 of the 1,878 authors here whose files we hold, read 2026-08-07

  • Use CSS variables for color consistencyin 72 of 1169, across 23 files
  • Commit to one bold aesthetic direction before codingin 72 of 1169, across 27 files
  • Match implementation complexity to the aesthetic visionin 70 of 1169, across 20 files
  • Add atmospheric background effects and texturesin 57 of 1169, across 9 files
  • Use unexpected spatial compositions and layoutsin 56 of 1169, across 8 files
  • Implement real working codein 55 of 1169, across 7 files
  • Vary themes and aesthetics across different designsin 48 of 1169, across 7 files
  • Launch chromium in headless modein 47 of 1169, across 4 files
  • Close the browser when donein 47 of 1169, across 4 files
  • Run provided scripts with help flag firstin 47 of 1169, across 4 files
  • Wait for network idle statein 47 of 1169, across 4 files
  • Use descriptive selectors for elementsin 47 of 1169, across 4 files

Said here and by no other author read

  • apply 3 to 5 relevant laws to the design
  • walk every heuristic group during reviews
  • name the lens for each design choice or finding
  • load the catalog for detailed takeaways
  • surface conflicts between lenses
  • state when user context overrides a lens

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,629. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.