A product team's design principles sit on a wiki page, yet design reviews still end in opinion battles; how would you make the principles actually decide things?
answer
- principles unused are platitudes
- put them in the review template
- cite the principle, not the preference
- decisions become examples
- retire what is never cited
basics
~20 sBuild the principles into the review process: proposals state which principle they serve or trade off, reviewers cite principles rather than preferences, decisions are recorded as examples, and principles that never get cited are rewritten or retired.
solid answer
~40 sPrinciples that live only on a wiki are not failing because of wording alone; they are missing from the moments where decisions happen. I would first check the set itself - platitudes and unranked conflicts get ignored for good reason. Then I would wire them into the process: the design review template asks each proposal which principle it serves and which it trades off, reviewers are expected to **cite a principle** when they object, and the facilitator redirects 'I don't like it' into 'which principle does this break?'. Settled decisions are recorded as **examples** linked from each principle. Finally, I would track which principles are cited: one never cited in months gets rewritten or retired, and leadership has to use them visibly too, or the team will not.
go deeper
Recall that principles only matter if they are cited when decisions are made, and that an objection should name the principle it relies on.
Explain the practices that put principles into reviews - template fields, citation norms, decision records, example libraries - and why platitudes must be fixed first.
Diagnose why a real team ignores its principles, fix the set and the process, and keep it alive by tracking citations and retiring principles that are never used.
Make leadership part of the mechanism: sign-off at the level that could override, visible use by senior people, and recorded overrides that feed revisions.
## Diagnosing why principles are ignored Principles that exist but do not influence decisions usually fail for one or more of these reasons: - **They are platitudes** - 'simple', 'delightful' - so citing them never settles anything. - **They conflict without a ranking** - both sides of a debate cite a principle, and the stalemate returns to opinion. - **They are absent from the moment of decision** - nobody opens the wiki during a review. - **Leadership overrides them silently** - the team learns that the real rule is whoever is most senior. - **They have no examples** - people do not know how to apply them to a concrete screen. The fix depends on which causes apply, so the first step is to find out, for example by reviewing the last dozen design decisions and asking which of them any principle influenced. ## Fixing the set before fixing the process If the principles are platitudes or conflict without order, embedding them in reviews will only spread useless citations. Before anything else: 1. Test each principle against real recent disagreements and rewrite or drop those that decide none. 2. Add a ranking where principles can conflict. 3. Attach at least one real example decision to each. ## Wiring principles into reviews The goal is that a principle is cited at the exact moment a disagreement happens. | Practice | What it looks like in a pharmacy refill app team | |---|---| | **Review template field** | Each proposal states: serves 'confirm the medicine', trades off 'refill in seconds' | | **Citation norm** | An objection names the principle it relies on, not just a preference | | **Facilitator redirect** | 'I would not do that' becomes 'which principle does this conflict with?' | | **Decision record** | Outcome, principles cited and reasoning are written down | | **Example library** | Each principle page links the decisions it settled | The **citation norm** changes the tone of a review: arguments become checkable, because anyone can ask whether the cited principle really applies, and a preference that cannot be tied to any principle is visibly just a preference - which is allowed, but carries less weight. ## Keeping the set alive Principles decay without maintenance. Practical habits: - **Track citations** loosely - which principles are cited in decision records over a quarter. - **Retire or rewrite** a principle that has not been cited in months; unused, it is a platitude in practice. - **Revisit the ranking** when decisions keep going against it or when research contradicts it. - **Onboard with examples**, not just the list, so new team members learn how the principles bend. ## Leadership behaviour The strongest signal is what senior people do. If a product lead overrules a principle-backed decision without comment, the team learns the principles are decoration. If the lead cites principles, accepts being overruled by them, and records overrides with a reason, the team follows. That is why the principles need sign-off from the level of leadership that could otherwise override them. ## A first-quarter plan For a team starting from an ignored wiki page, a realistic sequence is: 1. **Audit** the last dozen decisions and note which, if any, a principle influenced. 2. **Repair** the set with the team: rewrite platitudes, add a ranking, attach examples. 3. **Get sign-off** from the product lead who would otherwise be the one overriding. 4. **Change the template** for design reviews and brief facilitators on the citation norm. 5. **Review after a quarter**: which principles were cited, which were not, and what that says about the set. ## What success looks like There is no single metric, but useful signals include: - fewer reviews ending without a decision; - decision records that cite principles by name; - new team members applying principles correctly in their first proposals; - disagreements shifting from 'I prefer' to 'this trades off X for Y'. ## Common mistakes - Relaunching the same platitudes with a poster campaign. - Adding more principles to cover gaps, until nobody can remember any of them. - Treating a principle as a veto that ends discussion, rather than a shared rule the team reasons with.
- Should a design reviewer be allowed to object to a proposal without citing any principle?Yes, but the objection should be labelled as a preference or a new concern. If it keeps recurring, that is a signal the principles are missing something, and the concern may deserve to become a principle. What should not happen is an unnamed preference carrying the same weight as a principle-backed argument.
- How do you handle a principle-backed decision that later turns out wrong in user research?Record the evidence against the decision, fix the design, and then check whether the principle or its ranking caused the error. If it did, revise it openly with the research cited, so the principles stay credible instead of being quietly ignored next time.
saying these in an interview costs you the question
- Principles work once they are published on the wiki
- A poster campaign fixes principles nobody uses
- Adding more principles fixes gaps in coverage
- A cited principle ends the discussion like a veto
- Leadership may override principles silently without cost