Design Principles
Design Principles are a short set of memorable statements, grounded in user research and the organisation's values, that describe the experience a product or service should give people. A team drafts them together and then uses them as a shared yardstick, so that separate projects and disciplines make design decisions that pull in the same direction. The practice is common across design and is described, among others, in Vijay Kumar's '101 Design Methods' (2012), in the IDEO Design Kit and on Service Design Tools under the name Experience Principles.
Facilitation script
- 1
Set the goal and show one good and one weak example of a principle. Review the key research insights and the organisation's values together.
15 min - 2
Silent writing: each person drafts candidate principles on sticky notes, noting the insight behind each.
10 min - 3
Post and cluster the notes, name the clusters and discuss overlaps.
15 min - 4
Narrow down to three or four core principles by merging clusters and removing anything too generic to guide a decision.
15 min - 5
In pairs, write a name and a short statement for each principle, then read them out and refine the wording as a group.
20 min - 6
Test the principles against two or three recent decisions and sharpen any that would not have made a difference.
15 min - 7
Agree who produces the visuals and where the principles will be used and reviewed.
10 min
Tips
A principle earns its place only if it helps choose between two reasonable options, so ask for each draft what it rules out.
Statements such as 'simple' or 'user-friendly' fail that test because no team would aim for the opposite.
Keep the link from each principle to the research visible; it is what lets you defend the principle when a stakeholder challenges it later.
Three or four that people remember beat ten that sit in a slide deck.
Common pitfalls
Writing principles so generic that nobody could disagree with them, which means they never settle a real trade-off
Keeping eight or ten principles to avoid a hard conversation, so nobody remembers them and none is applied
Drafting from the team's preferences and not from research, so the principles collapse the first time a senior stakeholder disagrees
Skipping the test against real decisions, so vague wording is discovered only weeks later in a design review
Treating the workshop as the finish line and never building the principles into briefs and reviews, so they are forgotten within a quarter
Variations
The same set is often called Experience Principles or Experience Pillars when it describes a whole service and not a single product. For a faster run, bring a facilitator's first draft from the research and use the session to challenge, merge and rewrite it. Remotely, cluster on a digital whiteboard and write statements in pairs in breakout rooms. Some teams phrase principles as trade-offs, 'this over that', to make the choice explicit. Revisit the set when new research arrives or when teams report that a principle never gets used.
Where it fits
When to use it
Research is synthesised and the team needs to carry its insights into many design decisions without rereading the report each time
Several teams or agencies work on parts of the same service and their outputs are starting to feel inconsistent
Design reviews keep turning into arguments about taste and you need shared criteria to judge against
A project is moving from discovery into concept work and needs a clear frame for ideation
New people are joining and need to understand quickly what the team is trying to achieve for its users
When not to use it
There is no research yet; principles written from opinion carry no authority, so run interviews and synthesise them first, for example with an Affinity Map
The team needs agreement on scope, goals and success measures for one project; use an Experience Canvas or a project charter instead
You need to choose between specific concepts today; use a decision method such as Dot Voting or an Impact and Effort Matrix, ideally with existing principles as criteria
The organisation already has a principle set that nobody uses; fix how that set is applied before writing a second one
Related methods
Further reading
Frequently asked questions
What is Design Principles?▾
Design Principles are a small set of statements that describe the experience a product or service should give people, based on research and on the organisation's values. Teams use them as shared criteria when generating and judging design options. Service designers often call them Experience Principles or Experience Pillars.
How many design principles should a team have?▾
Three or four core principles is a workable number, because people can hold them in mind during a discussion. If more detail is needed, add discipline-specific principles underneath the core set and keep the top level short.
What makes a good design principle?▾
It is specific enough to help choose between two reasonable options, it traces back to something learned from users, and it is short enough to remember. A quick check is to ask whether a sensible team could choose the opposite. If not, the statement is a platitude and not a principle.
Who should take part in writing design principles?▾
The design or product team that did the research, plus stakeholders from the areas that will have to apply the result. A group of four to ten keeps the writing manageable. Leaving out the teams who are expected to use the principles is the most common reason they are ignored later.
How are design principles used after the workshop?▾
They are added to briefs, used as criteria in design reviews and concept selection, and shown to new team members. Review them when new research comes in. A principle that is never cited in a decision should be rewritten or removed.
Plan your next workshop with AI
Workshop Weaver helps you combine methods like Design Principles into a complete, timed agenda in minutes.
Try it freeMethod descriptions on Workshop Weaver are original content written by our team, based on established facilitation practices. This method was inspired by work from General design practice; Vijay Kumar, '101 Design Methods' (2012), as cited by Service Design Tools.