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 OfficeDepot.com or Walmart.com). 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 details. Therefore, 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.
