Organize a consistent website design system

Start with actual pages and components

Inventory headings, cards, buttons, forms, messages and spacing on important pages. Find variants that fulfil the same role and those meeting genuinely different needs. Combine duplicates before inventing another component.

For each element, document its use, expected content and necessary states: normal, focus, error, loading or unavailable. Guide and service cards may share a base while carrying different information.

• Components found on real pages.
• Duplicates rationalised.
• Useful states described.

Connect style with meaning

Define a hierarchy of headings, body text, space and colour. A primary button should consistently signal a priority action; colour cannot be its only cue. Preserve contrast, text size and visible focus in each variant.

Test long languages and different scripts. A German label or right-to-left Arabic layout may overflow where French fits. The multilingual guide covers these content and interface constraints.

Assess a colour pair and its purpose, not an isolated palette colour. Opaque sRGB teaching example: #777777 on #FFFFFF gives approximately 4.478:1, below WCAG 1.4.3’s 4.5:1 minimum for text outside its exceptions. W3C says not to round the result when deciding: displaying 4.5 to one decimal place does not turn failure into a pass. #767676 on the same white gives about 4.542:1 and exceeds that specific threshold. This check does not establish overall component conformance.

The 3:1 threshold for large text is not triggered by naming a style “large heading”. The criterion specifies, among other conditions, 18 point or 14 point bold; check rendered size and applicable conditions. Record text purpose, foreground/background pair and tested state. With transparency, gradients or background images, two palette codes no longer necessarily describe adjacent rendered colours. Keep a readability margin and retest variants instead of permanently approving a colour token alone.

• Visual role consistent.
• Contrast and focus checked.
• Variants tried in multiple languages.

Scroll the table horizontally to read every column. With a keyboard, focus the table area and use the arrow keys.

Try components in context

Place elements in pages with real text and images. A card elegant with two words may fail with a three-line title. Test phone width, zoom, form error and empty states before declaring a component ready.

Pair examples with simple acceptance checks. The prelaunch guide helps turn visual rules into journey checks instead of isolated screenshots.

• Short and long content tested.
• Empty and error states visible.
• Mobile and zoom checked.

Evolve the system without drift

Assign an owner to design decisions. When adding a variant, explain the need and where it belongs. Repeated exceptions may show that a general rule should change.

After changing typography, space or colour, review representative pages and languages. Keep a few examples current rather than a large obsolete document. The maintenance guide helps organise these checks.

• Decisions and uses documented.
• Exceptions tracked.
• Representative pages reviewed after changes.

Document how variants behave

Alongside colours and spacing, describe control contracts: navigation or action, selected state, unavailability and cancellation. Identical-looking buttons may reveal detail or submit a form; documentation and checks need that distinction.

Retain examples with long text, errors and missing data. Connect variants to their actual pages so changes have a clear review scope. A variant altering keyboard operation is a behavioural change, not merely another appearance.

Choose interface links, buttons and actions · Choose and test tabbed web views · Organise content with accordions and disclosures