Design requirements

This page defines the requirements for design work to be considered ready for review, handoff, or build.

These requirements apply to:

• Component design
• Page and flow design
• Updates to existing components or patterns

They exist to ensure designs are consistent, accessible, and implementable.

Purpose

Design requirements act as a shared contract between Design and Engineering.

They help:

• Reduce rework and clarification cycles
• Ensure consistency across products
• Make handoff predictable and scalable
• Maintain quality as the system grows

Component design requirements

Every component design must include the following.

1. Clear intent

Document:

• What problem the component solves
• When it should be used
• When it should not be used

This prevents components from becoming overly flexible or misused.

2. Complete anatomy

Design must clearly define:

• All internal parts (e.g. container, label, icon, helper text)
• Required vs optional elements
• Slot or content areas (if applicable)

Figma requirements:

• Layers are named clearly and consistently
• Anatomy is visible in the main component or via an annotated frame

3. Variants

All supported variants must be designed and documented.

Variants may include:

• Visual style (e.g. primary, secondary)
• Size (e.g. sm, md, lg)
• Tone or intent (e.g. default, success, warning, danger)
• Density or layout variations

Rules:

• Variants must reflect real use cases
• Avoid speculative or unused variants
• Each variant must be visually and functionally distinct

4. States

Every component must include all relevant states.

At minimum:

• Default
• Hover (if applicable)
• Focus (keyboard-visible)
• Active / pressed
• Disabled

If applicable:

• Loading
• Error
• Read-only
• Selected / checked

Accessibility requirements:

• Focus styles must be clearly visible
• Disabled states must not be the only way restriction or requirements are communicated. Users must be told why an action is unavailable and what to do next.

5. Content rules

Design must specify:

• Allowed content types (text, icon, media)
• Text length guidance and wrapping behaviour
• Truncation behaviour
• Multiline behaviour (if supported)

This ensures predictable behaviour with real content.

6. Layout and spacing

Components must be designed using system spacing and sizing tokens.

Design must document:

• Internal padding and spacing
• Alignment rules
• Minimum and maximum sizes
• Behaviour in constrained or fluid layouts

Avoid hard-coded values unless explicitly justified.

7. Accessibility

Each component must consider accessibility from the outset.

At minimum:

• Intended semantic role or HTML element
• Keyboard interaction expectations
• Screen reader considerations
• Colour contrast compliance

Any known limitations must be documented.

Page and flow design requirements

These requirements apply to full pages, screens, and user flows.

1. Structure and hierarchy

Pages must:

• Use established layout patterns
• Follow typography and spacing guidelines
• Have a clear visual and content hierarchy

Key actions and information should be immediately discoverable.

2. Component usage

Pages must:

• Use existing components wherever possible
• Avoid one-off or visually inconsistent patterns
• Propose new components when gaps are identified

Any deviation from the system must be called out explicitly.

3. Responsive behaviour

Designs must demonstrate:

• Behaviour at relevant breakpoints
• How content reflows or adapts
• Any changes in hierarchy or interaction

If only a single breakpoint is provided, assumptions must be documented.

4. States and edge cases

Pages and flows must include:

• Loading states
• Empty states
• Error states
• Success or confirmation states

Designs should reflect realistic data and edge cases.

Figma file and page structure

To support consistency, collaboration, and efficient handoff, Figma files must follow a standardised page structure.

This structure ensures designers and engineers can quickly find:

• System foundations
• Component definitions
• Usage and implementation details

Pages

Foundations

Provide a visual, at-a-glance reference for system foundations, focused on usage, not theory.

What this page includes:

• Colour palettes with usage labels (e.g. text, background, border, intent)
• Typography styles shown in real content contexts
• Spacing scale examples and common layout patterns
• Motion examples (if applicable), showing duration and easing in context

Components

Act as the source of truth for all components in the system.

What this page includes:

• Master components only (no detached instances)

Complete coverage of:

• Anatomy
• Variants
• States
• Accessibility considerations
• Clear naming that matches the documented component name

Component grouping

Components must be grouped by category for discoverability, for example:

• Components / Navigation
• Components / Forms
• Components / Data Display
• Components / Feedback
• Components / Overlays

Each category should:

• Contain only related components
• Use consistent ordering and layout
• Avoid mixing experimental or deprecated components

Component Layout Requirements

Within each component section:

• Anatomy is clearly labelled or visually annotated
• All variants are visible without scrolling where possible
• States are grouped and easy to compare
• Accessibility notes are included as lightweight annotations -Usage examples are clearly separated from master definitions

General Figma Rules

• Pages must not mix foundations, components, and flows
• Experimental or in-progress work must live on clearly labelled separate pages
• Naming in Figma must align with documentation and code
• Local styles, overrides, or ad-hoc values should be avoided

Design Readiness Checklist

A design is considered ready for build when:

• Purpose and usage are clear
• All required variants are designed
• All relevant states are included
• Spacing and sizing use system tokens
• Accessibility has been considered
• Edge cases are explored
• Figma file structure follows standards

If any item is missing, it should be flagged during review.

Ownership and follow-ups

Each piece of design work should document:

• Owner(s)
• Status (draft, ready for review, ready for build)
• Known gaps or follow-up work

This ensures accountability and long-term maintainability.

Summary

Design requirements exist to ensure that what we design can be built, used, and maintained.

Meeting these requirements means:

• Fewer handoff issues
• Faster implementation
• Higher quality outcomes

Designs that meet this bar help the system scale with confidence.