by Julie Zhuo and first appearing on fastcodedesign.com

FACEBOOK’S JULIE ZHUO ON THE BIGGEST TRAPS DESIGNERS FALL INTO—AND HOW TO AVOID THEM.

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 mistakes behind their backs, in the hopes that by bullying them into the spotlight, they’ll have a harder time slinking around, wasting our time, and steering us toward 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 out the door in three months, or making a larger product change and getting a bigger positive result out the door in six months, most teams I’ve seen pick the former, which necessarily constrains the exploration that designers will do. It takes Yoda-like patience to pick the latter. What can you design and build in three 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 and just looking to grow it). But if you want people to behave or think in a substantially different way, you probably need to alter the model of how your product works. Always looking for the quick win isn’t going to lead to the kind of broad, creative design exploration that yields truly innovative solutions.

“DON’T FALL IN LOVE WITH YOUR FIRST IDEA.”

Risk: If you’ve got a reasonable thing going, you probably don’t want to upend it. You might wind 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 people are afraid to even raise the idea of exploring bold new design directions. 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 design 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 additional time spent refining the concept is like rearranging deck chairs on the Titanic. Too often, I see designers get so enamored with a deep dive 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.

“GOOD EXECUTION ISN’T THE FULL PICTURE.”

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 considerations, the content, and 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 their lifestyle. So it stands to reason that designers want their stuff to not just be functional, but also to 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.

“WAY MORE PEOPLE IN THE WORLD ARE OFFENDED BY NOT BEING ABLE TO FIND A FEATURE THAN THEY ARE BY BAD KERNING.”

“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.” Way more people in the world are offended by not being able to find a feature than they are by bad kerning. Above all, consider that as much as we want to design something we ourselves love, it’s more important to design something that our target audience loves. (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 extends to not-very-frequently-used screens, like a superbly organized settings page, or a classy error pane. However, designers often neglect to pay as much attention to the things that get people into the experience in the first place.

“IT’S SIMPLY NOT TRUE IN THIS DAY AND AGE THAT IF YOU BUILD IT, THEY WILL COME.”

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 probably more critical to its success than dozens of other things you could optimize within that feature. Or what about making it easy for someone to switch from using a competitor to using your app, like building in simple data transfer? 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.