Adding features is easy when you design with scalability in mind. But is that really a good thing?
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.
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 who 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 just released Talk.
Maybe that feature you want to add 6 months down the line won’t fit into your focussed, not-easily-scalable design. But more importantly — maybe it shouldn’t. Don’t worry about designing yourself into a corner. Design for what you have now, and make it the best user experience possible.
UPDATE 19.08.14: This post has been featured on UX Mag and here’s what twitter had to say:
Tweets about “http://uxmag.com/articles/want-the-best-user-experience-make-it-harder-to-add-features …”