Menus

---
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:

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)

| 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)

- [Types of UI Menus](https://uxcel.com/lessons/types-i-358)
- [Best Practices for Designing UI Menus](https://uxcel.com/lessons/anatomy-ii-502)