A Design System That Has Drifted

Triage by risk: what invalidates the test, what breaks the contract, what blocks the engineers - then everything else.

Before the test (six days):

1. Replace the placeholder text. Lorem ipsum in two of three flows makes every reading, comprehension, and label finding unusable. This is the highest-value, lowest-effort fix on the list.
2. Fix the contrast on the CTA and any other failing text. It is a contractual AA requirement, and it will be on screen during testing. Diagnose with a checker rather than by eye.
3. Reattach the detached instances on the three tested screens only, and apply auto layout there so the prototype resizes correctly on the test device.
4. Consolidate only the buttons that appear in the test - one component with variant properties for state, size, and icon, rather than 14 separate frames.

After the test: full library rebuild - colour tokens with named variables, spacing scale, auto layout everywhere, remaining detached instances, and deprecation notes for old components.

Deliberately not before the test: a complete design-system migration. It is a project, not a task, and doing it under time pressure produces a second half-finished system, which is how the file drifted in the first place. A design system also needs governance - naming, documentation, and a rule for who changes it - or it will drift again within a quarter.

First, check the ratio against the right threshold, because the threshold depends on the text:

• Normal text: 4.5:1 against its background.
• Large text (18pt, or 14pt bold): 3:1.
• UI component boundaries and focus indicators: 3:1 - so an input outline or a focus ring cannot be faint grey either.

At 3.1:1 the call-to-action passes only if its label is genuinely large, which is rarely true of a button label. Assume it fails and fix it.

Options, roughly in order of preference:

1. Darken the teal until the white label reaches 4.5:1. Keeps brand recognition, changes one token.
2. Invert to a dark label on light teal, if the palette allows.
3. Change the button style for primary actions to the darker brand blue already in the system.

Then check every state, not just default: hover, pressed, focus, disabled, and error. Disabled controls are exempt from contrast requirements, but the label must still be legible enough to be understood, and the focus indicator is not exempt. Check dark mode separately, since a token that passes on light can fail on dark. Record the ratio in the component documentation so the next person does not re-litigate it.

Finally, raise the systemic issue: six near-identical blues is how a contrast failure becomes unfixable, because nobody knows which blue is the real one. Define named colour tokens and deprecate the rest.

Animation in the test. Smart Animate sliding a modal in from the right is polish, and polish can actively distort a usability test - a confident transition makes a missing back affordance feel intended, and participants may not report the confusion they would have had with a plain modal. Use motion only where it carries meaning: a modal appearing over the page communicates that the page is still there behind it, which a full-screen navigation does not. Otherwise use a simple dissolve. Then test on the actual device size the user will hold, because a slide tuned on a 1440px frame can look broken on a phone.

What to define before handoff, since engineers are guessing:

• States as variants: default, hover, focus, pressed, disabled, loading, error - for every interactive component, not just buttons.
• Edge cases: empty states, error states, long text, and truncation rules. If these are missing, engineers will invent them, and invented empty states are where products look unfinished.
• Spacing and layout: auto layout with explicit padding and gap, so measurements come from the file rather than from the eye.
• Interaction notes: what each control does, where it navigates, and what happens on failure.
• Tokens, not hex codes: colours and type styles referenced by name, so a change propagates.

Use Dev Mode so the engineers can inspect measurements, tokens, and annotations in place. Then do a 30-minute walkthrough with them - a handoff is a conversation, not a link.