Principles
Last updated:
Good frontend work starts with good decisions. Before tools, frameworks, or architecture, these are the calls that keep quality repeatable.
01 — Platform
Build the core experience first
The browser already solved most of the hard problems — start there before you invent a replacement.
Ship something that works without JavaScript, without a design system debate, and without a framework proving its worth. Use native HTML, CSS, and browser behaviour for the baseline experience, then enhance where it genuinely helps.
Prefer defaults over novelty. Measure whether complexity pays for itself in fewer bugs, faster delivery, or clearer maintenance — not whether it looks impressive in a demo.
02 — Trust
Clarity over cleverness
Users should never have to decode the interface to understand what it does.
Clever abstractions, surprise interactions, and one-off patterns feel efficient in the moment and expensive for everyone who follows. Consistency creates trust: the same control behaves the same way in the same situation.
Design and code should support confidence — predictable labels, obvious outcomes, and interfaces that read as seriously as the product behind them.
03 — Content
Content before components
If the message is weak, no component library will rescue it.
Start with what users need to know and do. Structure the page around that — headings, order, and plain language — before you reach for layout grids and reusable widgets.
Model content, not just screens. When copy, hierarchy, and purpose are clear, components become simpler to name, build, and maintain.
04 — Quality
Accessibility is product quality
Friction for disabled users is friction for everyone — it just shows up in audits last.
Accessibility is not a spreadsheet at the end of a sprint. It is whether someone can complete the task with a keyboard, a screen reader, zoom, or a shaky connection on a phone in bright sunlight.
Bake it into decisions early: semantic markup, visible focus, sufficient contrast, and forms that explain errors in language humans understand. Fixing it later costs more and ships worse experiences in the meantime.
05 — Native
Native before custom
Custom UI must earn its place — the platform version is usually cheaper to live with.
Buttons should be buttons. Links should be links. Forms should submit and validate in ways users already understand. Dialogs, details, and popovers exist for a reason — use them before you rebuild them poorly in React.
When you do build custom patterns, document why native options failed and prove keyboard, assistive technology, and mobile behaviour match what users expect.
06 — Speed
Performance is a feature
Slow interfaces feel broken even when nothing is technically 'wrong'.
Performance is part of quality, not a polish pass before launch. Every script, font, and embed has a cost — question each one the way you would question a feature that blocks the main thread.
Favour lightweight patterns, ship useful HTML early, and avoid JavaScript-first solutions for problems the platform already handles well. Fast teams still write standards; they just ship less waste.
07 — Teams
Build for the next developer
The best pattern is the one the next developer understands without a tour guide.
Code that only its author understands is a liability. This reference exists so teams can agree on what good looks like — and ship faster with fewer expensive mistakes, fewer regressions, and fewer debates that should have ended in documentation.
Principles are the start. Standards and patterns turn them into something you can use in review, in delivery, and in production.