SaaS Context Menu & Overflow Action UX Patterns: Real Screenshots (2026)
Every SaaS product eventually runs out of room. A row in a table, a card on a board, a file in a list, an object on a canvas — each can do far more than its visible buttons suggest, and the interface needs somewhere to put the rest of the actions without drowning the primary layout in controls. The context menu is that somewhere: the kebab (⋮) or "more actions" button that opens a tidy list of everything you can do to a thing, and the right-click menu that surfaces the same actions where your cursor already is. Done well it keeps a busy product calm — the surface stays clean, the common action stays one click away, and the long tail of rename, duplicate, move, share, archive, and delete lives one tap deeper in a menu that is grouped, labelled, and predictable. Done badly it is a junk drawer: twenty ungrouped items in a random order, a delete sitting flush against duplicate so a slip wipes real work, actions that should be disabled shown as live and then failing, and a menu that opens off the edge of the screen. This guide covers the decisions that make an overflow menu feel like a well-organised toolbox rather than a dumping ground — what belongs in the menu versus on the surface, how to group and order items, how to keep destructive actions safe, how to signal state, and how to make the menu reachable by mouse, keyboard, and touch — each shown with real SaaS screenshots from shipped products instead of mockups.
The moment a SaaS product gives users more than one thing they can do to an object, it faces a layout problem that never goes away: there is not enough room to show every action, every time, on every row, card, and item. A file in a list can be opened, renamed, moved, duplicated, shared, downloaded, starred, and deleted; a task on a board can be edited, assigned, labelled, converted, duplicated, and archived; a member in a settings table can be promoted, suspended, resent an invite, or removed. Surfacing all of that inline would bury the actual content under a hedge of buttons. The context menu is the pattern SaaS products use to solve this: a compact "more actions" affordance — most often a kebab (⋮) or meatball (⋯) button, or a right-click on the object itself — that opens a tidy list of everything you can do to that specific thing. Linear, Notion, Airtable, Figma, Google Drive, Slack, GitHub, and essentially every product with a list or a canvas ships some version of it, because it is what lets a dense interface stay clean while still keeping a deep well of actions one tap away.
Clay — a real navigation screen from the SaaSUI library.
The job of a context menu is to hold the actions that belong to an object without cluttering the surface — to be the calm, predictable place a user goes when they want to do something to a row, a card, a file, or a selection beyond the one or two primary things the layout shows inline. It is worth scoping precisely because it blurs into surfaces it is not: it is not a dropdown select (a form control for choosing a value from a list, where the point is picking one option, not firing an action), it is not the bulk-actions toolbar (which acts on many rows a user has explicitly selected, not the single object under the cursor), and it is not the keyboard-shortcuts system (though a good menu advertises those shortcuts). It is the object-scoped action list — the menu behind the ⋮, the thing a right-click reveals. The decisions below are what separate a context menu that feels like a well-organised toolbox from one that is a chaotic junk drawer where destructive actions lurk next to routine ones — each shown with real SaaS screenshots so you can see how mature products organise the long tail of actions.
Put the right actions in the menu — and keep the primary ones out of it
A context menu earns its keep by holding the actions that do not deserve permanent space on the surface, which means the first decision is what belongs inside it versus what stays inline. The strong pattern keeps the one or two highest-frequency, lowest-risk actions visible on the object itself — the button people reach for constantly — and pushes the long tail of occasional actions (rename, duplicate, move, export, archive, and the like) into the overflow menu where they are available without being loud. It does not hide the primary action behind the kebab out of a misplaced love of minimalism, forcing an extra click on the thing users do most; nor does it dump literally everything into the menu so the surface has no direct action at all. It sizes the menu to the object: a table row, a board card, and a canvas element each get the actions that actually apply to them, not a generic superset. And it resists the temptation to let the menu metastasise into a catch-all for every feature the team could not place elsewhere. The anti-patterns are a primary action buried in the overflow so the common case takes two clicks, a surface so crowded with inline buttons that the menu is pointless, and a single bloated menu of twenty-plus items that no user reads to the bottom. Keep the frequent action on the surface, and give the menu the meaningful long tail — no more, no less.
Confluence — a real navigation screen from the SaaSUI library.
Group and order items so the menu is scannable, not a wall of text
A menu with more than a handful of items is only usable if its structure does the reading for you, so grouping and order matter as much as the items themselves. The strong pattern arranges actions into meaningful clusters separated by dividers — create/edit actions together, move/organise actions together, share/export together, and destructive actions in their own group at the bottom — so the eye lands on the right region instead of scanning every line. It orders items by a stable logic (frequency and workflow, roughly top to bottom) and keeps that order identical every time the menu opens, because a menu whose items shuffle is a menu users can never build muscle memory for. It uses concise, verb-first labels ("Duplicate", "Move to…", "Rename") rather than vague nouns, and pairs each with a small leading icon so the group is scannable by shape as well as word. It uses submenus sparingly — a "Move to →" that expands into a folder list is fine; three levels of nesting for routine actions is not. The anti-patterns are a flat, undivided list of fifteen items in no discernible order, labels that change position between sessions, ambiguous wording that makes users hover-and-guess, and deeply nested submenus that turn a quick action into a scavenger hunt. Group, divide, order stably, and label with verbs so the menu reads at a glance.
Keep destructive actions separated and safe
The single most common way a context menu betrays its user is by placing something irreversible one careless pixel away from something routine, so destructive actions demand deliberate protection. The strong pattern isolates delete, remove, archive, and their kin in their own group at the bottom of the menu, set off by a divider and usually tinted with a warning colour, so they are never adjacent to a benign action like "Duplicate" that a slipped click could turn into a disaster. It reinforces the visual separation with a real safety net for anything truly irreversible — a confirmation step, a typed-name check for the severe cases, or better still an undo affordance after the fact so the common accidental delete is one click to recover rather than a support ticket. It resists putting a destructive action first or in the muscle-memory position where users click without reading, and it never hides a hard delete behind an innocuous label. It also respects reversibility as a spectrum: an archive that is easily restored needs less friction than a permanent purge, and the menu should signal which is which. The anti-patterns are delete sitting flush against duplicate with no divider or colour, an irreversible action with no confirmation or undo, a destructive item in the top slot where errant clicks land, and a "Remove" that quietly means "permanently destroy". Separate the destructive group, colour it, and back the irreversible ones with confirmation or undo.
MakeForms — a real navigation screen from the SaaSUI library.
Signal state honestly — show what applies, disable what does not
A context menu is contextual by definition, which means its most important quality is that it reflects what the user can actually do to this object right now, not a static list that lies. The strong pattern tailors the menu to the object and the user’s permissions: it omits or disables actions that do not apply — no "Restore" on a live item, no "Publish" on something already published, no "Delete" for a viewer who lacks the right — so the menu never offers a door that leads nowhere. When it disables rather than hides an item (useful when the action exists but is temporarily unavailable), it dims it clearly and, ideally, explains why on hover ("You need admin access to remove members") rather than leaving the user to click a dead option and wonder. It reflects current status in the labels themselves — "Unarchive" instead of "Archive" for an archived item, "Remove from favourites" for a starred one — so the menu is a mirror of state, not a fixed script. And it keeps the menu fast to open, resolving these states without a visible lag that makes the interface feel broken. The anti-patterns are a menu that shows every possible action regardless of state and then fails when one is chosen, disabled items with no explanation, labels that contradict the object’s actual status, and permission-gated actions shown as live to users who cannot perform them. Make the menu tell the truth about what is possible — hide or explain the rest.
Perplexity.ai — a real navigation screen from the SaaSUI library.
Make the menu reachable and positioned well — mouse, right-click, keyboard, and touch
A context menu is only as good as a user’s ability to summon it, read it, and dismiss it across every input they actually use, so reach and positioning are not afterthoughts. The strong pattern offers more than one route to the same actions: a visible kebab (⋮) button for discoverability (right-click is invisible to anyone who does not know to try it), a right-click context menu on the object for power users who expect it, and full keyboard operability — the menu opens on Enter or the context-menu key, arrow keys move through items, Escape closes, and focus returns to the trigger afterwards. It positions the menu intelligently so it never opens off-screen: it flips above the trigger when there is no room below, aligns to the edge nearest the object, and stays anchored to what it belongs to rather than floating loose. It adapts to touch, where hover and right-click do not exist, by making the kebab a comfortably tappable target and the menu items large enough for a thumb, and it advertises keyboard shortcuts inline (a greyed "⌘D" beside "Duplicate") to teach the faster path. The anti-patterns are a menu reachable only by right-click that touch and keyboard users can never open, a menu that renders half off the bottom of the viewport, kebab targets too small to tap reliably, and no way to dismiss the menu without clicking precisely outside it. Give the actions a visible trigger, keyboard and touch parity, and smart positioning so the menu always opens where it can actually be read.
Slite — a real navigation screen from the SaaSUI library.
The details that separate a context menu users trust from a junk drawer
Each decision above is small on its own; a context menu feels like a well-organised toolbox — a calm, predictable place that holds an object’s full range of actions without cluttering the surface or endangering the user — when they are handled together. These are the behaviours mature SaaS products share across their kebab menus, right-click menus, and overflow action lists.
- The one or two most frequent, lowest-risk actions stay visible on the object; the meaningful long tail lives in the overflow menu — the primary action is never buried behind the kebab.
- The menu is scoped to the specific object and its state, offering the actions that actually apply rather than a generic superset dumped on every row.
- Items are grouped into meaningful clusters separated by dividers, ordered by a stable logic that never shuffles between opens, and labelled verb-first with a leading icon.
- Destructive actions sit in their own group at the bottom, set off by a divider and a warning colour, never adjacent to a routine action a slipped click could trigger.
- Irreversible actions are backed by a real safety net — confirmation, a typed-name check for severe cases, or an undo affordance so the common accidental delete is recoverable.
- Actions that do not apply are omitted or clearly disabled with an on-hover reason, and labels mirror current state ("Unarchive", "Remove from favourites") rather than a fixed script.
- The same actions are reachable by a visible kebab (⋮) button, right-click, and full keyboard operation (open, arrow, Escape, focus return), with comfortably tappable targets on touch.
- The menu positions itself to stay on-screen — flipping above the trigger when there is no room below — and advertises keyboard shortcuts inline to teach the faster path.
- Context-menu UX stays distinct from the dropdown select (a form control for picking a value), the bulk-actions toolbar (acting on many selected rows), and the keyboard-shortcuts system (which the menu merely advertises).
Common SaaS context menu mistakes
- The primary action is hidden inside the overflow menu, so the thing users do most often takes two clicks instead of one.
- A single bloated menu lists twenty-plus ungrouped items in no discernible order, and no user reads past the first few.
- Delete sits flush against Duplicate with no divider or warning colour, so a slipped click destroys real work.
- An irreversible action has no confirmation and no undo, turning a mis-tap into a support ticket.
- The menu shows every possible action regardless of state or permission, then fails or is ignored when the user picks one that does not apply.
- Disabled items are dimmed with no explanation, leaving users to click a dead option and wonder why nothing happened.
- The menu is reachable only by right-click, so touch and keyboard users can never open it, and kebab targets are too small to tap reliably.
- The menu renders half off the bottom of the viewport because it never flips above the trigger when space runs out.
Frequently asked questions
When should an action go in the context menu instead of on the surface?
Put an action inline on the object when it is both frequent and low-risk — the one or two things users reach for constantly — and push everything else into the overflow menu. The surface is expensive real estate: every inline button competes with the content and with the other buttons, so it should be reserved for the action that earns permanent visibility. A file’s "Open" or a task’s "Edit" might live inline; rename, duplicate, move, share, export, archive, and delete almost always belong in the menu, because each is used occasionally and showing all of them inline would bury the row. The failure modes are symmetrical: hiding the primary action behind the kebab forces an extra click on the common case, while surfacing the entire long tail inline turns a clean list into a hedge of controls. A useful test is frequency times risk — high-frequency, low-risk earns a surface slot; everything occasional or dangerous goes in the menu, grouped and ordered so it is still fast to reach. Scope the menu to the specific object too, so a row only ever offers the actions that actually apply to it.
How should destructive actions be handled in a context menu?
Separate them, colour them, and back the irreversible ones with a safety net. The core risk is proximity: a delete placed next to a duplicate or a rename means one slipped click can destroy work, so destructive actions should live in their own group at the bottom of the menu, set off by a divider and usually a warning tint, never adjacent to a routine action or in the top muscle-memory slot. Visual separation alone is not enough for anything truly irreversible — pair it with a real confirmation, a typed-name check for the most severe cases (deleting a workspace, removing a member), or, better for the common accidental delete, an undo affordance that lets the user recover in one click after the fact. Respect reversibility as a spectrum: an archive that restores easily can be low-friction, while a permanent purge deserves the strongest guardrail, and the labels should make clear which is which — "Remove" should not quietly mean "permanently destroy". Done right, the destructive group is obvious, deliberate to reach, and forgiving when a mistake slips through.
Should a context menu be reachable by right-click, a kebab button, or both?
Both, because they serve different users and inputs. A visible kebab (⋮) or "more actions" button is essential for discoverability — right-click is invisible to anyone who does not already know to try it, and many users, especially on touch, never will. A right-click context menu on the object is valuable for power users who expect it and want the actions where their cursor already is, so offering it in addition rewards fluency without penalising newcomers. The non-negotiable third route is the keyboard: the menu should open from a focused object, let arrow keys move through items, close on Escape, and return focus to the trigger afterwards, so it is operable without a mouse at all. Touch needs its own consideration since hover and right-click do not exist there — the kebab must be a comfortably tappable target and the items large enough for a thumb. Advertising the relevant keyboard shortcut inline beside a menu item (a greyed "⌘D" next to "Duplicate") is a bonus that teaches the faster path over time. Offer the visible button and right-click and keyboard, and the same actions reach every user however they work.
Study real SaaS context menus and overflow actions in the SaaSUI library
Every decision above is easier to apply when you can see how real products solved it. Browse real kebab (⋮) and "more actions" overflow menus, right-click context menus on rows and canvas objects, grouped and divider-separated action lists, isolated destructive groups with warning colours and confirmations, disabled and contextual states, and inline keyboard-shortcut hints from shipped SaaS applications like Linear, Notion, Airtable, Figma, Google Drive and other polished products in the SaaSUI.Design library, with real screenshots instead of mockups, to study how mature products decide what belongs in the menu, group and order the items, keep destructive actions safe, signal state honestly, and make the menu reachable by mouse, right-click, keyboard, and touch.
Interested in sponsoring SaaSUI.Design? Learn about sponsorship options →