I am doing an audit of a website and there are areas where the label in the navigation goes to the same page as a the link in it's dropdown like the "Banking" going to same page as "Mission and Roles".

Is it ok that they have different names?

An example of this is Dribbble. Navigation labels got to same page as a link in the dropdown. If you shrink the page to mobile size the Nav label as a trigger to open the dropdown. https://dribbble.com/marketplace

Go Pro goes to same link as For Professionals.

Design Files goes to same page as Discover

Does it make more sense to place all pages of a section in a dropdown and the nav label on desktop has no behavior other than opening the dropdown?

Banking (no action on click only opens dropdownenter image description here)

  • Mission and Roles
  • Leadership
  • Regulations

2 Answers 2


Simply put, in and of itself, it's okay for the nav header and one of the sub-nav links to go to the same page, (or not—ought to be determined by user testing). But...

...the matter is more complex than that.

Looking at https://dribbble.com/ nav headers it appears the design principle they are following is:

a) Link all navigation headers, and in that link, either

b) Go to a page that is a category overview, or

c) Go to a feature page within that category or top filter with the category's browse functionality.


So, if following the same design principle in the provided example of


  1. Mission and Roles
  2. Leadership
  3. Regulation

...since each of the subcategories are distinctive and equal, clicks on BANKING go to a category overview page.

Generally consistency is important. So either link all category headers, or none.

Then, if they're linked, consider the nature of the category and it's subcategories and choose the header link with what makes sense accordingly, and is supported by user testing.

  • Thank you. That makes sense and clears up the linking ot the same page under different name.
    – keano12
    Commented Dec 13, 2022 at 0:09

Generally it is a bad inconsistency to have two different labels that link to the same content. Especially with the demise of color-coding of visited links, users can’t tell that the links go to the same content, so may click on both, only to waste their time.

This also applies to labels for menus (i.e., “nav labels” like “Banking”) and their menu items (“Mission and Roles”, etc.). The users have no way of anticipating that Banking also goes to Mission and Roles, and so if they can’t find what they’re looking for with the individual menu items, they may click on Banking in a wasted attempt to get the content they need.

Compounding the problem is that the menu label (“Banking”) will often be a poor label for the content. When a user clicks on Banking, they’d expect general information about Banking, not some detail about it, like Mission and Roles. In cases where the menu label links to a “Overview” or “Introduction” or “Summary” page, that is less of a problem since then it does link to general information, but that still doesn’t solve the inconsistency –users may still think clicking the menu label (“Banking”) leads to separate content than the menu item (“Introduction”).

Really the only good thing the menu label should link to is a short page listing links to each menu item, each with a short description of what they mean. This useful if the user can’t decide which menu item to choose or otherwise is unsure what they mean. It’s also useful because users can’t always tell if the labels in the top bar are dropdown menu labels or just links (including an arrow for menus would help). A user may slew and click the menu label before they get a chance to react to the dropdown menu unfurling. Linking the menu label to a page of links of the menu items allows users to recover in one click, rather than starting over with the menu. However, this still means that many users that click the menu label are being unnecessarily delayed in getting the content they need.

So the real solution is the menu label only opens the dropdown. While it’s a common convention, menus should not open on hover alone.

  • For one thing as described above, it causes user errors where the user doesn’t know there’s a menu and clicks on the menu label only to, at best, end up on intermediary content (a page of links) or at worst, an arbitrary page that’s unlikely what they wanted. User may not realize there even is other content because they didn't notice the menu.

  • It can also cause errors as the user aims to click a link on the page below the menu bar but accidentally slews over the menu label cause the menu to drop down and a random menu item to be selected.

  • It can cause annoying and distracting animation as the mouse slews over the page, or a little random shift of the mouse can make a menu occlude content on the page the user is trying to read.

  • it doesn’t work with touch interfaces.

  • Counterintuitively, it’s slower to select menu items with a hover-to-open than a click-to-open menu, especially after you’ve made an effort to address some of the problems above by including a delay in opening the menu on hover. See Chaparro BS, Minnaert G, & Phipps C, (2000) Limitations of Using Mouse-over with Menu Item Selection.

If you want one-click access to some default content, while also supporting a menu of supplemental content, use a split button.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.