Before You Redesign the Menu, Test These 4 Things
•
4 min read
Before redesigning your menu, test what is actually broken. Learn how card sorting, tree testing, first click testing, and usability testing help teams redesign navigation with confidence.
Over the years I have seen many design updates and I can say that menu redesigns often begin with the wrong question. A team looks at the navigation, decides it feels crowded or outdated, and starts “improving” labels, spacing, and layout on a hunch.
However, if users still cannot find what they need, still hesitate on what to click next, or still end up in the wrong place, the issue usually goes deeper than the visible design. That is why the first step of any design involving navigation should start with testing.
1. Test whether the grouping makes sense
A menu can look clean and still be built on categories that do not match how users think. This is often where the problem starts. Teams group content based on internal language, product logic, or what feels reasonable from the business side. Users do not arrive with that same mental model. They are simply trying to find the right place quickly.
My usual starting point here is tree testing. It helps establish a baseline and shows whether users can actually find the information in the current structure. Sometimes that first tree test already tells you a lot. Users may expect certain items to live elsewhere, or they may hesitate because a label is unfamiliar or unclear. If participants are trying to find soccer shoes, for example, but the navigation uses the word “cleats,” that mismatch can already point you toward a more useful change.
Once you have that baseline, the next step depends on what the tree test reveals. If the problem is clear enough, I would usually make changes to the structure or wording and then run a second tree test to see whether those changes improve findability. If the first tree test shows that something is off but does not give you enough direction on how people naturally group and label the content, that is where card sorting becomes useful. Card sorting helps you explore potential new groups and wording, especially when the structure is still open to change. It also helps explore better grouping and wording before you test the revised structure again.
2. Test whether users can actually find the right place
Once the grouping from card sorting starts to settle, the next question is simple: can users find what they need in the structure you have created? The menu may feel improved internally, but users still take the wrong path, bounce between similar sections, or choose the second-best destination because the right one was not placed correctly.
The method I trust most here is tree testing. It removes the visual design and focuses on findability. Users get a structure and a task, and you see whether they can reach the correct location.
This is especially useful when a team says things like “the menu is much simpler now” or “the labels are clearer.” Those are good signs, but they are still internal signs. Tree testing shows whether users agree.
⭐ This is also the point where you would like to run a comparison against the baseline you created.
3. Test where users click first when the UI is in place
Once the navigation starts taking shape inside a real design, I want to know whether users know where to begin.
This is a different question from pure findability. At this stage, the issue is not only whether the structure works, but whether the visible entry point (or points) feels obvious enough in context. That is where first click testing becomes very useful.
A first click tells you a lot. If users consistently start in the wrong place, the rest of the journey is already problematic. That first move often reveals whether the menu label is doing its job, whether the hierarchy is helping, and whether the design is supporting the architecture instead of getting in the way.
This is especially useful for header navigation, account menus, sidebars, and any area where users need a clear starting point before they can complete a task.
4. Test whether the menu is even the real problem
Sometimes users struggle with navigation, but the menu is not actually the main issue. The friction may appear later in the journey. The labels may be fine, but the destination page may be unclear. The path may start well, but the next step may break the user’s confidence.
This is why I would always include some form of usability testing before locking in a menu redesign. Once users move through the real interface, you can see whether the navigation is the problem, or whether it is simply the first place where a larger experience issue becomes visible.
This is also where recordings are really useful. They help you spot hesitation, backtracking, second-guessing. Watching the small pauses and participants thinking out loud can help you spot the underlying issues in the user experience.
A simple way to sequence the research
Not every project needs a long research plan or not every one of these steps will be relevant to your case, but most menu redesigns benefit from a basic sequence.
If the structure is still open, start with card sorting. If the structure is mostly defined, move to tree testing. If the UI is already taking shape, add first click testing. If you want to understand how the menu behaves inside the full journey, run usability testing.
That sequence does not need to be rigid, but it helps teams avoid jumping straight into visual changes before they understand what is actually broken.
Redesign the menu after you understand the problem
Sometimes the issue is grouping. Sometimes it is naming. Sometimes it is findability. Sometimes it is a broader usability problem that only happens to show up around navigation first. Testing helps you separate those cases before design work gets locked into the wrong fix. Once you know what is actually failing, redesign becomes much more confident, and much more useful.
