Skip to content
Design Engineering
Foundations

The quality bar

Seven principles every product here is held to, whatever it is built with.

Good products share a texture you can feel but rarely see specified. These seven principles are the standard behind this guide and the skills. Measure your work against them before you call it done.

1. Product-specific, not template-shaped

The interface should visibly respond to its actual user, content, and task. Don't let an agent default every product to a sidebar, a header, four statistic cards, a generic table, and rounded containers everywhere. A dense dispatch screen and a luxury checkout can both be excellent — they should look nothing alike.

2. Deliberately composed

Strong alignment, hierarchy, proportion, typography, density, and rhythm. Beautiful does not mean more gradients, blur, animation, cards, and shadows — it means the design has authorship. A larger or more decorative diff is not evidence of improvement.

3. Behaviour is part of the design

Loading, empty, error, permission, success, stale, conflict, interrupted-write, and recovery states belong to the experience. A polished screenshot of the happy path isn't a polished product.

4. Responsive by relationship

Preserve the task, hierarchy, and interaction as conditions change — don't just stack desktop regions vertically. Decide what relationships should survive as space changes; let content, not device presets, determine breakpoints. See responsive layout.

5. Accessible by construction

Semantics, keyboard behaviour, focus, contrast, target size, reduced motion, and text expansion are design decisions, not a checklist to run afterward. A Lighthouse score is not proof that a person can use the thing.

6. Architecturally honest

Mocks are called mocks. UI restrictions aren't called authorization. Local state isn't called persistence. Login isn't called tenant security. A passing build isn't called verification. This matters most in AI-generated applications, where confident-sounding shortcuts compound fast.

7. Proven in the actual result

Inspect the thing. Render it. Use it. Break it. Resize it. Reload it. Try the denied path. Compare before and after. Nothing counts as working until the result itself has been observed — not the source, not the build log, not the score.

Name the slop

Generated interfaces fail in recognizable ways. Give each failure a name so you — and your agent — can spot it and refuse it:

  • The default dashboard — sidebar, stat cards, and a generic table, regardless of what the task actually is.
  • Cardified tables — comparison tables auto-stacked into cards on small screens, destroying the relationships the task depends on.
  • Hamburger by default — navigation hidden in a drawer before content pressure demands it.
  • Gradient confetti — decoration standing in for composition: blobs, glass, and glow with no hierarchy job.
  • Marketing hero in a work tool — giant headline treatment on dense operational surfaces.
  • The lonely centered column — one narrow column for comparative or parallel work that needs breadth.

When you catch one, say its name in review. Named patterns get recognized; vague unease gets shipped.

Where this lives in the work

Four skills carry the overall bar: $prototype makes the idea real enough to evaluate, $craft makes the experience excellent, $slice makes one workflow actually real, and $readiness proves what level of use it can safely support. The other fourteen answer narrower questions. Start with interface craft to see the bar applied to visible work.

Last updated on

On this page