Grouping and Naming
How you group things is how users understand the product.
Grouping is a statement about how you want users to understand the product. Get it wrong, and every future search makes them guess your categories again.
What you'll run into:
- Users can't find features, yet you think the classification is perfectly clear
- New features have nowhere to go, so you keep opening new groups
- Navigation items need an explanatory caption to make sense
The most common mistake is grouping by the system's internal structure. Names like "Data Management" and "Business Config" make sense to developers because they mirror the code's modules—but users have no such map. They're thinking "I want to see how much money came in this month."
What to group by
| Basis | When it fits | Risk |
|---|---|---|
| Task | The default for most cases | Tasks need to stay stable, or the structure gets rebuilt on redesign |
| Object | The product has clear core entities, like projects and customers | Users who don't think in entities find it roundabout |
| Role | Different roles use completely non-overlapping features | Multi-role users switch constantly, which is annoying |
| Frequency | As a secondary sort, not a primary grouping | Frequency changes, and differs between users |
| System module | Almost never | You're asking users to understand your implementation details |
Grouping by task carries a bonus: the task list is your feature scope. A feature that fits no task can probably be cut. And validation is cheap: find five people, give them one task ("check last month's revenue"), and watch where they click first. If more than three click wrong, that group should change.
Four rules for naming
- Use the words users say, not the words you use internally. If your team calls it a "ticket" and users call it a "problem," call it a problem.
- One thing, one name across the whole site. "New" in the sidebar, "Add" in the empty state, and "Create" in the dialog is the same action wearing three names.
- Names should say what's inside, not what type it is. "My projects" beats "Project management" because you can predict what you'll find inside.
- Avoid "More," "Other," and "Tools." These words admit the classification failed. If something truly won't fit, it doesn't belong at this level.
| Don't use | Use instead | Why |
|---|---|---|
| Data Center | My Records | Users don't see themselves as managing data |
| Business Config | Rule Settings | "Business" is an internal term |
| Workbench | Needs My Action | The former doesn't say what's inside |
| More | Split into existing groups | A junk drawer only gets fuller |
After naming, read the whole sidebar top to bottom and imagine a first-time user seeing it: can they say what's inside every entry within five seconds? If one entry makes you pause, that's the item to fix in the next pass.
How to verify
Three cheap validation methods; doing them settles most questions about your grouping:
- Run a reverse test with five people. Give them a task ("check last month's revenue") and watch where they click first. If more than three click wrong, change the group.
- Let users group the features themselves. Write the features on cards and let users sort them—more reliable than your guess. This is the card sorting method. card-sorting-wiki
- Try adding three future features. If they don't fit and you have to open a new group, the current logic isn't abstract enough or you're slicing on the wrong dimension.