# A small guide to kebab menus Date: 2026-07-22 Mood: Sweating the small stuff Reading time: 6 min Canonical: https://alejandromarco.com/notes/small-guide-kebab-menus How we refined Vidext’s action menus through research, real product actions, and a small bench of concrete design variants. How a fast-growing product turned one small dropdown into a useful design exercise. At Vidext, we are rethinking the experience of learning, and the new product is growing quickly. That momentum is exciting: new capabilities become real, teams start using them, and the product gets more useful every week. It also creates small places that need a second pass once the first version has done its job. Our action menus were one of those places. Modules and courses had gained new actions over time, and the **···** dropdown had quietly become the place where many of them met. The menu worked, but every row had the same weight. Working with content, organizing it, publishing it, and removing it all looked like equivalent decisions. This was not a project about making the dropdown prettier. It was a chance to pause, understand the actions we had accumulated, and give them a clearer structure before the product grew around them. ![The original Vidext module action menu, with six ungrouped text actions: Details, Edit title, Edit in chat, Preview, Add to courses, and Archive.](/notes/kebab-menus/current-module-menu.png) _The starting point: the actions were there, but their relationship was not visible._ ## Start with the actions, not the styling We began with an inventory. Which actions exist for a module and for a course? Which ones do people use most often? Which ones belong to the same kind of task? Which ones only appear in a particular state? The current menu was useful because it gave us the real material to work with. It also forced a question before grouping anything: does every action belong here? **Details** repeated what opening the card already did, so it disappears from the sketches. For the actions that remained, **Edit in chat** and **Preview** are about working with the content. **Edit title** and **Add to courses** are about organizing it. **Publish** and **Archive** change its lifecycle. The list was not random, but its structure was still invisible. We then compared our questions with guidance from Apple, NN/g, GitHub Primer, Shopify Polaris, and Atlassian. The sources differed in detail, but they pointed in a similar direction: contextual menus should stay focused, related actions should remain together, frequent actions should be easier to find, and destructive actions need a predictable treatment. Research gave us hypotheses, not answers. We thought the menu needed groups. We thought the most frequent actions should come first. We thought icons might help people scan. We also knew we needed to see those ideas with our real labels and components before deciding. ## Turn the hypotheses into sketches Menus are surprisingly difficult to discuss in the abstract. “This needs more hierarchy” can mean several things, and “icons will make it easier to scan” sounds convincing until every action needs a symbol. So we built a small design bench. It kept the current menu as the baseline, placed several module variants beside it, repeated the structure for courses, and tried five symbols for **Release course**. Everything used the actual typography, spacing, colors, and components from the product. [![A design bench comparing four module action-menu variants, course menus with and without icons, and five candidate icons for Release course.](/notes/kebab-menus/action-menu-sketches.png)](/notes/kebab-menus/action-menu-sketches.png) _The design bench made each decision visible: grouping, icons, destructive styling, course structure, and the release symbol. Open the image to inspect it at full size._ The first variant was the current flat menu. The next added only separators. Another added icons to every group. A fourth kept icons for the frequent actions and used color only for the destructive one. Below them, the course menu let us check whether the same language could work on another object instead of solving one dropdown in isolation. The comparison changed the conversation. We were no longer discussing whether icons are good in general. We could ask which variant made **Preview** easier to find, whether **Add to courses** had an icon people could understand, or whether a rocket really communicated release. Some ideas became stronger when we saw them. Others disappeared quickly. ### Let the separators explain the structure The most useful sketch was also the simplest: groups, with no icons. ![A sketch of the Vidext module menu grouped with separators and no icons. Edit in chat and Preview form the first group, Edit title and Add to courses the second, and Publish and Archive the third.](/notes/kebab-menus/separators-only.png) _One variable at a time: groups and separators, with no help from icons or color._ The separators already turned one long list into smaller decisions: work with the content, organize it, then change its lifecycle. This is a tiny example of [Information Architecture](/notes/first-note). The information did not change, but its relationships became easier to understand. A separator is not decoration. It is a quiet piece of structure. ### Use icons where they earn their place The icon sketches were useful because they showed the limit of the rule. Chat and play have familiar shapes, so they helped **Edit in chat** and **Preview**. **Add to courses** did not have one obvious symbol. Adding an icon there made the row busier without making it clearer. The release symbol created another useful discussion. The rocket felt decorative. In a learning product, the checkmark was already occupied: it means completed. We chose the upward arrow because it could represent the same lifecycle action for publishing a module and releasing a course. ## Take the best parts forward The final module menu did not come from choosing one sketch unchanged. We combined the strongest parts of several variants. ![Two final Vidext module menus. Both show Edit in chat and Preview with icons, then Edit title and Add to courses without icons, then Archive in red. The second menu also shows Publish with an upward-arrow icon.](/notes/kebab-menus/module-menu-states.png) _The final module variants combine the useful parts: clear groups, selective icons, a stable release symbol, and Archive isolated at the end._ The first group contains the actions used to work with a module, with icons where recognition is immediate. The editing group stays text-only. **Archive** sits alone at the bottom and is the only red action, so position and color carry the warning together. The menu also responds to state. **Publish** appears when that action is available and disappears when it is not, while the rest of the groups keep their order. The frame remains familiar even when the object changes. We applied the same decisions to courses rather than inventing a second pattern. ![Two final Vidext course menus. The draft course includes Assign teams, Add modules, and Release course with icons, followed by Edit title and Delete. The released course removes Release course while preserving the other groups and the red Delete action.](/notes/kebab-menus/course-menu-states.png) _The course menu uses the same language. Release appears only while it applies; the groups remain stable, and Delete keeps a predictable ending._ This is where the state work mattered. A menu is not a static list attached to a card; it belongs to an object that can be unpublished, published, releasable, or released. The relevant lifecycle action can change without making the rest of the menu feel unfamiliar. The sketches also stayed close to implementation. We used the grouping and icon capabilities our menu component already had. For the missing destructive treatment, we added tone="destructive" as a reusable menu-item variant instead of styling these two menus as exceptions. ## The version I want to remember When I open another **···** menu, these are the questions I want to ask: - **Inventory.** What are the real actions in this menu? - **Frequency.** Which ones do people use most often? - **Groups.** Which actions naturally belong together? - **Structure.** Can separators reveal it before icons do? - **Icons.** Does every symbol make its action easier to recognize? - **Destructive actions.** Are they isolated and predictable? - **State.** What changes when the object changes? - **Reality check.** Have I compared the real variants side by side? The final menus are still small. That is the point. The work is visible as less hesitation, not more interface. When a product is moving quickly, it is easy to treat this kind of refinement as polish for later. I think it is part of building the product. Revisiting a small surface lets us absorb what we have learned, make the next feature easier to place, and stop yesterday’s decisions from becoming tomorrow’s structure. Vidext will keep growing, so these menus will probably change again. They now have a clearer logic to grow from — and we have a process for returning to them when they need another pass. Sources I am building from - Apple. [*Menus*](https://developer.apple.com/design/human-interface-guidelines/menus) and [*Context menus*](https://developer.apple.com/design/human-interface-guidelines/context-menus), Human Interface Guidelines. - Kate Kaplan. [*Designing Effective Contextual Menus: 10 Guidelines*](https://www.nngroup.com/articles/contextual-menus-guidelines/), Nielsen Norman Group, 2025. - Anna Kaley. [*Contextual Menus: Delivering Relevant Tools for Tasks*](https://www.nngroup.com/articles/contextual-menus/), Nielsen Norman Group, 2019. - GitHub Primer. [*ActionList guidelines*](https://primer.style/product/components/action-list/guidelines/) and [*Action menu*](https://primer.github.io/design/components/action-menu/). - Shopify Polaris. [*Action list*](https://polaris-react.shopify.com/components/lists/action-list) and [*Common actions*](https://polaris-react.shopify.com/patterns/common-actions). - Atlassian Design System. [*Dropdown menu*](https://atlassian.design/components/dropdown-menu/).