Skip to content

Before your next release

Ship what you meant.

Design, usability and accessibility reviews for teams building with AI.

See what needs attention in your running product, give your coding agent clear fixes, and check the result.

Ask for a free review See an example

A free review, arranged by email. We agree what it covers with you. Free checks and new accounts aren't open yet.

One screen. Three kinds of attention.Illustrative

  1. DesignBack and Confirm visit have the same visual weight.
  2. UsabilityTime choices show 9:00 and 9:30 without a time zone.
  3. AccessibilityIn the illustrated trace, Tab skips the date and time controls.
See the issues, fixes and recheck
A fictional booking screen in Fieldday, read for three concerns. Back and Confirm visit have the same visual weight; the time choices show no time zone; and in the illustrated keyboard trace, Tab goes from Work email straight to the buttons, past Choose a day and Choose a time.

Between building and releasing

Built it? Now look at the experience.

Whether you design and code, or code and make design decisions, review what runs against what you intended.

  1. 01Bring a working interface

    A browser prototype, a preview, or your product.

    Share a running address and the task that matters. Agree access and safe actions before the review.

  2. 02Decide what needs attention

    See the screen. Understand the concern.

    Design hierarchy, usability and accessibility are read together on the same screen. Evidence and interpretation stay distinct.

  3. 03Make the change, then recheck

    Give your agent the why, not just the ticket.

    Choose fixes, review the brief, then compare the changed experience before release.

AI helps you look. You make the call.

Reviewing the running experience matters when code moves quickly. Variantly proposes concerns to investigate; you decide what fits your intent.

Evidence, with limits

AI attempts aren’t people. They don’t predict how many customers will struggle, or replace research with people, including disabled people. Design recommendations are interpretations. Accessibility checks have a stated coverage, not a blanket pass.

How it works

See an example review: inviting a teammate

One review, from intent to change

Three concerns. One experience.

Each concern keeps its evidence, a person’s decision and the brief your coding agent reads. A recheck compares the changed screen.

  1. 1Design

    Back and Confirm visit have the same visual weight.

    Design interpretation
    Decision
    Fix it
    Brief
    Use one primary action; keep Back quiet.
    Recheck
    Confirm visit leads; Back is quiet. Design review needed
  2. 2Usability

    Time choices show 9:00 and 9:30 without a time zone.

    Usability concern
    Decision
    Fix it
    Brief
    Name the time zone before selection and in the saved visit.
    Recheck
    Europe/Berlin appears beside the choices and in the confirmation. Screen observation changed
  3. 3Accessibility

    In the illustrated trace, Tab skips the date and time controls.

    Synthetic observation
    Decision
    Fix it
    Brief
    Make the day and time controls keyboard reachable, with visible focus.
    Recheck
    The illustrated keyboard route reaches both controls, with visible focus. Original obstacle not observed

After the proposed changeIllustrative

The same Fieldday booking screen after the proposed change: Confirm visit is the one primary action, Europe/Berlin is named beside the time choices, and the illustrated keyboard route reaches Choose a day and Choose a time with a visible focus ring.

Illustrative: no review ran, and a changed observation never approves a design.

Some problems don’t slow people down. They stop them.

Accessibility is checked on the same screens, in the same run, and decided in the same place.

Accessibility

Safe to point at your live product.

You set where it goes and what it may do. Everything else is off.

How we handle your data

  • Only where you say

    It visits only the addresses you list.

  • Never pays; deletes only if you allow it

    It never sends checkout, billing or password forms.

  • Passwords sealed

    Sealed when saved and opened only to sign in.

  • Private by default

    Nothing is public unless you publish a report.

Questions teams ask first.

How is this different from end-to-end tests?

A script checks that its steps still work. An attempt is given the goal, not the steps, so it finds the wrong turns, unclear labels and dead ends a script walks straight past.

Can I trust what the AI finds?

Every issue keeps its screens, the step and what a screen reader would announce, so you can check it yourself. AI proposes; a person decides each issue. Nothing closes on its own.

Is an attempt the same as research with people?

No. An attempt shows where to look. When an issue needs real people, choose Not sure yet, and it keeps the question to ask them.

Will it change data on my live site?

Only if you let it. Signed in, it may submit the forms you allow, with email addresses at your own domains only. Use a staging site if you’d rather it touched nothing real.

Does it work on pages behind a login?

Yes, with a test account or a staging site. That’s where most tasks that matter live.

Find what’s in your customers’ way.

Paste your site, pick a task, and see every screen where an attempt got stuck. You decide what gets fixed.

Observed

A reply by email about what the review will cover.

One task, reviewed free. We’ll reply by email to agree what it covers.

Or hear when accounts open.

One email, when Variantly opens