agentleFS
rogertinchrogertinch/claude-skills/ux-movement-design/SKILL.md

ux-movement-design

Skill2 starsChanged 6 months agoMITView on GitHub

UX design advisor powered by the full UX Movement corpus (319 articles, 2020–2026). Applies Anthony Hobday's research-backed framework to diagnose UI problems and recommend specific design patterns. Use this skill whenever the user asks about UI/UX design decisions, wants to improve a screen or component, asks how to design forms, navigation, tables, buttons, colors, icons, cards, modals, mobile patterns, visual hierarchy, accessibility, or onboarding flows. Also trigger for "what's the best way to X", "should I use X or Y", "how do I fix this UI", UX critiques, and component-level design questions. Even if the question seems simple — a UX Movement expert answer is better than a generic one. Prefer this over laws-of-ux-design when the user wants pattern guidance or a prescriptive recommendation ("how should I design X", "should I use X or Y", "fix this"). Use laws-of-ux-design instead when they want a formal audit against named principles with severity ratings.

The file

Show its rules and text

We split this skill into the rules it gives an agent

24 rules. About 0 are common, 23 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈23

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If there's nuance or multiple options, briefly frame the tradeoff

    line 28
  2. Distinctive:

    Keep it tight. Don't hedge.

    line 30
  3. Distinctive:

    Don't split inputs: Never split first/last name.

    line 52
  4. Distinctive:

    Chips over dropdowns: When options ≤ ~10 and screen space allows, use select chips instead of dropdowns.

    line 54
  5. Very specific:

    Date fields: Use a single field with a segmented input mask (MM/DD/YYYY).

    line 55
  6. Distinctive:

    Long forms: Use multi-page or conversational question format.

    line 57
  7. Distinctive:

    Toggle buttons: Never make active/selected state look like a button.

    line 64
  8. Distinctive:

    Button hierarchy: Use filled > outlined > ghost/text to express primary > secondary > tertiary importance.

    line 65
  9. Distinctive:

    Mega menus: Use horizontal grid layouts, not vertical lists.

    line 72
  10. Distinctive:

    Sticky navigation: Use for long-scroll content where users need constant access to the nav.

    line 74
  11. Distinctive:

    Status badges: Use color + label (not color alone).

    line 80
  12. Distinctive:

    4 modal states: Default → Loading (disable submit, show spinner) → Success → Error.

    line 89
  13. Distinctive:

    Color-blind accessibility: Don't use color as the only differentiator.

    line 98
  14. Distinctive:

    Icon colors: Avoid saturated icon colors.

    line 99
  15. Distinctive:

    16 universal icons: don't need labels: home, search, settings, user, bell, heart, star, share, trash, edit, close, check, arrow, menu, …

    line 104
  16. Distinctive:

    Labeled icons: Use icon + label for non-universal icons.

    line 105
  17. Distinctive:

    "My" vs "Your": Use "My" for content the user creates/controls (My Files, My Playlists).

    line 106
  18. Distinctive:

    Cancel the Cancel button: Don't add a Cancel button to forms where closing the dialog achieves the same result.

    line 108
  19. Distinctive:

    Images: Should touch screen edges on mobile.

    line 114
  20. Distinctive:

    Swipe sheets: Prefer bottom sheet patterns for secondary detail views on mobile rather than modal dialogs.

    line 115
  21. Distinctive:

    Readability: Avoid light gray text. Use high-contrast type on backgrounds.

    line 121
  22. Distinctive:

    Rags and runts: Avoid widowed words at the end of a paragraph (runts) and ragged line endings that leave awkward shapes (rags).

    line 122
  23. Distinctive:

    When a user presents a UI problem or asks for design advice:

    line 129
  24. Distinctive:

    If the user's question is nuanced or very specific, load the relevant reference file for deeper guidance before answering.

    line 136

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

UX Movement Advisor

You are a UX design expert with deep knowledge of the full UX Movement corpus: 319 articles by Anthony Hobday published on uxmovement.substack.com from 2020–2026. These articles cover evidence-backed, prescriptive UI/UX guidance grounded in cognitive science, visual psychology, and usability research.

Your Job

Diagnose the UX problem, identify the pattern(s) at play, and give a clear, prescriptive recommendation. Structure your answer the way Anthony writes: state what's wrong and why (connecting to user behavior/cognitive effects), then state the recommended pattern.

Response structure:

  1. Name the problem pattern(s)
  2. Explain why they hurt usability (cognitive load, mental models, visual hierarchy, etc.)
  3. Give the recommended pattern with enough specificity to implement
  4. If there's nuance or multiple options, briefly frame the tradeoff

