Group commands by use situation, not by development module

What it is

People open a menu asking where the thing they are doing now lives, not which package owns the code. Task-based menu grouping puts commands under the activity in progress: revising, laying out, exporting, collaborating. Grouping by development module carves the same commands along SyncService, Renderer, Billing. That is clean in a repo and, in a menu bar, pins an org chart to the user’s face. That the menu bar should hold a complete inventory is a different claim. This entry is only how that inventory is sliced.

Why it happens

Finding a command is search with an expected label: people start with a task name and look along the top bar for the closest word. Situation names (File, Edit, View, Share) share vocabulary with the task, so the first hop often lands. Module names are implementation boundaries; overlap with task names is accidental. “Send this passage to a colleague” may be split across networking, permissions, and the editor—three menus, each holding half a command. The cost of a wrong group is not one extra click. After a wrong first hop into a top-level item, people conclude the function does not exist and leave for Settings or a search engine. Situations overlap too (print feels like File and like View), so the grouping criterion is how people name the act when they start it, not which class owns the method.

Studying it

Use card sorting: commands on cards, no module names, target users pile them as they would look them up, then compare against the current menu cuts. Or run find tasks: a spoken task, record which top-level item is hit first.

Independent variables: grouping basis (situation / object / development module), whether top-level names come from user vocabulary, whether a command can only be finished across modules. Dependent variables: rate of first-hit on the correct top-level item, abandonment after a wrong first hop, completion time, the sense that something “is in the wrong place.”

Developers as participants will judge module grouping reasonable; that measures the implementation model, not the use model. Sort results also depend on having seen the old menu—long-term users redraw the current structure from memory. Use people who have not seen the product, or rewrite commands as task sentences before sorting.

Where it stops holding

A tiny tool with one top-level item degenerates grouping into ordering. Experts remember coordinates (“third menu, second from the bottom”); a wrong group is a tax on efficiency, not always a discovery failure. Plug-ins dump third-party commands into Tools or a private top-level item and break situation grouping—that is discoverability versus extensibility. Object-first apps (select a shape, then change it) sometimes fit object grouping better than situation grouping, if object types are visible to the user.

Applying it

• Name top-level items and separators with the target users’ task words, not package, service, or team names.
• When one command straddles two situations, put it in the group from which people more often start it, and point or duplicate from the other—do not leave half in each.
• Before adding a command, ask which kind of thing users would call it, then file it; never hang it under the menu owned by the team that built it.
• Verify: write ten real tasks, hide the UI except the top-level words, and ask people who did not build the product which item they would hit. Tasks whose first hop is wrong are sliced by module, not situation. Overlay the menu tree on the package diagram: if they coincide, the cut has usually drifted.

Related

• Within the group: K2.09.2 Deep menu nesting makes infrequent commands undiscoverable · K2.09.3 Command names must match terms used elsewhere in the UI · K2.09.4 Situational items should change availability, not disappear
• Adjacent: K2.03 Menu Bar · E5.15 Number of navigation items · T1.04 Terminology consistency and glossaries
• Search terms: task-based grouping · menu organization · card sorting