| name | ux-menus |
| description | Design or critique UI menus — pick the right menu type (dropdown, cascading, contextual, single/multi-select, search, inline) for the action set, and apply item ordering, grouping, labeling, and state best practices. Trigger when the user asks to design or review a menu, dropdown, context/right-click menu, overflow (⋮) menu, or asks how to organize actions into a menu. |
| license | MIT |
| metadata | {"author":"uxcel","version":"1.0.0"} |
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:
- Establish the action set — what actions, how related, how many, selection or command?
- Apply the always-true core — type from structure, priority ordering, grouping, labels, states.
- 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)
| Decision | Apply when | Avoid / adapt when | Default recommendation |
|---|
| Cascading menu | True parent-child action categories; desktop, with room to unfold | Many/deep children (cumbersome, overwhelming); mobile; tight layouts — check unfold space with mockups | One child level max; if it grows, restructure the flow |
| Contextual (right-click) menu | Desktop power workflows; element-specific frequent actions | As the only access to a function (undiscoverable); touch-first products | Context menu as accelerator; every action also reachable visibly |
| Search inside the menu | Long lists where scrolling is tedious | Short lists (overhead) | Add when the list exceeds a couple of scroll-turns |
| Keyboard shortcuts shown in the menu | Productivity tools with repeat actions (copy/cut/paste) | Inventing non-standard shortcuts; shortcut-only access | Standard shortcuts on the most common commands, displayed in the menu |
| Multiselect pattern | Hotkey+click, checkboxes, or tag collection — pick by audience and platform | Hotkey-based multiselect on mobile or for casual audiences | Checkboxes/tags; selections visible and removable in place |
| Icon-only inline menus (⋮) | Dense tables needing per-row actions | Burying the row's single most important action in the overflow | Primary row action visible; secondary actions in ⋮ |
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
| ❌ Don't | ✅ Do |
|---|
| One dropdown holding every miscellaneous action | Related actions only; restructure when it stops being a set |
| Three levels of cascading children | One child level; if it grows, change the flow |
| Alphabetical order regardless of use | Most-used first; secondary items a level down |
| Flat list of 14 ungrouped items | Dividers clustering related actions |
| "Insert" when everyone says "Paste" | Conventional, tested labels |
| Decorative or clever icons per item | Universal icons only — or no icon |
| Right-click as the only way to delete | Contextual menu as accelerator, visible path exists |
| Deselecting requires reopening and hunting | Selected items shown and removable in place |
| Menu stays open on outside click | Standard open/close behavior |
| 32px cramped rows | ≥48px items with breathing room |
| Ship without checking | Hand off to heuristics + accessibility + aesthetics + microcopy |
Source lessons (Uxcel)
