UX Menus

Menus Skill

How this skill behaves (read first)

This is a generative skill. The default failure modes: catch-all dropdowns (unrelated actions dumped into one menu), deep ambiguous nesting (cascading levels users get lost in), and unordered item lists (no prioritization, no grouping, jargon labels). A menu is a curated, ordered set of related actions — when it stops being that, the fix is changing the flow, not adding levels. This skill gates:

1. Establish the action set — what actions, how related, how many, selection or command?
2. Apply the always-true core — type from structure, priority ordering, grouping, labels, states.
3. Surface the context-dependent decisions (cascading, contextual, search-in-menu, shortcuts) with trade-offs.

Then it hands off to ux-heuristics-audit, ux-accessibility-audit, ux-aesthetics-audit, and ux-microcopy-audit for validation.

Scope & composition (per docs/orchestration-policy.md §9): this skill owns menu structure and anatomy. Peers that own a sub-part (defer — each handles its sub-part if reached): ux-navigation owns where menus live in the overall navigation system (hamburger placement, mega menus, top bar vs. sidebar), and ux-selection-controls owns the choice between menus vs. radio/checkboxes for form selection.

Step 0 — Establish the action set

Ask if not known; state the assumption if proceeding without an answer:

• Commands or selection? Triggering actions (Copy, Delete) vs. choosing values (filter options) — selection menus need selection indicators and single/multi-select decisions; command menus need verbs and possibly shortcuts.
• How many items, how related? A menu only earns its place if the items belong together. Unrelated actions → split or rethink the flow. Very long lists → search menu or a different control.
• Is there sub-structure? Real parent-child categories may justify cascading — but if children multiply, change the user flow instead.
• Platform — contextual (right-click) menus are desktop-native; multiselect menus are hard on mobile; hover states need touch equivalents.

The always-apply core (correct for almost every case)

Pick the type from the structure of the choice

• Basic dropdown — one pick from a simple list; closes on selection.
• Single-select — mutually exclusive options with a clear selection indicator (checkmark, bold, overlay). Don't use it to launch modals or dynamic controls.
• Multiselect — checkboxes/tags for combinable options; selected items always visible and removable in the menu input — never force backtracking to deselect.
• Search menu — long lists (countries, languages): auto-suggest filtering as users type.
• Contextual menu — frequent actions for the clicked element (right-click/long-press), appearing at the pointer, options varying by target.
• Inline / overflow (⋮) menu — per-row actions in tables and lists (Edit, Delete, Download) without leaving the view.
• Cascading menu — only for genuinely categorized actions (New → document types); see the gated table.

Order and group — this is where menus are won

• Most-used items at the top. Don't hide critical options behind extra levels when space exists; working memory holds ~5–9 items, so the primary list carries the important actions, the rest go a level down or out.
• Dividers cluster related items — pale lines, not separate menus; grouping makes the list scannable without clutter.
• Scrolling is a smell: a scroll bar is mandatory if you scroll, but beyond a couple of wheel-turns of options, add search or change the flow.

Labels and icons

• Labels say what happens — short, conventional ("Paste," not "Insert"), no jargon or wordplay; truncate unavoidable long labels with tooltip access; a wrapped label is a label that needs rewriting. Test labels (card sorting) — what's clear to you confuses users.
• Leading icons before labels (LTR) — familiar, universal icons only (scissors = Cut); unfamiliar icons slow users down more than no icon.
• Familiar selection marks — checkmark or ×; nothing inventive.

States and behavior

• Hover/focus feedback on every item (subtle overlay, elevation, or border) and visible states for selected/disabled.
• Predictable open/close: opens on tap/click, closes on outside click. No surprises.
• Items ≥48×48px with comfortable padding — legibility and motor-impairment access.
• Elevation (~8dp) separates the menu from the page — it should read as a floating, actionable surface.

The context-dependent decisions (surface, don't auto-apply)

Validate the result (orchestration)

Hand-offs name each lens by its installable skill name. Invoke one only if that skill is installed; if it isn't, this skill's own core already carries these rules — proceed without it rather than blocking.

After generating or revising, hand the result to the audit lenses rather than declaring it done. These are candidate lenses — posture is set by docs/orchestration-policy.md, or route the whole thing through ux-design-review. Here, heuristics and microcopy are Tier A (auto-run); accessibility, aesthetics, information-architecture, and mobile-responsiveness are Tier B (offered) — under an existing design system aesthetics is suppressed and accessibility narrows to usage; mobile-responsiveness applies only on mobile. If the user invoked this skill for one specific thing, respect that scope.

• ux-heuristics-audit (Tier A) — recognition over recall (visible critical options), consistency of behavior, user control (easy deselection, predictable dismissal).
• ux-accessibility-audit (Tier B — offer; narrow under a design system) — keyboard navigation through items, 48px targets, contrast of labels and dividers, non-hover access to everything.
• ux-aesthetics-audit (Tier B — offer; suppress under a design system) — spacing, elevation, grouping rhythm; whether the menu reads as one clean surface.
• ux-microcopy-audit (Tier A) — label clarity, conventional verbs, truncation choices.
• ux-information-architecture-audit (Tier B — offer) — whether the menu's grouping, depth, and label system match user mental models and carry information scent; this skill structures the menu surface, IA owns the category model behind it.
• ux-mobile-responsiveness-audit (Tier B — offer; applies only on mobile) — when the context is mobile: touch targets, no hover-dependence, multiselect pattern fit.

If the audits surface a conflict (e.g., completeness vs. scannability), resolve back toward the primary task: the user opens a menu to act fast — every item competes for the same scan.

Common do/don't patterns

Source lessons (Uxcel)

• Types of UI Menus
• Best Practices for Designing UI Menus