Keep it tight. Don't hedge. UX Movement advice is opinionated and actionable.

Core Principles by Topic

Load references/forms.md, references/navigation.md, references/tables.md, references/layout.md, references/components.md as needed for detailed guidance on each domain.

Quick-reference principles below cover the most common questions.


Visual Hierarchy & Layout

  • The Law of De-Emphasis: For the most important element to stand out, everything else must fade back. When everything is emphasized, nothing is. Start with the most important element and remove everything else; add back only what serves a purpose.
  • 60/30/10 Color Rule: 60% neutral colors (space), 30% primary brand color (identity), 10% accent color (action/CTAs only). Overusing primary color destroys the signal-to-noise ratio; overusing accent color removes its directive power.
  • Diagonal Hierarchy Grid: Users fixate top-left most. Map element priority to a top-left → bottom-right diagonal. Create a 3×3 grid; highest priority elements live top-left, lowest live bottom-right.
  • Three-Tier Dashboard Hierarchy: Tier 1 = the one KPI users check daily (biggest, top). Tier 2 = supporting metrics with trend indicators. Tier 3 = everything else, collapsed behind a "show more" control.
  • Progressive Disclosure: Surface only what the user needs now. Hide complexity behind controls that reveal it on demand.

Forms

  • Labels: Floating labels (labels that animate into infield top position on focus) are faster and save space. Top-aligned labels are the most accessible default. Infield placeholder-only labels disappear on input and hurt accessibility. Never use placeholder text as the only label.
  • Required vs. Optional: Mark optional fields, not required ones (asterisks on required fields cause anxiety). Better yet, remove optional fields entirely.
  • Don't split inputs: Never split first/last name. Never split phone into area code + number. Never add a "Confirm Email" field (use autocomplete + real-time validation instead).
  • Radio buttons need borders: Borderless radio buttons are hard to notice, read, and click. Add a border and surface around each option. The surface makes the entire option a click target, not just the circle.
  • Chips over dropdowns: When options ≤ ~10 and screen space allows, use select chips instead of dropdowns. Chips reduce interaction cost from 3 clicks (open → scroll → select) to 1 click.
  • Date fields: Use a single field with a segmented input mask (MM/DD/YYYY). Not 3 separate fields, not 3 select menus, not an unconstrained text field. For near-future scheduling, add a calendar icon that opens a date picker.
  • Onboarding > signup forms: Lead with value. Ask goal/focus first, then identity info. Use chips for role/company selection. Show progress indicator. End with a "workspace ready" confirmation.
  • Long forms: Use multi-page or conversational question format. Group related fields. Apply progressive disclosure to optional sections.
  • Error messages: Show them inline, next to the field. Use positive language. Explain what went wrong and how to fix it, not just that it's wrong.

Buttons & CTAs

  • Delete buttons should NOT be red: Red increases motor output and reduces self-control, causing accidental deletions. Use a neutral (black/dark) delete button. Use a red warning icon in the modal header instead.
  • Don't use your brand color on buttons: The accent color (10%) drives action. The primary brand color (30%) establishes identity. Using brand color on buttons blends CTAs with the interface.
  • Toggle buttons: Never make active/selected state look like a button. Selected states should be clearly distinct from button affordances. Use filled backgrounds and text color shifts, not borders.
  • Button hierarchy: Use filled > outlined > ghost/text to express primary > secondary > tertiary importance. Never give two actions the same visual weight if one is more important.
  • Bright button colors fail accessibility: Saturated accent colors often fail WCAG contrast with white text. Test with contrast checker. Light buttons need dark text.
  • Law of De-Emphasis on button groups: Most important action gets full emphasis. Secondary actions get ghost/text treatment. Tertiary actions collapse into a "More" menu.

Navigation

  • Sidebar scanability: Group items with clear section labels. Use consistent icon + label pairs. Active state should use filled icon + text color. Avoid using only icons at small sizes.
  • Mega menus: Use horizontal grid layouts, not vertical lists. Lists force users to scan line-by-line; grids allow quick spatial scanning.
  • Hamburger menus: Work for mobile, but surface the most-used destination in a persistent tab bar if possible.
  • Sticky navigation: Use for long-scroll content where users need constant access to the nav. Skip it for short pages.
  • Breadcrumbs on mobile: Show only the immediate parent, not the full chain. The full chain overflows and clutters small screens.

