Design reviews argue about screenshots. Meanwhile the thing your users actually load has quietly moved. A radius that isn't quite the token, a focus state that never shipped, an empty screen nobody has looked at since the release it went out in.

Your system is probably in good shape wherever it's defined. It's the built product that drifts, and checking all of it is tedious enough that it doesn't happen. Strawberry works in the browser, so it can go and look at the real thing: the pages that render, in the states that actually break, across the breakpoints and themes you care about.

What Strawberry can help you do

Not sure where to start? Tell your companion what you're working on and it can suggest a first step. See the skill

Find where it has drifted

Drift is invisible one page at a time and obvious in aggregate. A single button with the wrong radius is nothing. The same button rendered four different ways across one signup flow is a system problem, and you only see it if someone walks the whole thing.

That walk is tedious, which is why it doesn't happen. Your companion can do it against the live product, in the states that actually break:

  • Spacing that isn't on the scale, and type outside the ramp.
  • Colors that are nearly a token but not the token, and text that fails contrast on its real background.
  • The same component built three ways, or a variant used somewhere it wasn't meant for.
  • Focus that isn't visible, hover that does nothing, disabled that doesn't look disabled.
  • Empty and error states, where drift concentrates because they get built last and reviewed least.

Findings come back grouped by cause rather than by page. Twelve instances of one wrong token is a single fix, and it should read like one. Accessibility failures come first, then anything on a primary flow, then the cosmetic drift.

It also won't file a deliberate exception as a bug. Where something looks intentional, it asks rather than assuming.

Ground it in what users said

Design reviews go badly when the strongest evidence in the room is a preference. Themes pulled from actual feedback, with the quotes still attached, tend to end the argument faster than another round of opinions.

Hand it over cleanly

A design decision that lives only in a file gets rebuilt from memory. Turning it into a spec, or into something presentable for the people who have to agree to it, is the part that decides whether it survives contact with a sprint.

Make reviews stick

Design decisions get made in a room and then quietly evaporate. Three weeks later the same debate runs again, because nobody wrote down what was settled or why.

Keep the product honest

Drift comes back. It always does, because it's the by-product of shipping quickly rather than of anyone being careless.

Once an audit is right, the system it checks against, the surfaces it walks, and the states it covers can be saved. If the whole team should be checking the same way, that method can be shared rather than living with whoever set it up.

Skill

Make a design process reusable

Turn this audit into something the design team runs the same way.

After that, a Routine can re-walk the agreed surfaces once a release has landed and tell you only what is newly broken.

Ship what customers actually asked forFlow audits, bug research, specs, and metrics from the build side of the same product. Market like a team of tenAudience research and positioning work that feeds design decisions. Research deep enough to bet onSourcing, landscape mapping, and structured evidence behind a design argument.
Official Strawberry skill
Copy skill file Download skill file
name
getting-started-with-design-work-in-strawberry
description
Help a designer audit a live interface for drift, understand who they are designing for, turn feedback into design themes, and present work. Use to choose a first design workflow and complete one real result.

Getting Started with Design Work in Strawberry

Help the user finish one real piece of design work, then show them the workflow behind it.

The useful ground here is the built product rather than wherever the design is authored. Walking the live interface, gathering the evidence a decision needs, capturing what a review actually decided, and turning accepted work into something the people building it can follow.

Start with the live product

The most useful thing here is that the companion can open the real interface and move through it. Use strawberry/design/audit-a-design-system to walk agreed pages and record where the built interface has drifted from the system, across the states and breakpoints that matter.

Use strawberry/product-engineering/audit-a-product-flow when the question is whether the flow works rather than whether it looks consistent.

Ground the work in evidence

Use strawberry/product-engineering/synthesize-customer-feedback to turn approved feedback into source-linked themes, so a design argument rests on what users said rather than on whoever spoke last in the review.

Use strawberry/marketing/research-an-audience when the user needs a sourced picture of who they are designing for.

Keep decisions from evaporating in reviews

Design decisions are usually made in a room and then lost. Use strawberry/operations/prepare-for-meetings to walk into a review with what was decided last time, what has changed since, and the open questions that need answers. Use strawberry/operations/debrief-a-meeting afterwards to capture what was actually decided, what is still open, and who owns the next move, so the same discussion does not run twice.

Carry it into the work that follows

Use strawberry/product-engineering/write-a-product-spec when a design decision needs specifying for the people building it, and strawberry/research-analysis/create-beautiful-slide-deck when the work needs presenting to a room rather than reviewed in a file.

Keep what works

Preserve the accepted system, audit scope, states checked, and report format as a custom skill. Use strawberry/operations/set-up-shared-team-workflow when the design team needs one shared method. A Routine can re-walk agreed surfaces after each release and report only new drift, once scope and review point are clear.