Design Principles

Explore a compilation of principles crafted by experts that shape my approach to web design and development

Appearance follows behavior
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.

Published in Principles of User Interface Design by Joshua Porter
Be the browser’s mentor, not its micromanager
Give the browser some solid rules and hints, then let it make the right decisions for the people that visit it.

Let the browser 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.

Published in Be the browser’s mentor, not its micromanager by Andy Bell
Consistency matters
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.

Published in Principles of User Interface Design by Joshua Porter
Design dictates behavior
The behavior you’re seeing is the behavior you’ve designed for.

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.

Published in Principles of Product Design by Joshua Porter
Don't repeat yourself (DRY)
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.

Published in The Pragmatic Programmer by Andy Hunt, Dave Thomas
The experience is the product
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 and 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.

Published in Principles of Product Design by Joshua Porter
Good design works for everyone
Designing for a minority makes things better for everyone.
  • 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
Published in 4 design principles I use every day to avoid bad UX and create products that work for everyone by Adam Silver
Principle of least surprise
In interface design, always do the least surprising thing.

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.

Progressive disclosure
Show only what is necessary on each 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.

Published in Principles of User Interface Design by Joshua Porter
The robustness principle
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.

Rule of least power
Choose the least powerful language suitable for a given purpose.

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.

Ubiquity, then consistency
It’s the idea that anyone should be able to access a resource, regardless of technical or personal constraints.

It’s an admirable goal, and what’s even more admirable is that the web succeeds in this goal! But sometimes something’s gotta give, and that something is control.

[…] I feel like I’ve painted a divisive picture, like you have to make a choice between ubiquity or consistency. But the rather wonderful truth is that, on the web, you can have your cake and eat it.

  • 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.
Published in Ubiquity, then consistency by Jeremy Keith
Users are not product designers
A designer who blindly follows users will quickly fall prey to their inability to accurately self-report.

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.

Published in Principles of Product Design by Joshua Porter