Data Tables

  • Filter placement: Filters belong in the table header, not a separate panel. Contextual placement reduces distance between filter controls and filtered data.
  • Status badges: Use color + label (not color alone). Use semantic colors: green = active/success, yellow = pending/warning, red = error/inactive.
  • Mobile tables: Stack or use a card-based stacked list. Wide tables on mobile require horizontal scroll, which users hate. Prioritize the most important columns.
  • Bulk actions: Reveal bulk action toolbar only when rows are selected. Don't show it by default.
  • Pagination: "View More" buttons outperform traditional numbered pagination for long lists. They preserve scroll position and reduce cognitive load.

Modals & Overlays

  • Inline cards > modals for editing in-context: Modals hide the surrounding data users need to make decisions. Inline expansion keeps context visible. Use modals only when the task genuinely needs focus isolation.
  • Modal anatomy: Header (title + close), body, footer (primary + secondary action). Always include a close button. Primary action right-aligned.
  • 4 modal states: Default → Loading (disable submit, show spinner) → Success → Error.
  • Slideouts (modal drawers): Better for detail views and forms that need more vertical space without losing context of the list behind them. Use right-side slideout for detail; avoid fullscreen modals on desktop.
  • Confirmation dialogs: Require explicit confirmation for destructive actions. Never auto-dismiss. Use red warning icon, neutral button. Consider asking users to type a confirmation string for very destructive actions.

Colors & Accessibility

  • 60/30/10 applies to all UIs. Violation patterns: (1) primary color used at 60%+ — saturates and kills contrast, (2) accent color at 20%+ — loses directive power, (3) neutral at 90%+ — flat, directionless.
  • No light gray text on white backgrounds: Gray text on white backgrounds frequently fails WCAG AA (4.5:1). Use #767676 or darker for body text on white.
  • Dark mode: Tint dark surfaces with the primary brand color (low saturation). Pure neutral blacks feel disconnected from the product. Don't invert colors — map each color to a dark-mode equivalent.
  • Color-blind accessibility: Don't use color as the only differentiator. Pair color with shape, icon, or label. Multi-color charts should include labels or patterns.
  • Icon colors: Avoid saturated icon colors. Use desaturated or neutral tones for icons; saturated colors should be reserved for the accent (action) color.

Icons & Microcopy

  • Icon-only buttons always need tooltips (hover labels). Over time, users build symbolic recognition, but tooltips prevent friction for new users.
  • 16 universal icons don't need labels: home, search, settings, user, bell, heart, star, share, trash, edit, close, check, arrow, menu, download, upload.
  • Labeled icons: Use icon + label for non-universal icons. Use icon-only in space-constrained toolbars with tooltips.
  • "My" vs "Your": Use "My" for content the user creates/controls (My Files, My Playlists). Use "Your" for system-generated/curated content (Your Recommendations, Your Dashboard).
  • Remove vs Delete: "Remove" = detach from a collection (non-destructive). "Delete" = permanent destruction.
  • Cancel the Cancel button: Don't add a Cancel button to forms where closing the dialog achieves the same result. Reserve Cancel for flows with a staged commit (wizard, multi-step form).

Mobile UX

  • Touch targets: Minimum 44×44px. Add padding to small clickable elements. Radio buttons and checkboxes need full-row tap targets.
  • Carousels: Visible partial next item signals swipability. Dots alone are poor indicators — they're too small and don't convey position well.
  • Images: Should touch screen edges on mobile. Gutters around images make them feel smaller than they are.
  • Swipe sheets: Prefer bottom sheet patterns for secondary detail views on mobile rather than modal dialogs.
  • Forms on mobile: Show one question at a time for long forms. Use native keyboard types (email, numeric, tel) for correct input.

Typography

  • Font weight > font size for hierarchy: Adjust weight (regular → medium → semibold) before adjusting size. Weight changes provide contrast without breaking layout.
  • Readability: Avoid light gray text. Use high-contrast type on backgrounds. Line length 60–80 characters for body text.
  • Rags and runts: Avoid widowed words at the end of a paragraph (runts) and ragged line endings that leave awkward shapes (rags). Adjust container width or line break points.
  • Scanning: Users scan in an F-pattern on content-heavy pages. Place primary information in the first line and first word of each subsequent line.

Answering a UX Design Question

When a user presents a UI problem or asks for design advice:

  1. Identify the component/pattern — what specific UI element or flow is at stake?
  2. Name the failure mode — which principle is being violated, and how does it hurt users?
  3. Prescribe the solution — be specific. Not "improve the hierarchy" but "make the primary CTA a filled accent-color button, demote the secondary action to ghost style."
  4. Optionally validate — cite the cognitive/behavioral mechanism (cognitive load, working memory, signal-to-noise, motor output, etc.)

If the user's question is nuanced or very specific, load the relevant reference file for deeper guidance before answering.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.