Standards
Build speed into the system, calm into the experience.
The best product work makes complex systems feel understandable, bounded, and worth trusting. A user should be able to see what is happening, decide what should happen next, and recover when the system needs correction.
Standard statement
Great product work gives people more capability without taking away their judgment.
That requires clear outcomes, visible system behavior, governed automation, evidence for important claims, accessible interaction, and reusable patterns that help quality scale beyond a single review.
Operating rules
These are the standards I would use in critique, product review, implementation review, and release judgment.
Start with the user job
Every flow should make the intended user outcome, context, constraint, and success signal clear before the interface gets clever.
Preserve orientation
The user should always know where they are, what is happening, why it matters, what changed, and what happens next.
Govern consequential action
Autonomy is scoped by risk. External, irreversible, expensive, or reputation-impacting actions need preview, explanation, and explicit approval.
Show evidence for important claims
Recommendations, summaries, rankings, and automated actions should connect to sources, tool output, assumptions, or visible uncertainty.
Design recovery as a primary path
Pause, edit, reject, retry, undo, take over, and recover states are not edge cases. They are how users stay in control.
Ship calm interface craft
The product should feel focused, legible, responsive, and restrained: strong hierarchy, generous spacing, plain language, and no performative complexity.
Make accessibility part of the default
Semantic structure, keyboard paths, labels, contrast, focus states, reduced motion, and readable layouts should be expected before release.
Prefer system fit over one-off polish
When a pattern repeats, it should become a design-system primitive, template, skill, hook, or documented decision.
Quality bar
The bar should be clear enough for designers, engineers, and agents to evaluate work the same way.
Product
The work solves a real user job and names the tradeoff it is making.
Agent behavior
The system exposes plan, scope, evidence, risk, approval, and recovery when autonomy is involved.
Interface
The screen is calm, linear, legible, responsive, accessible, and visually resolved in light and dark modes.
Copy
Language is plain, specific, and useful. It avoids vague AI language and explains risk without drama.
Engineering
States are typed, edge cases are represented, patterns are reusable, and implementation details preserve design intent.
System
The decision either uses the existing system or improves it for the next team member.
Review questions
A lightweight rubric for deciding whether work is ready to ship.
- 01Does this solve an explicit user job?
- 02Can the user tell what is happening and what happens next?
- 03Are consequential actions previewed, explained, and approved?
- 04Are important claims supported by evidence or clear uncertainty?
- 05Can the user pause, edit, reject, recover, or take over?
- 06Does the work hold up across mobile, desktop, light mode, dark mode, keyboard use, and basic accessibility expectations?
- 07Does this reuse or improve the design system instead of creating a one-off pattern?
- 08Should any decision from this work become a skill, hook, template, or documented standard?
Enforcement
Standards should not depend on memory. They should become part of the way work is created, reviewed, and shipped.
Design system
Reusable primitives, tokens, states, examples, accessibility rules, and interaction patterns.
Skills
Repeatable workflows for design critique, agent UX review, accessibility audit, copy review, and visual polish.
Hooks
Automatic checks for known non-negotiables before work ships.
PR checks
A lightweight release contract for evidence, approval, accessibility, responsive fit, and documented exceptions.
Decision records
Short explanations of why a standard exists, where it applies, and when it should be revisited.