Skip to content
This repository has been archived by the owner. It is now read-only.
Switch branches/tags
Go to file
Cannot retrieve contributors at this time
permalink layout title
Defining design principles


A typical design principle has two components:

  1. A title or descriptive label. The title may be a single word, such as "authentic," or a brief, memorable imperative statement, such as “Earn trust, don’t assume it.”

  2. One to three sentences of supporting insights based on research.

Optionally, if you’re sharing a design principle outside the main team, you can also add some examples of how the principle has influenced the product.

For example, from the BBC’s Global Experience Language Design Philosophy:

Image of Gel Example

The title is:


The explanation is:

We value the familiarity and trust placed in us. We acknowledge the BBC's heritage of iconic design and broadcasting history with subtle references.

Another example, this time from IBM

Example of IBM site for Design Principles

The title is:

Get support

The explanation is:

Support users in the ways they want to get help. Expand their knowledge and encourage them to share it.

What makes a good set of design principles?

Design principles are most useful when they are:


The words "design principles" in some cases can mean “universal truths” or “industry-wide rules of thumb.” Those are legitimate interpretations. On a project-by-project basis, however, the most useful principles for decision-making are the ones that are limited in scope. Those principles address the aspects of the product that could differentiate your product from competitors.

One way to test whether your principles are sufficiently specific is to ask yourself whether you could, in another context, aim for the opposite. We don’t know any designers who aim to make their work unusable. "Be usable" is a general goal rather than a differentiator, which makes it a bad design principle. But consider IBM’s “Get Support” principle. One can easily imagine an application encouraging solitary contemplation rather than social knowledge sharing.


Helpful design principles bring your priorities into clearer view. They don’t diffuse effort across multiple conflicting priorities. They don’t offer conflicting goals or values. A good set of design principles wouldn’t emphasize social engagement and solitary contemplation at the same time. Both principles are perfectly good ones, of course — but not for the same project.

You can quickly evaluate your set of principles by using them in a short, directed brainstorming session. Does using them help you focus discussion? Or do you end up distracted by ideas that don’t address the important questions. In creative work, we usually generate far more ideas than we can or should pursue. Design principles help teams say no, fast. Remember, they are filters.


On the one hand, products should fit smoothly into the lives of their users. On the other hand, products are always rooted in the organizations making them*.* To help designers balance these priorities, sets of design principles should represent insights from user research and engage the history and culture of the sponsoring organization. For example, the BBC’s principles ask designers to honor the organization’s "heritage of iconic design" while, for users, providing a “timeline of Britain.”

Sadly, most organizations don’t have a well-documented heritage of iconic design to draw from. However, over time, teams develop their own unique terms for what they value or dislike — words like "Googly" or “wandery-squanderness.” Grounded design principles often reference these internal terms.

Principles grounded in the lives of users often begin the same way: with words or concepts that come up again and again in research. It’s a good sanity check to verify what you’ve found with "desk research" — checking them against more intensive studies from academia or industry research.

If you can’t justify how your principles link back to empirical user research or internal organizational culture, they’re probably not grounded.

Open and evocative

As designer Stephen P Anderson writes, "Open like the sky," not “We value the color blue.” Design principles are not technical requirements or style guides. The more literal the principle, the less useful it will be for evaluating many different kinds of ideas, and the less useful for generating new ideas. What happens when you apply a proposed principle to different parts of your product? If your principle seems completely irrelevant, just as the color blue would be to information architecture, you probably shouldn’t include it in the final set.

Built together

Designers tend to lead design principle creation, for understandable reasons. However, in order to serve as a common reference point, principles need support from an entire team and potentially across and within organizations. The best way to get that support is to include representatives of stakeholder groups in creating them. Small design teams are rarely successful in trying to impose fully formed principles on outsiders. Building principles together leads to principles that feel like they belong to everyone, not just an elite team. They also help avoid overly-literal or limited principles that are only relevant to a single discipline.