Design Principles

Humans are most comfortable with things that behave the way we expect. Other people, animals, objects, software. When someone or something behaves consistently with our expectations we feel like we have a good relationship with it. To that end designed elements should look like how they behave. Form follows function. In practice this means that someone should be able to predict how an interface element will behave merely by looking at it. If it looks like a button it should act like a button. Don’t get cute with the basics of interaction…keep your creativity for higher order concerns.

Give the browser some solid rules and hints, then let it make the right decisions for the people that visit it, based on their device, connection quality and capabilities. This is how they will get a genuinely great user experience, rather than a fragmented, broken one.

No matter how you’ve planned, people often behave in unexpected ways. Don’t dismiss the behavior, accept that the behavior you’re seeing is the behavior you’ve designed for…whether or not it was intentional. If it was something you didn’t plan for, your probably need to focus more on the core interactions more…make them as tight as possible to focus the user’s efforts.

Screen elements should not appear consistent with each other unless they behave consistently with each other. Elements that behave the same should look the same. But it is just as important for unlike elements to appear unlike (be inconsistent) as it is for like elements to appear consistent. In an effort to be consistent novice designers often obscure important differences by using the same visual treatment (often to re-use code) when different visual treatment is appropriate.

“Don’t repeat yourself” (DRY) is a principle of software development aimed at reducing repetition of information which is likely to change, replacing it with abstractions that are less likely to change, or using data normalization which avoids redundancy in the first place.

The DRY principle is stated as “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system”. […] When the DRY principle is applied successfully, a modification of any single element of a system does not require a change in other logically unrelated elements. Additionally, elements that are logically related all change predictably and uniformly, and are thus kept in sync.

You should be deliberate about absolutely everything in your design. This means whitespace, alignment, size, spacing, colour, shadows. Everything. If someone points at a random part of your design you should have an explanation for why it looks that way. If you do not do this your design will not feel coherent.

If you are new to design you can use this rule as a prompt to learn more about what you are not deliberate about yet.

There is your product and then there is the experience someone has using your product. It’s easy to see the difference from afar, but to the person using your product they are one in the same. Every interaction matters and becomes part of the product experience. The original iPod is a canonical example: the iPod experience included everything from picking up and feeling the heft of the device to finding music with the scroll wheel to syncing with your computer to purchasing music from the iTunes store. All of those interactions taken together made up the total product experience and ultimately what the customer was buying.

There are many reasons for this principle but my favourite is that designing for a minority makes things better for everyone.

Examples:

• Subtitles don’t just help deaf people; they allow people to watch a video in a loud cafe
• Plain language isn’t just easier to read for people with low literacy; experts find it easier to read too
• Large radio buttons don’t just help people with motor impairments; everyone finds them easier to click

In user interface design and software design, the principle of least astonishment (POLA), also known as principle of least surprise, proposes that a component of a system should behave in a way that most users will expect it to behave, and therefore not astonish or surprise users. The following is a corollary of the principle: “If a necessary feature has a high astonishment factor, it may be necessary to redesign the feature.”

From Jeremy Keith’s post “Robustness and Least Power”:

Be conservative in what you send, be liberal in what you accept.

Even though the robustness principle was formulated for packet-switching, I see it at work in all sorts of disciplines, including design. A good example is in best practices for designing forms:

Every field you ask users to fill out requires some effort. The more effort is needed to fill out a form, the less likely users will complete the form. That’s why the foundational rule of form design is shorter is better — get rid of all inessential fields.

In other words, be conservative in the number of form fields you send to users. But then, when it comes to users filling in those fields:

It’s very common for a few variations of an answer to a question to be possible; for example, when a form asks users to provide information about their state, and a user responds by typing their state’s abbreviation instead of the full name (for example, CA instead of California). The form should accept both formats, and it’s the developer job to convert the data into a consistent format.

In other words, be liberal in what you accept from users.

I find the robustness principle to be an immensely powerful way of figuring out how to approach many design problems.

Show only what is necessary on each screen. If people are making a choice, show enough information to allow them the choice, then dive into details on a subsequent screen. Avoid the tendency to over-explain or show everything all at once. When possible, defer decisions to subsequent screens by progressively disclosing information as necessary. This will keep your interactions more clear.

If a trade-off needs to be made, always put user needs above all.

[…] User needs come before the needs of web page authors, which come before the needs of user agent implementors, which come before the needs of specification writers, which come before theoretical purity.

From Jeremy Keith’s post “Robustness and Least Power”:

When it comes to figuring out what specific tools or technologies to use, there’s an equally useful principle: the rule of least power:

Choose the least powerful language suitable for a given purpose.

On the face of it, this sounds counter-intuitive; why forego a powerful technology in favour of something less powerful?

Well, power comes with a price. Powerful technologies tend to be more complex, which means they can be trickier to use and trickier to swap out later.

Take the front-end stack, for example: HTML, CSS, and JavaScript. HTML and CSS are declarative, so you don’t get as much precise control as you get with an imperative language like JavaScript. But JavaScript comes with a steeper learning curve and a stricter error-handling model than HTML or CSS.

As a general rule, it’s always worth asking if you can accomplish something with a less powerful technology:

In the web front-end stack — HTML, CSS, JS, and ARIA — if you can solve a problem with a simpler solution lower in the stack, you should. It’s less fragile, more foolproof, and just works.

• Instead of using JavaScript to do animation, see if you can do it in CSS instead.
• Instead of using JavaScript to do simple client-side form validation, try to use HTML input types and attributes like required.
• Instead of using ARIA to give a certain role value to a div or span, try to use a more suitable HTML element instead.

It sounds a lot like the KISS principle: Keep It Simple, Stupid. But whereas the KISS principle can be applied within a specific technology—like keeping your CSS manageable—the rule of least power is all about [evaluating technology](evaluating technology); choosing the most appropriate technology for the task at hand.

Ubiquity; universality; accessibility—however you want to label it, it’s what lies at the heart of the World Wide Web. It’s the idea that anyone should be able to access a resource, regardless of technical or personal constraints.

• Start with user needs.
• Build an under-engineered solution—one that might not offer you much control, but that works for everyone.
• Layer on a more over-engineered solution—one that might not work for everyone, but that offers you more control.

Users have endless opinions about your product, but they are not the designer. You are.

When people tell you something’s wrong or doesn’t work for them, they are almost always right. When they tell you exactly what they think is wrong and how to fix it, they are almost always wrong.

This quote from Neil Gaiman is right on…people are very aware when a problem exists but don’t know how to solve (if they knew how to solve it they wouldn’t have the problem!) So don’t dismiss problems quickly…make sure that you dig deeper to understand the underlying issue, it might only seem unrelated. A designer who blindly followers users will quickly fall prey to their inability to accurately self-report. Do not resent them for this…this is the nature of the user.