Published: Mar 01, 2011
Universal, Human, Clean
Useful, Fast, Simple
These are design principles, the first three from the Facebook design team and the latter three from Google's UX team. They are good. They are certainly qualities to aspire to. After all, who wouldn't want to create a clean or simple design?
However, I don't think they are great design principles. Great design principles help designers learn more about their design and make critical decisions about what they're building.
In contrast, look at this design principle from the Windows 7 Desktop Design team:
Reduce concepts to increase confidence.
A designer can take their design sketch and ask, "Are we introducing any new concepts? If so, why? Is it necessary?" This speaks directly to the users' experience. Given two alternative design approaches, we can see which one requires fewer concepts for the user to achieve their tasks.
Lately, we've been working with teams to craft great design principles. Each time we succeed, we end up with a list of guiding phrases that help the team make important decisions. Those phrases keep coming up, in idea discussions, sketch reviews, and design critiques.
Each time the phrase comes up, there's a discussion. "What do we consider a concept?" "How can we tell if confidence increased?" Answering questions like that makes each designer smarter. It also establishes a common ground for the team as a whole, giving them a way to suss out the boundaries of the principles — what's in and what's out, to misquote Project Runway's Heidi Klum.
In our research of great user experience design, we found design principles can play a really important role. However, most design principles fell short because they were too motherhood and apple pie — too blue sky.
As we looked at the teams getting the most from their principles, we found these were more detailed, more specific than just one word attributes, like "innovative." They were talking to the very things that would make this release different, better than anything they or their competitors had produced before.
This specificity seems, at first glance, counter-intuitive to the idea of principles — an overarching idea of the right way to design something. However, because they were specific to what the designers were working on at that moment, they played a much bigger role in formulating the look, feel, and experience of the design. That's exactly what you want from principles.
We've captured what we discovered and put them into six tests. If a principle passes every test, it's a great design principle — one that will likely guide the design team to produce designs their users love.
The Windows 7 Desktop Design team spent a lot of time studying the user experience from Microsoft Vista (the previous release). They noted where user frustrations were coming from. Their design principles emerged directly from that research.
Everyone on your team should have a ton of examples at their fingertips about how the current design or your competitor's designs violate each principle. It should be easy to see how, when followed, the principle will make a better experience than what's out there today.
To make this work, everyone on the team needs to have the same background on the research. First-hand experience with the research is the best. If there's still discussion about whether an existing design does or doesn't meet the criteria set forth by the principle, the principle isn't yet clear enough.
It's easy to separate a good design from bad designs. A great principle helps you distinguish a great design from the good designs. While a good design might be ok, it's not great if it doesn't follow the principle.
Take the Windows 7 Desktop principle of UX before knobs and questions. Applying this principle, the designers could look at a new feature and ask questions like "Does this require configuration to get value?" or "Are we asking questions we've already gotten the answer to?" They can eliminate designs that put configuration over a great user experience, even though those designs might have been clean, useful, and simple.
As a rule of thumb, a great principle should make the team reconsider two-thirds of the designs that came before them. It helps the team say "This idea isn't completely baked yet. Keep pushing on it." It becomes the razor between good and great.
The Windows Phone UI team's principle, Celebrate Typography is a direct swipe at the Blackberry and even the iPhone. The designers talk about having an "uncompromising sensitivity to weight, balance, and scale", something their competitors haven't attended to.
Your team should have an easy time understanding how competitors would want to take different principles than what you've adopted. Easy to use is not something that will ever set a competitor apart. However, Focus on polish before new features could set your design apart from a competitor trying to win the hearts and minds of customers through new features, even though their existing platform is buggy and convoluted.
One team discovered their users were overwhelmed by the complexity of the command navigation. Their current design featured every possible action on every possible object. In their next release, they've adopted the principle, Emphasize discovery over completeness. They wanted users to easily discover the most important functions. They planned on removing infrequently used functions.
However, they could imagine a future project where completeness would be more important than discovery. In designing an interface for highly-trained administrators, for example, having easy access to every function would be key to the design's success.
Great principles aren't ever-truisms. They are only useful for right now. By thinking through scenarios of when you'd reverse them later, you help define what it means to follow that principle now.
As you start a new project (or even sub-project), the team should look at the research, the competitors, and the market to see if the principle still applies. It should be one of the first things the team discusses when they launch a new initiative.
It's very likely that different teams, simultaneously working on separate aspects of a release, could have their own principles. For example, in a medical office management system, the appointment calendar team works with different principles than the team working on insurance billing reports. These teams should discuss their principles with each other, to identify any that might apply across both efforts. However, they shouldn't worry if they are working to different principles. After all, their two projects probably have very different measures of success.As projects progress, new principles will emerge and old principles will need to go into storage. Over time, the team can track its maturity by tracking the changes in their principles.
Responding to the overwhelming feedback that their current releases were too buggy, one team adopted Polish over new features as a key principle. Once the first design sketches started appearing, their team discussions quickly focused on the meaning of polish. Does it include non-bug changes? Colors? Fonts? White space?
Principles often start out with just a definition of "we'll know it when we see it." We can easily tell when something is very unpolished or very polished. But soon we need understand the two extremes and identify when we're following the principle and when the design needs more work.
These discussions are healthy for your team, especially if you talk about real designs and sketches. It gives your team a chance to glean a common understanding of your goals. It equalizes the authority, so anyone can say what's been agreed to and what the principle means. This leads to an increased understanding of what good design is across the entire release.
If your team has already tried to put together your own principles, chances are they'll fail many of the tests. As a field, we've done a crappy job of talking about what makes a great principle work.
Don't despair. Start having the conversations. The best principles change as the team's perspectives on design matures. Don't be afraid to let your principles grow into something that will guide your team to create user experiences your customers will thank you for.
How do your principles fare against these tests? Share your experiences on our UIE Brain Sparks Blog.
Read related articles: