A design system does not have to be a large component library. For a focused website, it can be a documented set of CSS custom properties, layout rules, reusable components, and interaction states. The goal is to make common decisions once and make unusual decisions visible.
Start with semantic tokens
Define variables for background, surface, text, muted text, border, primary action, accent, success, and error. Add spacing, radius, shadow, and content-width scales. Name variables by purpose rather than a specific color so a future theme change does not require rewriting component rules.
Create a predictable type scale
Choose body size and line height first. Use clamp for a few responsive headings rather than many unrelated sizes. Limit paragraph width for comfortable reading, keep labels large enough to use, and test at browser zoom. Typography should communicate hierarchy without depending on every heading being dramatically larger.
Build components from shared primitives
Cards, buttons, tags, inputs, alerts, and navigation should reuse the same tokens. Define base behavior and add small variants for meaning. Include hover, focus-visible, active, disabled, loading, error, and empty states. A component is not complete when only its default screenshot looks good.
Use layout rules instead of page exceptions
Create containers, grids, clusters, and stacks that respond to available space. Let grid minmax and flexible gaps handle ordinary changes before adding media queries. Avoid fixed heights for text content. Test long headings, translated text, missing images, and cards with unequal descriptions.
Audit by removing a token
Change one color, radius, or spacing token and inspect the site. Components that do not respond reveal hard-coded decisions. Document when an exception is intentional. This exercise turns visual consistency into something measurable and keeps new pages from drifting as the site grows.
Document the system in one page
Create a living reference that displays the color roles, type scale, spacing, buttons, fields, tags, cards, alerts, and their interaction states. Include examples with long content, errors, disabled controls, and narrow widths. Use this page during review so a new feature can be compared with established patterns. Update tokens and documentation together rather than allowing the reference to become historical.