Drift is invisible one page at a time. A button with a radius two pixels off is nothing. The same button rendered four different ways across one signup flow is a system problem, and the only way to see it is for somebody to walk the whole thing.

Nobody walks the whole thing. It's tedious, it's never the most urgent task, and by the time you'd notice, three releases have shipped on top of it.

Walk the real pages, in the states that break

Strawberry works in the browser, so it can move through the live product the way a user does and inspect what's actually rendered rather than what a spec says should be. That distinction is the whole point: the drift you're looking for exists precisely because the build and the definition disagree.

It checks the states that get skipped in review, across the breakpoints and themes you care about:

  • Spacing off the scale, and type outside the ramp.
  • Colors that are nearly a token but not the token, and text failing contrast against its real background rather than its intended one.
  • The same component built three ways, or a variant doing a job it wasn't made for.
  • Focus that isn't visible, hover that changes nothing, disabled that doesn't read as disabled.
  • Empty and error states, where drift concentrates because they get built last and reviewed least.
Want to try it?

Ask your Strawberry companion: “Walk these pages and show me where the built interface has drifted from our design system. Cover the states and breakpoints, and group the findings by cause.”

Skill

Find where the interface has drifted

Walk these pages and show me where we have drifted from our design system.

Findings grouped by cause, not by page

A list of forty inconsistencies ordered by URL is a document nobody opens twice. Twelve instances of one wrong token is a single fix and should read like one, which changes it from a backlog into an afternoon.

Ordering follows what actually matters. Accessibility failures first, then anything sitting on a primary flow, then visible inconsistency, then cosmetic drift. And you're told which surfaces were walked and which weren't, so a bounded audit doesn't get read as full coverage.

Not every difference is a defect

A deliberate exception, a legacy surface already scheduled for replacement, and a genuine mistake look identical from the outside. An audit that files all three as bugs gets ignored, and deservedly.

So findings that look intentional get raised as questions rather than defects. You know which of them were decisions.

Keep it from coming back

Drift returns. It's the by-product of shipping quickly rather than of anyone being careless, which is also why a one-off cleanup buys you about a quarter.

Once an audit is set up the way you want it, the system it checks against, the surfaces it covers, and the states it inspects can be saved. After that it can run as a Routine that re-walks the agreed surfaces once a release lands and tells you only what's newly broken.

Ship what customers actually asked forFlow audits, bug research, and specs from the build side of the same product. Research deep enough to bet onThe evidence side: sourcing, structured data, and clear answers.
Official Strawberry skill
Copy skill file Download skill file
name
audit-a-design-system
description
Click through a live product or site and record where the interface has drifted from its design system, with inspectable evidence for each finding. Use for spacing, type, color, component, state, and accessibility inconsistencies across real pages rather than in a design file.

Audit a Design System

Walk a live product and find where the built interface has drifted from the system it is supposed to follow. The design file is not the subject here. The pages users actually see are.

Drift is invisible page by page and obvious in aggregate. One button with the wrong radius is nothing; the same button rendered four different ways across a signup flow is a system problem.

1. Agree the system and the scope

Establish what the interface is meant to conform to: a published design system, a token set, a component library, or simply the pattern used on the pages the user considers correct. When there is no documented system, ask which pages are the reference and treat those as the standard.

Agree the surface to walk. A flow, a section, a breakpoint, a theme, or a specific component wherever it appears. An unbounded audit of an entire product returns a list nobody reads.

2. Walk the real pages

Move through the live interface the way a user would, and inspect what is actually rendered rather than what the design file specifies. Look at each page in the states that matter: default, hover, focus, disabled, loading, error, and empty. Empty and error states are where drift concentrates, because they get built last and reviewed least.

Check the breakpoints the user cares about, and both themes where the product has them.

3. Record what has drifted

Useful categories:

  • Spacing: padding and gaps that do not sit on the scale.
  • Type: sizes, weights, and line heights outside the ramp, or the same role rendered differently in different places.
  • Color: values that are close to a token but not the token, and text or icons that fail contrast against their real background.
  • Components: the same element built several ways, or variants used outside their purpose.
  • States: missing focus indication, hover that changes nothing, disabled that does not read as disabled.
  • Content and shape: inconsistent radii, borders, shadows, or icon weights.

For every finding, record where it is, what it should be, and what it currently is. Capture the evidence so the user can see it without rerunning the audit.

4. Separate a defect from a decision

Not every inconsistency is a bug. A deliberate exception, a legacy surface scheduled for replacement, and a genuine mistake all look identical from outside. Group findings by confidence and ask about the ones that look intentional rather than filing them as errors.

5. Return something a team can act on

Group by cause rather than by page. Twelve instances of one wrong token are a single fix and should be presented that way; twelve unrelated one-offs are a different problem.

Order by what actually matters: accessibility failures first, then anything affecting a primary flow, then visible inconsistency, then cosmetic drift. Say plainly what was walked and what was not, so nobody reads a bounded audit as complete coverage.

6. Continue

Use strawberry/product-engineering/audit-a-product-flow when the question is whether the flow works rather than whether it is consistent, and strawberry/product-engineering/write-a-product-spec when a finding turns into work that needs specifying.

After the audit proves useful, preserve the accepted system, the surfaces walked, the states checked, and the report format as a custom skill. A Routine can re-walk agreed surfaces after releases and report only new drift, once the scope and the review point are settled.