The hamburger menu pattern has gotten a lot of bad press in the design community over the past few months. Most of the negative attention it’s garnering relates to usability issues like lower discoverability, information not being glancable, and that it clashes with other navigation patterns. Worst of all, it allows for complacence, leading to a sloppy information architecture.

For me though, it brings to light a different issue entirely: it makes scaling in apps and adding features too easy. Need a to add a new navigation six months down the line? Easy, stick it in the hamburger menu. It acts as an easy way to scale an app without compromising the overall look and feel.

Jawbone menu

Hamburger menu on the Jawbone app

Building software with scalability in mind seems like a logical choice for most companies. I would argue however, that software should be built for its current purpose, without scalability in mind. It seems counterintuitive, but it’s the right thing to do. It means that adding features down the line will need to be a careful process of consideration rather than just something that’s tacked on.

We’re at a time when apps and software are becoming more and more focused. Successful companies that previously took the kitchen sink approach have done a u-turn and are now decoupling features to create entirely separate experiences. Foursquare has separated its “checking in” function to Swarm. Facebook created Messages (and many other apps), Path recently released Talk.

Maybe that feature you want to add six months down the line won’t fit into your focused, not-easily-scalable design. But more importantly—maybe it shouldn’t. Design for what you have now, and make it the best user experience possible.

Design for what you have now, and make it the best user experience possible

Further reading: Why and How to Avoid Hamburger Menus.


Illustration of overloaded motorcycle courtesy of Shutterstock.

Article No. 1 123 | October 24, 2013
Article No. 952 | February 6, 2013
Article No. 1 267 | July 3, 2014


Good article Jonathan, pretty informative. But, in enterprise context, wondering what should be the UX essentials for successful adption within the organization. User-friendly, contextual? what else? Thoughts?



Great article. Too often products are designed as a great big pile of features. To the people that use them, they are not. Plan carefully and often, revise, redesign and execute with discipline. Thanks. 

Cheers man!

It's a nice read Jonathan, you almost nailed it but I was slightly disappointed reading the 3rd para about 'Scalability', I understand what you meant by being current and make tactical decision while adding features later on. That again means you have to keep your design scalable because most products and development these days happen in Agile/MVP model so you cannot keep chanign your design at every release or making drastic iterations.I think one of the key challenges for us (Designers) while laying the IA for an app is being able to keep the design scalable as well as better affordance of menu and actions.

You're right that most projects these days are fast changing and agile. This doesn't mean that you should take shortcuts and easy work-arounds for having a good, clear iA. 

It's a nice read Jonathan, you almost nailed it but I was slightly disappointed reading the 3rd para about 'Scalability', I understand what you meant by being current and make tactical decision while adding features later on. That again means you have to keep your design scalable because most products and development these days happen in Agile/MVP model so you cannot keep chanign your design at every release or making drastic iterations.I think one of the key challenges for us (Designers) while laying the IA for an app is being able to keep the design scalable as well as better affordance of menu and actions.

nice article jonathan, but i have a few issues with your argument.

I worked at a compnay that grew very reapidly and kept adding features to the service to the point where the architecture couldn't adequately cater to all the features (Foursquare was also very guilty of this). And so we updated the archiecture and refined the product by removing features.

So I agree that as the app market matures, applications are getting more focused. But to use the current trend in decoupling features to create new apps to bolster your argument of designing only for current needs doesn't add up for me.

Foursquare's Swarm has been a disaster - people hate it and coudn't understand why they needed two apps. Foursquare has been quilty more than most of featrue creep and creating secondary app was not the answer - cutting features was. 

And while Facebook's messenger app makes sense as s stand alone app (it's competing against other stand alone messenger servcies) I can't see how this example applies to most other services.

I'm not sure about how successful Path has been, but I would be very wary of this decoupling trend - what's good for facebook is not necessarily good for your company. 

Oh and while i'm here I might as well weigh in on the hamburger issue ;)

While I can see that in some cases it's an easy way our for lazy architects to hide all their features - the hamburger menu is not the problem. It works very well if its appleid coherently because...

1. it gives the user a simple mental model of the service. 

2. the 80-20 rules applies to the home screen - the home screen accomodates the majority of the user's needs. in which case, nesting the other content in a single menu (that maybe gets used 20% of the time) makes perfect sense.


You're right that decoupling isn't always the way to go and can't be applied to every situation. I think the Foursquare/Swarm example is interesting though. I personally never cared about checking in and only used it for tips. Maybe Smarm will die a slow death now, allowing Foursquare to focus on its new core. I think it's a fine faith for an app that was getting so bloated.

In some cases the Hamburger menu makes total sense. Spotify for example. Without being able to hide the lists somewhere the app would be a total mess. I was just using the menu to help me describe the problem.

Cheers for the thoughtful comment!Jonathan

Certainly agree with a lot of this. Often worrying about what 'might' come next results in the creation of lots of unecessary features and functionality that developers think might be useful in the future. We have to remember that our applications are built to solve a problem right now....therefore we should focus on features that directly contribute to the core purpose of a web application today. If things change over time then the interface may have to adapt but trying to plan for these changes only encourages bad practice as we try to second guess what might be needed for something we don't know about yet. 

I say worry about what you can control today and you'll produce a far better UX than if you're worrying about what 'might' be needed in the future.

Exactly :)

