If you don’t have them already, you and your team need to draft and use Experience Principles. You might be thinking, “hey, that’s a familiar phrase, those are the same as ‘Design’ Principles, right?”
They’re also not Creative Principles, Strategic Guidelines, or Design Rules. Many of these labels get used interchangeably (along with a few others). But I am pedantic about the label Experience Principle for a reason.
Let’s start with the idea of a “principle.” A principle is a statement that describes the foundation for reasoning. In our context, it should be a directive for the product team.
Experience Principles describe our values, and inform our business strategy or product decisions. Experience Principles are based on research. These principles incorporate what the team has learned about users’ needs and wants. They also reflect an understanding of the business needs and brand positioning.
Design principles are often described or defined the same way, so what gives? An Experience Principle is exactly what it sounds like. It’s about how the user experiences the product you are creating. It is more than the design.
Developers, business stakeholders, product managers, project managers, designers… every role makes decisions that impact the product. Even when a designer may write the Experience Principles, they are for every person on the team. Experience Principles might codify design concepts. But great Principles might also encompass ideas like performance, access and user needs.
The product experience is the responsibility of every person on the team. That shared responsibility should be reflected in how the principles are described.
These are several years old but still worth reviewing. Each set of Principles below is clear and instructive of the product team’s intent.
Words matter. When your team has agreed to core Principles, they give you a way to focus your efforts. You can use your Experience Principles to reduce misunderstandings. You will have a set of values to come back to when weighing decisions.
For example, if you are the Office 2007 team – There is a clear theme about getting out of the user’s way. (See Principles 1-3.) So when a suggested “quick” solution adds a visually distracting element to the experience, and a “hard” solution does not… the Experience Principle should guide you in that decision. (The decision should be the less distracting, but harder solution.)
There is also a focus on pragmatism in the Office 2007 principles. In direct contrast, a Google Calendar principle states: “Fast, visually appealing and joyous to use.” There is both a recognition of their brand and users within that disparity.
Microsoft is not known as a “fun” or “playful” brand. And the majority of their paying Office customers are businesses. Their principles appropriately reflect that audience.
But Google began adding “fun” into their experience early on. Google featured their first Doodle in August 1998, 2 weeks before the company became a legal corporation. (It was for Burning Man, by the way.)
That brand value is carried forward into the Google Calendar Experience Principles. Including moments like the one below.
The Google Calendar team decided illustrations associated with specific event keywords was valuable. That likely means something else didn’t get done, and that’s okay.
Well-crafted Experience Principles act as a decision making framework for the whole team.
Digital products are ingrained in our lives now: Facebook, Twitter, Uber, Microsoft Office, G Suite… the list goes on. You need to put your users first or you won’t succeed. And yet, if you ignore the business’ needs, the business (and the product) will fail.
Both groups must inform your Experience Principles. There is a balance with Experience Principles that can help prevent moving too far one direction or another.
For example, Experience Guidelines are helpful when involving external stakeholders. They unify the team to justify a decision, one way or another. You may have marketing, advertising, or sales peers that have specific quantitative goals. It can be helpful to to remind these folks of your team’s qualitative goals as well. Experience Principles state those objectives for you.
Keep it simple:
A quick note – your Experience Principles may sound like ‘UX truisms.’ For example, Microsoft’s Principles many sound like generic ‘good design rules.’ That’s okay. Principles aren’t meant to be unique or clever. They’re meant to guide the team, and they need to be realistic or they become useless.
Windows 7 was a critically acclaimed improvement over Windows XP. And although it had a few hiccups to get there, Office 2007 did create more efficient workspaces.
Side note: The initial Office 2007 caught a large number of existing users off with the update to a more visual UI. But new users found it easier to learn and adopt, and it did not take long for most users to relearn.
The best time to write and adopt your Experience Principles are at the start of the product cycle. Or, at the start of major new initiative (such as a rebrand, redesign or rebuild of the tech stack/back end).
But it’s never too late to reflect on your product, your users and your business. You can introduce the concept with a new feature set and ask your team to try the experiment with you. It will take some effort to remember to reference those Principles throughout the process. Good luck!