Tips on How to Craft Design Principles

Design principles act as a moral compass for your product design.

On a couple of occasions now, I've been tasked with crafting design principles that will help guide product design decisions. I've researched what others have done high and low, and ultimately found what works for one company doesn't necessarily apply to another. Here are some helpful tips on how to go about creating yours.

I will note that calling them design principles is admittedly a bit of a misnomer. Design principles implies that they are owned and relate only to the designers, whereas they should be relevant to the entire organization. Designers, product managers, developers, support staff, QA – should all be accountable to these principles. For the sake of brevity, however, I will stick to how this is relevant to product designers.

Why Bother with Design Principles?

Luke Wroblewski does well in explaining the importance of design principles:

“Design principles are the guiding light for any software application. They define and communicate the key characteristics of the product to a wide variety of stakeholders including clients, colleagues, and team members. Design principles articulate the fundamental goals that all decisions can be measured against and thereby keep the pieces of a project moving toward an integrated whole.” Luke Wroblewski - Developing Design Principles

Whether you're prioritizing work, or designing interactions for a feature, you can refer back to your principles to help you make better decisions. If what you are working on, or proposing to work on, falls outside of the scope of your principles, then perhaps you should reevaluate your priorities. Designing new features that stay true to your principles will also help you to build a more cohesive product as each individual feature is striving to meet the same set of goals.

If you can't communicate your design decisions in terms that are relevant to your principles, you might be steering your project off course. It will help reduce “it just looks better” excuses. When you have principles to refer back to, reasons like that just don't fly.

Keep the List Short

It's easy to get carried away when you're crafting your list, but it's vital to keep it short and concise. I like keeping it to a list of around five. Anything more than that and you start giving yourself too much leeway with how you should design your product. If a decision is relevant to only 1 out of 12 principles, as an example, then how valuable is it? Too much room allows for too much compromise.

Keeping the list short also makes them a lot easier to remember, making them more meaningful. It's easier for your team to get behind something they can remember. If you have to open up a PowerPoint (bleh!) presentation every time you want to remind yourself of them, it likely won't work.

Have Conversations with the Product Champions

If you yourself are not the champion of the product (yet — as ultimately you should be), talk to the people who are. Through these discussions you should be able to get a sense of the short and long term visions for the product. This will help you piece together principles that will allow you and your team to carry out the vision.

While you can expect to get valuable feedback here, you shouldn't expect to get nice words or phrases handed on a platter. It will take some refinement to boil down this feedback into small consumable chunks that will make sense to the entire organization.

Stay True to Your Company Culture and Goals

At bitHound, we just ran through this exercise and settled on principles such as actionable and insightful. On their own, these words might not mean enough to an outsider of the organization. But that's ok — they won't mean anything without the context of our culture and our product. If you do things right and stay true to your principles, they should be evident to your users.

I chose the word crafting instead of picking or choosing as you really need to identify and develop principles that are relevant to your company. Don't just select a bunch from a list because they sound good. You should probably expect the list to evolve over time. As your business and users' needs change, so might your principles. Don't stick with principles that no longer make any sense to your organization.

When is the right time?

Now. I don't think there is such thing as too early. They may fluctuate more when you're product and company are young, but defining your principles early will help to keep you on track in a stage where it's easy to take your product in too many, and perhaps conflicting, directions.

Remind your team at the right times

You don't want to make these feel like a corporate initiative that people lose interest in the moment you queue up your presentation. At bitHound we put it on the front page of our wiki. We open up an Evernote note with them listed when we're working on sprint planning. We remind each other during product discussions. Instead of a boring presentation, make it a workshop that allows for open feedback an discussion. People will take ownership when they have an opportunity to provide their own input.

Good designers are already likely working with some principles in mind, even if they have not yet formalized them into simple words or phrases. The exercise of making them succinct will help you better communicate your design intentions to your team, your managers and ultimately improve your product's user experience.

Have you crafted design principles for your team? What has worked best for you?

Other resources

Here are some resources you might find handy when creating your list:

• Luke Wroblewski - Developing Design Principles — Luke has several great articles on the topic, including this one, which includes some examples.
• Government Digital Service Design Principles (UK) — Here's an example of a robust set of principles. A bit lengthy, but it might give you some ideas.
• Android Design Principles — Android, yes Android, has published their UX team's design principles. It's well done.

Stock photos from Unsplash.