The 5 Most Common Design Mistakes
There’s no learning without mistakes. And I’ve done the following (as well as seen the following done) too many times to count. Luckily, there’s this thing called the “Internet” and this medium called an “article” that lets us point at and talk about these mistakes behind their backs, in the hopes that by bullying them into the spotlight, it’ll be harder for them to slink around, wasting our time and steering us towards no-good solutions.
1. Over-constraining the design exploration
There are two main reasons why design explorations become over-constrained:
Time: few things are more tempting to a product team than the promise of bringing about a positive change quickly. Between making a smaller product change and getting a small positive result in three months, or making a larger product change and getting a bigger positive result out the door in six, most teams I’ve seen pick the former, which necessarily constrains the exploration that designers will do. It takes a Yoda’s worth of patience to pick the latter. What can you design and build in 3 months? Small, iterative improvements. Which—don’t get me wrong—can be very positive up to a certain point (and is almost certainly the right thing to do if you’re happy with your product/feature as is and just looking to grow it). But if you want people to behave or think in a substantially different way than they do now, you probably need to alter the model of how your product works, and always looking for the quick win isn’t going to lead to the kind of broad, creative design exploration that yields those kinds of solutions.
Risk: if you’ve got a reasonable thing going, it seems crazy and maybe even foolish to upend it with a change to the system. You might end up with something less effective than what you have now. And even if you do end up with something better, your users might hate it. There’s a huge tax in changing or introducing new things. Often, this fear of risk means even the very idea of exploring bold new design directions never gets brought up. Everyone just assumes the answer will be no, because that’s the natural state of things. Resist this temptation. Have the conversation—is the risk-to-reward tradeoff worth it to explore broader systems or model changes? The answer might be “no” most of the time, but it should be “yes” more frequently than it is now, when this conversation happens all too rarely.
2. Refining too early
This is a classic designer’s mistake: you start off exploring a big, ambiguous problem. You have a cool concept in your head. You sketch it out. Looks sweet! Excitement builds! You start working on a high-fidelity mock or prototype. So sick! The design questions start piling up. Should you go with black or white as the background? Maybe the buttons should be round. Oh! This would be a great use case for that new nav idea you’ve been thinking about! Before you know it, 80% of the design time has been on refining one idea instead of exploring multiple ideas.
Maybe your first idea is always the best idea. Maybe you’re that person who touches things and then they turn to gold. I wouldn’t bet on it. You’re better off not falling in love with your first idea and instead doing broader explorations on a number of different systems, models, and approaches when you’re in the exploration stage. At this point, specific interaction and visual details only matter in that they need to be clear enough to support the story you’re trying to tell with your concept so that others can understand it and help you critique it. Any addition time spent refining the concept is like rearranging deck chairs on the Titanic. Too often, I see designers getting so enamored with deep-diving on one idea that they don’t leave themselves any room to explore other very different—and potentially much better—ideas.
3. Mistaking a good execution for a good product
Scenario: a talented designer comes in with a polished prototype of beautifully laid out content containing professional photography of smiling, attractive people and super interesting content. There’s a tight and compelling narrative about how someone will use this product. Everyone is so wowed by the stunning nature of the presentation that not a lot of questions are asked. When something looks good, you sometimes trust that it is good.
Alas, a good design execution isn’t the full picture, and will generally leave out a lot of the necessary ingredients required for the product to actually work well. For instance, the design execution may be awesome when you use high-res photos and well-formatted, rich content, but what if most of your actual content is low-quality meme photos? Or you’ve designed a bunch of features to give suggestions based on different cuts of data, but there’s not enough information in your system to support these features? Or you’re relying on people to have state-of-the-art hardware to support your slick animations, but it turns out a huge portion of them are running Gingerbread on 2010-spec phones? A good execution shouldn’t sell a design in of itself—there also needs to be deep discussion and understanding of the technical, content, or other constraints that might get in the way of the idea working in an idealized way.
4. Overvaluing simplicity and style at the cost of clarity
It’s well understood that designers have a great appreciation for aesthetics, which extends beyond the job into the lifestyle, permeating into home decor, fashion, and purchasing decisions. So it stands to reason that designers want their stuff to not just be functional, but also look and feel good. (And often beyond even that—to look and feel unique, so as to create for people a novel sensation of wonder and awe.) Unfortunately, it happens all too often that this desire gets taken too far, where in the name of aesthetics or style, usability for the app’s target audience gets compromised.
“Target audience” is important here because it sets the context for how to evaluate the success of the design. If you’re making an app for only other designers, then by all means, lose the labels. Make it gesture-based. Not a problem if your mom can’t figure out how to use it, as long as other designers don’t have any trouble. But if you’re making an app with the idea that lots of people in the world will use it, consider that being super explicit with labels and text, using tried-and-true interaction patterns, and resorting to familiar iconography is going to make people’s lives easier, even if it adds more clutter or feels less “innovative”. Consider that way more people in the world are more offended by not being able to find a feature than by bad kerning. Above all, consider that as much as we want to design something we ourselves love, it’s more important whether or not the target audience we’re designing for loves it. (Otherwise, your work might get included in a post about perplexing design decisions.)
5. Undervaluing the experience outside of the container
Every designer I know takes incredibly seriously the responsibility of crafting the experience within the container for which they are responsible, whether it’s an app, product, or website. Often, this attention to detail extend even to not-very-frequently-used screens, like a superbly organized settings page, or a classy error pane. However, designers often neglect paying as much attention to the things that get people into the experience in the first place. For example, one of the most powerful levers to remind people of the value of a mobile app is through notifications, but there are far fewer designers who get super jazzed about figuring out the perfect system of rules to send out useful-yet-not-annoying notifications compared to those who are excited about, say, figuring out the visual system for an app. Another example is determining the best entry point for a new feature, an often contentious and therefore challenging endeavor, but nonetheless probably more critical to its success than dozens of other things you could optimize within that feature. Or what about removing barriers for someone to switch from using a competitor to using your app, like building in easy transfer of data? And let’s not forget about marketing—how are people going to hear about this new feature or app? How should they think about it or talk about it? It’s simply not true in this day and age that if you build it, they will come. It’s important to consider not just what the experience is inside the container, but how people will get there. (And of course, whether or not you even need a container in the first place. Sometimes the best design is invisible.)