To me, the most valuable message of this article is that we should be consciously deciding how scalable to make our designs and not just assuming they need to be as scalable as possible. It's easy to get stuck thinking that we should always be designing as scalable as possible. But as you've outlined, there may be situations that call for a more restricted system. Thanks Jonathan.

Hey Stephen, cheers for reading.Yes it does seem like a lot of companies get stuck wondering and worrying about scaling.The main point I wanted to make was that a products user experience should not be sacrificed to make it more scalable for later expansion. Sure sometimes you need to plan for a feature that you know is coming up, but it doesn't mean the current users should have to get a comprimised experience.Cheers,Jonathan


I like and I agree with the radical title of your article.  Also I see several fundamental reasons for bad UX:

1. Bad planning: It is often way more easier to build a new app than change design for a single gear in dual clutch gearbox. Software is often built without fully understanding the full scope. Lets do something quick and add everything later is the main cause of bad UX.

2. Incomplete business requirements: Even business people are so happy to tell you what screens and fields and  buttons and underlying workflows they want to see. And it's way more easy to discuss the color of a button than actual business situation, problems and business targets, so that you could take your time and design a software that addresses those.

3. Design made by Engineers: Very often UX design is made by the development team. The problem is that technical people approach from a different angle. So there is no surprise that you get very technically oriented software that brings to the surface all possible tech internals that normally should be hidden from the end user whenever possible.

Today community blames Hamburger, but the problem exists here since Xerox Alto. And Hamburger is not the cause, but the victim of what is nearly as old as the first GUI. So rather than blaming Hamburger I think we need to focus on understanding business problems and design software that addresses them first of all.


Hey Aidas,

You're absolutely right. I was just using the hamburger as a sort of anchor to make my point, it's not supposed to be the focus.Incomplete business requirements are always a killer!

I disagree.

While your point about building an app's UI for the intended current features of the app makes sense on one hand, it fails miserably on the other. Yes, feature-creep can kill the UX of an app, so yes, we should avoid that. But to blame the innocent "hamburger menu icon" or anything else for this is plain silly.

Two examples that argue against your...argument.

First, many product owners need to be able to add future content sections should a major reorganization or new entity come into existence. Local governments face this often, as do other large organizations. Being able to easily add or rearrange a few content sections in the "offcanvas menu" makes the IT cost of this organizational change minimal. Should we go with a text-string-length-based menu, designed only to work with the existing section labels, any change could not only be costly, but could force a dramatic re-think of the menu design pattern, very possibly creating big usability problems for users.

Second, I've created a common UI for a government agency for small web apps, so that whenever there is a need for a new app -- just this week they suddenly needed a simple web form app for a particular reason -- we can just slap the UI on the app, make a few customizations, and voila! We have a new app that shares a common UI experience with the other apps we create and customers use. Building a unique menu design pattern for each app would be not only very costly, but it is completely unnecessary. And, it would actually make usability worse, not better.

Yes, when one is creating a beautiful bespoke consumer-based app I can see that a custom menu that avoids the "hamburger icon" and the "offscreen menu" might be a plus. However, I would argue that ditching a commonly understood pattern, and one that offers some clear benefits, for the simple sake of doing something different is not necessarily a smart move.

Yes, this pattern may have some issues, but so do all of them, especially on a small screen.

Hey Chris,First of all, thanks for your comment. You're right, sometimes the "ignore scalability" argument is simply invalid. There are of course two sides to this story, I just wanted to focus on one. The hamburger menu in particular is just a jumping off point and wasn't intended to be the focus of the piece.I too worked for a government agency and did in fact build a very scalable UI. In certain cases it makes total sense. University websites for example also have to be very flexible. Hell I even think the hamburger menu in Spotify's mobile app makes total sense.What I was really trying to get at was the fact that a lot of companies use this as an easy way out. A way to avoid the responsibility of making hard decisions. Thanks again for reading,


I completely agree about the whole avoiding hard decisions thing. Sadly, in the real world of starved budgets, few resources, unrealistic deadlines, poor management, and an utter lack of understanding -- all far more common than those "unicorn" workplaces that build slick stuff with buckets of VC money -- the "easy way out" is often the only choice if anything is actually going to be shipped. There are sooo many apps I'd like to get my fingers into that are being developed at my current workplace, but all the above dictate -- at least so far -- that I only get to be involved in a few. So, without others like myself, well, the "easy way out" becomes the "only way forward," however sad that is. At least with commonly recognized UI patterns -- however ill fitting at times -- there is some semblance of standardization.

Ultimately, though, I don't think the "hamburger icon" and its associated "offscreen menu" pattern are any more guilty of fomenting feature creep or similar UX-degrading sins than any past patterns. The "mega menu," for example, first appearing -- what, maybe a decade ago? -- is just as big an offender. So is the much older "sidebar nav" (which is basically the offscreen menu), that could go on forever. Or the "flyout menu" animation that made people create the most horrifyingly wide and deep (and redundant and poorly labeled and organized) taxonomies imaginable; this was almost criminal.

My point is that whenever a new pattern comes along that offers the possibility of scalability, it will be used as often to ruin the UX as to enhance it. Why? Because it's easy, and that, more than anything else, is always going to be the most common arbiter of what design pattern to use for a UI.

Then I guess we're in agreement! I might have to consider writing a follow-up some time based on your arguments.