Design thinking
How to write design principles that actually work
:quality(80))
Most projects start with a conversation about what to build. Fewer start with a conversation about what it should feel like to use. Design principles are a way to have that second conversation early — before the decisions get made by default.
Done well, they give a team a shared language. They make it easier to choose between two good options, push back on a direction that feels off, and check at the end whether you actually built what you set out to build. Done badly, they are a list of adjectives on a wall that nobody looks at.
The difference is usually in how they are made.
What design principles actually are
A design principle is a short, clear statement that describes the experience a user should have with your product. Not what the product does, but what it feels like to use it.
They are different from brand values, though related. Brand values describe what a company stands for. Design principles translate that into something a designer or developer can act on. "We are transparent" is a value. "We show users exactly what will happen before they commit to it" is closer to a principle.
A good set usually has five to seven principles. They should be specific enough to actually guide a decision, but broad enough to apply across the whole product. The test is whether two people on the team would use the same principle to make the same choice. If one person reads it one way and another reads it differently, it needs more work.
Good principles share a few qualities: they are distinctive to this product, not generic enough to apply to anything; they are written from the user's perspective, not the company's; and they sit in a useful middle ground — not so vague they mean nothing, not so specific they only apply to one screen.
Three angles to work from
When I help teams develop design principles, I find it useful to approach the product from three directions.
The business angle
What is this product trying to achieve? What does success look like? What are the values of the organisation behind it, and how do those translate into an experience? A useful exercise here is the elevator pitch: can you describe the purpose of the product in a single sentence? If not, the principles will be vague too.
The user angle
This is the most important one. What is the user trying to do? What do they feel at different points in the journey — confident, uncertain, rushed, curious? What would they say if they described using this product to a friend? Principles written from the user's point of view tend to be more actionable than those written from the inside out.
The shape angle
What does the principle actually look like in the product? Can you sketch it? A principle like "make it easy" is hard to visualise. A principle like "never make the user do something twice" is something you can test against a real interface. Looking at principles through the lens of how they manifest in the design often reveals whether they are concrete enough to be useful.
:quality(80))
Principles need to live somewhere
Writing good principles is only half the work. The other half is making sure they are actually used.
For a small project with one team, that might just mean a printed sheet on the wall. For a larger product with multiple teams or external partners, something more deliberate is needed — a shared reference document, a style guide, or a proper design system where the principles inform every component.
Apple gave a public example of this when they presented their design philosophy at WWDC years ago. Whether or not every statement was a design principle in the strict sense, the intent was clear: this is how we think about our products, and we want everyone building on our platform to understand that.
Principles are not a goal in themselves. They are a means to an end — the end being a product that is coherent, considered, and genuinely good to use. The best ones you barely notice after a while, because the decisions they guide start to feel obvious.