Mega Menus: Spool vs. Nielsen | Perficient Digital

Today UIE’s Jared Spool posted an article criticizing mega menus. I’ve confidently designed a couple of these based on Jakob Nielsen’s assessment that Mega Drop-Down Navigation Menus Work Well. I’m not convinced that “mega menus aren’t evil, just troubled” based on Spool’s article.

My primary issue with the article is that five out of the six “epic forces battling your mega menus” simply don’t apply only to mega menus. The first point – that there’s no visual clue that mega menus exist – is not inherent in mega menu design. Mega menus can have the same affordances as a standard menu. Options can be styled like buttons, and I disagree with the assertion that “no de facto standard has emerged to help designers communicate when mega menus are hiding behind navigation links”.  A down-pointing arrow next to each horizontal menu item or a right-pointing arrow next to a vertical menu item is a pretty standard affordance (see or This affordance implies a hidden secondary menu; no need to have anything additional identifying the menu as a “mega menu”.

The second, third and fourth “epic forces” are not at all unique to mega menus, but rather are issues with any secondary navigation that is hidden by default.  These relate to users finding trigger words, understanding category names, and having to move their mouse before they know where they want to go. These are all good critiques of any secondary menu that is not visible by default, but do not only apply to mega menus. I’d grant that mega menus tend to make you want to have a very basic and high-level primary menu where the category names might be vague, but that can be avoided by a carefully designed and tested information architecture.

The fifth “epic force” is the only one that really applies solely to mega menus – that they eat up a lot of real estate that might cover something the user wants. This only happens if the user accidentally hovers on the menu item though, and can easily be managed by implementing a proper mouseover delay (Nielsen recommends 0.5 seconds). 6/26 update: See Neo Insight’s excellent article for additional timing detailsTherefore, I don’t find this to be a very compelling point.

I do agree with force #6 in general – hover events don’t work on hover-less devices, so that’s an issue – though again, it does not just apply to mega menus. Spending a lot of time developing content in hover events is problematic because of mobile devices, so if you expect your site to be frequently used in mobile settings, you might want to think twice about designing mega menus. You’ll either have to set the menu to display on finger tap, or be sure to design a landing page for each category that lists all the secondary menu options.

Spool’s report that their clients saw sustained drops in revenue and KPIs after rolling out mega menus does give pause. I would weigh it more considerably if I knew how many clients this happened to and how they specifically designed their menus and overall site. For now, I continue to concur with Nielsen, that used appropriately, mega menus have several advantages, including:

  • They show everything at a glance.
  • They support grouping and the ability to visually emphasize relationships among items, including varied font attributes.
  • They allow for the use of icons and pictures for illustration.

3 responses to “Mega Menus: Spool vs. Nielsen”

  1. Ivo Bosma says:

    Hello Molly,

    just wanted to let you know that I agree with you on your thoughts. Very well written article, so thanks for that!

  2. […] lays out his six arguments against mega menus, most of which are in fact not unique to mega menus at all and I don’t find them inherently problematic (not that germane here; scroll to the […]

  3. Steve says:

    I agree about the perceived affordance an arrow brings to a menu item but there is an issue when the menu becomes large as a mega menu. To prevent accidental hovers (so content is not covered and possible loading issues depending on the size of the menu) designers may force a delay before a mega menu opens. In which case, a delayed response may cause some users to think nothing will happen and the arrow is meaningless. Many users still do not understand subtle cues such as arrows referring to a sub menu. If the feedback (the menu opening) is delayed the problem for them is exacerbated. This is not true with smaller menus as they don’t generally block out the content and load instantly.

    If there is no delay you can run into extreme annoyance such as Yahoo when they released their “quick preview” on their last design and giant menus were popping up and loading all over the place. It lasted about a month before being changed to a click.

    Also, as you put it when arguing against the fourth epic force: “I’d grant that mega menus tend to make you want to have a very basic and high-level primary menu where the category names might be vague, but that can be avoided by a carefully designed and tested information architecture.”

    That’s true but the temptation is there and that is the balancing act I suppose.

Leave a Reply