skip to content

What separates a useful product design principle from a platitude, and how would you test a draft principle before a team adopts it?

level: middleimportance: should knowfreq 32%

answer

  1. would anyone argue the opposite
  2. settles a real past disagreement
  3. specific to these users
  4. a reviewer can point at a violation
  5. names what you give up

basics

~20 s

A useful principle settles a real disagreement: its opposite is something a reasonable team might choose, and it points to a specific decision. A platitude like 'easy to use' has no sensible opposite, so everyone agrees with it and it decides nothing.

solid answer

~40 s

The core test is whether the principle **settles a disagreement**. 'Simple and delightful' fails, because nobody argues for complex and joyless; 'confirm the medicine even when it costs a tap' passes, because a speed-first team could reasonably choose otherwise. I would run a draft through a few checks: is its **opposite reasonable**; can we name a **past decision it would have decided**; is it **specific** to our users, here patients refilling prescriptions; can a reviewer **point at a screen** and say it violates the principle; and does it say what we are willing to **give up**. A draft that fails most of these is a value statement, not a principle, and should be rewritten or dropped.

go deeper

for a junior

Recall that a principle must help decide between options, and that adjectives like simple or delightful cannot do that because nobody argues against them.

for a middle

Explain the tests - opposite, past decision, specificity, violation, cost - and show how to rewrite a platitude into a rule with its trade-off visible.

for a senior

Run the test with real material: collect recent disagreements, check which drafts would have decided them, then drop, merge or rank principles based on the result.

for a principal

Argue why fast consensus on principles is a warning sign, and how to get leadership to adopt principles that openly name what the product will not do.

## Why platitudes are the default failure When a team writes design principles in a workshop, the first drafts are often platitudes: 'simple', 'intuitive', 'delightful', 'user-centred', 'consistent'. They are appealing because everyone agrees with them. That agreement is the problem. A principle exists to settle arguments between reasonable options, and a statement everyone already agrees with cannot tip any argument either way. Consider a pharmacy refill app where the team is split on whether to show the medication's name and strength on a confirmation screen before submitting a refill. 'Keep it simple' supports both sides: one says confirmation adds clutter, the other says it prevents confusion. The principle has decided nothing. ## The tests A draft principle can be checked with a short set of questions: | Test | Question to ask | Platitude fails because | |---|---|---| | **Opposite test** | Is the reverse something a sensible team might choose? | Nobody chooses 'hard to use' | | **Past-decision test** | Would it have decided a real disagreement we had? | It supports both sides | | **Specificity test** | Would it fit a very different product unchanged? | It fits every product | | **Violation test** | Can a reviewer point at a screen and say it breaks this? | Nothing concrete can break it | | **Cost test** | Does it name what we give up? | It promises everything at once | The **opposite test** is the fastest filter: if the opposite of the principle is absurd, the principle is not saying anything. ## Rewriting a platitude into a principle The usual rewrite moves from an adjective to a decision: 1. Start from the platitude - 'simple'. 2. Ask what simplicity has cost or would cost in this product - fewer checks before a refill goes out. 3. Name the trade-off the team actually wants - accuracy over fewer steps for medication details. 4. Write it as a rule with its cost visible - 'Confirm the medicine, even when it costs a tap'. 5. Attach an example decision - the confirmation screen shows the drug name, strength and prescriber. The result is arguable, which is exactly what makes it useful. A delivery app might legitimately choose speed over confirmation; a pharmacy app chooses confirmation, and now everyone knows it. ## What good principle sets also include Beyond the one-line rule, each principle usually carries: - a **one-sentence rationale** tied to the product's vision or its users' risks; - **one or two examples** of decisions it settled, which teach how to apply it; - optionally, a **counter-example** - a design that looks fine but breaks it. Examples matter more than the wording. People learn how a principle bends and where it stops from the decisions it has already made. ## A worked test of three drafts Take one real disagreement from the pharmacy team: should a refill reminder open straight into a prefilled refill, or into the patient's full medication list? - **'Keep it simple'** - both sides claim it; decides nothing. - **'Refill is the default path; everything else is one step away'** - decides it: open the prefilled refill, with the full list one tap away. - **'Patients are in control'** - arguable in principle, but here both options leave the patient in control, so it did not decide this case; it may still decide others. Only the second draft passed on this disagreement. Running the whole set against five to ten such cases shows which drafts carry weight and which only sound good. ## Testing a draft with the team Before adoption, a practical approach is: - Collect **five to ten recent design disagreements** from critiques and reviews. - For each draft principle, ask whether it would have **decided** each disagreement, and which way. - Drop principles that decide none, and **merge** principles that always decide the same way. - Check that two principles that do decide things do not silently **contradict** each other; if they can conflict, the set needs a ranking. ## Common mistakes - Mistaking **values** ('we care about patients') for principles: values motivate, principles decide. - Writing principles that describe the **current design** rather than the choices the team wants to make next. - Adopting a principle because **everyone agreed quickly** - quick unanimity is a warning sign, not an endorsement. - Keeping principles that are never cited: an unused principle is a platitude in practice even if it passed the tests on paper.

  • Can a principle pass the opposite test and still be a bad principle?
    Yes. A principle can be arguable yet wrong for the product, for example favouring speed over confirmation in a medication app. The opposite test only proves the statement says something; whether it says the right thing depends on the vision, the users' risks and evidence from research.
  • What is wrong with a principle such as 'be consistent'?
    As written it has no sensible opposite and hides the real trade-off: consistency with what, and at what cost? A useful version names the choice, for example favouring consistency with the platform's own conventions over the brand's custom controls, which a different team could reasonably reverse.

saying these in an interview costs you the question

  • A principle everyone agrees with instantly is a strong principle
  • Easy to use is a good product design principle
  • Principles should describe how the current design already works
  • Company values and design principles are interchangeable
  • A good principle never names what the team gives up