A principle is a tie-breaker you agree on before the argument starts. Five designers, five different files, nobody booking a meeting, and the decisions still line up — that is the job.
Most published principles fail at that job because nothing in them is contestable. "Be delightful." "Put users first." Nobody was arguing the other side. A principle earns its place when it names what you are giving up — speed over configurability, consistency over local cleverness, fewer options over raw power.
The five below are the common ones, and they are a reasonable starting stock. The set that actually works is the one your team writes down after the third time the same disagreement costs a week.
- Principles of Product Design — article
- 5 Design Principles From The World's Most Product-Centric Companies — article
- The Principles of Design | FREE COURSE — video
User-Centered Design
User-centred design means any decision can be traced back to something a real person did, rather than to what the room preferred. That is the whole of it, and it is hard because the room is present and the user is not.
In practice: watch five people attempt the task before anyone argues about the layout. Recruit people who have the problem, not colleagues who are being kind. Weight what they did above what they said they would do.
The failure mode has a script. Somebody says "I use this product too" and swaps their own fluency for evidence — of course you found the control, you placed it. The other failure is taking requests literally. Users are excellent at reporting where it hurts and unreliable at prescribing the cure.
- User Centered Design (UCD) — article
- What is user-centred design (UCD)? — video
Functionality over Polish
Make it do the job, then make it good. A gorgeous screen bolted to a flow nobody needs is a more expensive mistake than a plain one, because the team will defend it for longer.
This is about sequence, not permission to ship something shabby. "Functional" still includes everything users read as quality: loading states, error messages that say what to do next, data that does not vanish, a form that keeps what you typed when it fails. That is function. Gradient work and bespoke illustration are polish.
The inverse failure is just as real. Teams say "we'll polish it later" for two years, and in a crowded category visual credibility is part of whether anyone trusts you with their data. Put a date on later.
Consistency & Coherence
Consistency is cheap memory. Learn a pattern once and you know it everywhere — the same word for the same concept, the same place for the same action, destructive things always recoverable by confirmation or undo.
Coherence is the stricter half: the parts have to add up to one product, so things that behave differently must look different. Two buttons that look identical and do opposite things are perfectly consistent and completely wrong.
A design system is how this survives twenty people and four years — shared components, named tokens, one spacing scale. It holds only when conforming is the cheaper path: the component is already in the file you open, and a new pattern gets agreed in days rather than sprints.
Consistency used as a veto is the failure worth naming. A bad pattern repeated everywhere is not a virtue — fix it in the system rather than exempting one screen and quietly starting a second.
Collaboration by Design
Show the work while it is still ugly enough to change. Disappear for three weeks, come back with a finished flow, and you have guaranteed two things: an engineer will find the constraint that breaks it, and you will defend it anyway, because three weeks.
Bring an engineer into the sketching — they know which of your two layouts is a day and which is a month, and that is a design input, not an interruption. Bring the product manager in while the scope is still movable. Support and sales hear the same complaint often enough to recite it, and they know which one is costing money. Write the decision down where the next person will find it, or you will make it again.
Run critique on unfinished work with a real question attached. "Does this ordering match how you'd do it in the spreadsheet?" beats "thoughts?", which returns opinions about the colour.
Iteration over Perfection
Ship a version that can teach you something, then improve it with what it teaches. The alternative is spending a quarter perfecting a guess.
Iteration only works when the release is wired to learn. Decide in advance what result would make you carry on and what would make you stop, and check the events are instrumented before it ships — a launch you cannot measure is a launch you will argue about. A/B testing is one instrument among several, and the traffic it needs depends on how often the thing you are measuring happens and how small a change you want to catch. When the numbers will not get there, watch five people use it instead.
Two abuses. Shipping something genuinely broken and calling it iterative — trust does not iterate back. And iterating forever because nobody ever declared a version finished.