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.
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.
