product definition

PRODUCT.md is the durable product-truth artifact: who uses this, what success means, and the principles that decide arguments later.

what it teaches

  • name the users by their arrival state. not "developers" but people who already know AI-generated UIs have quality problems and want a practical solution, not education about the problem.
  • define success as observable behavior. two measures: the user steers AI output with design precision instead of vague prose, and the output passes professional design review — not "looks like an AI made it."
  • principles are constraints, not vibes. the five that govern the product:
    1. Practice what you preach — the product must pass its own anti-pattern detector; shipping anything it would flag is losing.
    2. Show, don't tell — the site is the demo; no words about design quality in place of executed quality.
    3. Expert confidence — direct and opinionated; hedging reads as inexperience.
    4. Editorial over marketing — a design publication's register, not a SaaS landing page's.
    5. Purposeful restraint — every element earns its place; nothing included because "landing pages usually have that."
  • accessibility as baseline, not feature — WCAG 2.1 AA with verified contrast (not eyeballed), keyboard navigation, reduced motion, semantic HTML first, plain-language copy.

why

without a written product truth, every design session re-litigates identity from vibes: "modern and sleek," "approachable and warm," "more premium." no one has written down who the user is, so six months later the surfaces contradict each other — one page minimal and technical, another colorful, the homepage glossy, the app stark. the file settles arguments by existing: it is the reference both designers reach for, not vibes or seniority.

when to use

read PRODUCT.md before any design work; write it (via an init interview) before the first surface of a new product.

good and bad

bad

purpose: empower the future of work

the slogan cannot decide a product or design argument. every dispute gets settled by whoever argues loudest, each surface encodes a different assumed user, and the contradictions surface only when the whole product is seen together — at which point the fix is a redesign, not an edit.

good

user: operator who needs to observe and correct a workflow run
success: the operator can identify the blocking step and take the next action

names a user state and observable success that downstream surfaces can test. a named user with an observable outcome converts taste disputes into checkable questions — does this surface let the operator find the blocking step? — so decisions are reproducible across sessions and contributors, and the product accumulates one identity instead of a committee average.

search pages

go to any page