Digital products

Accepted

Every colour, space and type size in an Aleris interface comes from the shared token file instead of being typed by hand.

Why it looks like this

Every screen is either communicative, where Aleris tells, guides and welcomes, or instrumental, where the user works, navigates and monitors. The mode follows the situation, not the person's role: a patient managing their treatment plan is working, and a member of staff reading an internal newsletter is being told something. A booking flow is instrumental from the first step to the last, and the mode does not shift between steps in one flow.

The tokens are plain CSS custom properties, tied to no framework. Aleris works across three countries with separate technical infrastructure, different digital maturity and products on different technology stacks, so a framework can be added on top as a bridge while the tokens stay the same.

Motion has one job: to confirm that the system is listening. Every movement answers something the user did or shows a change in the system's state, and motion that is there because it looks good does not belong.

What never changes

The page is sand: sand-100 on communicative surfaces, sand-50 on instrumental ones
A white or coloured section is a layer on top of it, even when it fills the screen.
One primary action per screen, in interactive orange
Interactive orange is a darker step than the brand orange, which is for accent, decoration and print, because white text on the brand orange fails AA.
No value is typed by hand
No hex colours, no pixel values for spacing and no raw Tailwind colour classes in product code: everything goes through the token file.
Animate what does not move the layout, unless the user moved it
Size may change only when the user caused it, one contained element at a time and within the moderate duration, and the reduced-motion setting turns all animation off. Email layouts are static.
Contrast meets WCAG AA
That is 4.5:1 for normal text and 3.0:1 for large text and interface components.
Touch targets are at least 44px
A dense desktop tool used with a mouse or trackpad can go down to 24px, but anything a patient touches, or anything that could be used on a touchscreen, keeps 44px.
Keyboard focus shows on every ground
Buttons draw a dual ring, white inside and petrol outside, swapped on the white button that sits on petrol, so one of the two rings always contrasts.

How to apply it

Communicative surfaces

Patient-facing content, service introductions and marketing sit on sand-100, with cards for content structure, generous spacing and one reading column that grows with the window.

Transitions can be a little longer and more expressive here, because the reader is browsing and the rhythm is slower.

Instrumental surfaces

Tools, admin, dashboards and booking flows sit on sand-50. Cards are optional, spacing is tighter and content can span all twelve columns. The type stays the same size, and the density comes from how the layout is used and from the information hierarchy.

Keep motion tight. The fast duration is the default for buttons, hovers and state changes, and modals and panels can use the moderate one.

In a table, put the identifier in the first column and row actions next to it rather than at the far right. Numbers are right-aligned and text left-aligned, and headers are quieter than the data, in smaller type and sentence case.

Every surface

Reference the semantic tokens in product code, and look a token up in baseline-tokens.json, which carries its usage and constraints. Keep the comments in aleris-tokens.css where a developer opens it, because every usage and constraint note is a rule, and strip them from the stylesheet at build time.

Show loading with a skeleton shimmer rather than a spinner. Past two seconds, add progress; past ten, let the person move on and tell them when it is done.

Show a time at the precision the reader's decision needs. A patient deciding whether to leave the house needs "in 20 minutes", not the seconds of a database timestamp.

Relative time, such as "two days ago", belongs on a live screen. In an email, a PDF or a printout it is false, so store and send the absolute time.

The values

Token	Value	Used for
`--spacing-0`	0px	Zero gap, collapsed state
`--spacing-3xs`	4px	Minimum gap, icon padding, label-to-field
`--spacing-2xs`	8px	Tight element spacing, inline gaps
`--spacing-xs`	12px	Related element spacing, input padding-y
`--spacing-sm`	16px	Default component padding, grid margin mobile
`--spacing-md`	24px	Section spacing within components, card padding
`--spacing-lg`	36px	Between components, above h2
`--spacing-xl`	48px	Between sections
`--spacing-2xl`	72px	Major section breaks
`--spacing-3xl`	96px	Page-level spacing
`--radius-0`	0px	Sharp corners, full-bleed edges
`--radius-s`	4px	General containers: panels, modals, tables
`--radius-l`	16px	Cards only
`--radius-m`	8px	Interactive: buttons, inputs, dropdowns
`--radius-full`	100px	Compact indicators: badges, tags, avatars
`--shadow-e2`	-2px 2px 4px rgba(0, 72, 81, 0.06), -3px 8px 24px rgba(0, 72, 81, 0.1)	Dropdowns; the hover state of a clickable card; and one featured element per communicative page at rest, such as the text card of a hero

What good looks like

Do
One orange button, with a secondary button beside it
Interactive orange marks the one primary action on the screen.
Don't
Two orange buttons in the same view
Two equally strong signals leave the reader without one clear next step.
Do
An accordion that opens when the user clicks it
The user caused the change, and it is contained to one element.
Don't
A banner that grows into place as the page loads
Nothing changes size on its own, not on load and not on scroll.
Do
A booking flow on sand-50 from the first step to the last
A booking flow is instrumental throughout, even where it carries information.
Don't
A booking flow that switches to sand-100 for its information step
Mixing modes in the middle of a flow reads as incoherent.
Do
44px buttons in a patient booking flow
Anything a patient touches keeps the 44px target.
Don't
24px icon buttons in the same flow
The 24px floor is for dense desktop tools used with a mouse, not for surfaces a patient touches.

Asked about digital products

Is 44px the minimum touch target everywhere, or can a dense desktop table go smaller?
How do I get the Aleris tokens into my project?
Why does Museo Sans fall back to Arial when our app is deployed?

Creating with digital products

How it is checked

Button token parsing
Button text meets AA against its own fill
Button fills are perceivable against the surfaces they sit on
Filled button variants declare their own active fill
Form input tokens are perceivable against their surfaces
Table row states are perceivable against the page
The touch-target token matches the rule it exists to enforce
The pointer-target token matches the AA floor the rule relaxed to
Radius-l is reinstated for cards, and the image-in-card inversion is resolved
The corpus's own surfaces use the breakpoints they declare
The decided column ladders keep their anchors

Read from data-products/tokens/tokens.test.ts at build.

Source and status