Review the redesigned task

A task kit for design, usability and accessibility review. Read and adapt it without an account.

Use an approved staging site and synthetic data. A human or an agent can use this brief; an AI attempt supplies evidence to inspect and hypotheses to investigate. It does not stand in for research with people.

A task brief to adapt

Replace the starting URL, synthetic values and permitted actions with your own approved boundaries. Keep the outcome; leave the click sequence open.

Starting state: Signed in as a project editor on the dashboard. Practice exists with the same initial description in separate, equivalent fixtures for the old and new builds.

Goal: Find the saved project Practice and change its description to Ready for review.

Observable success: Practice shows Ready for review after reload, with no change to another project. The interface makes the saved state distinguishable from an unsaved draft.

Conditions: Use the same browser, account role, fixture, goal and entry route on both builds. Compare desktop, 390px mobile width, keyboard-only and 200% zoom separately. Record build identifiers. A person reviews changed semantics with their screen reader.

Permitted actions: Use only the two approved staging builds. Edit the description of the supplied disposable project. Do not delete projects, change permissions, overwrite another fixture or use production data. Restore each fixture through its approved setup before another attempt.

7 checks to make

1. Hold the comparison steady. Verify the starting records, role and product state match. A different fixture or permission level is a confound, not evidence that the redesign helped.
2. Find the task entry. Start from the dashboard on each build without click instructions. Record whether the visible label and accessible name point to the intended project.
3. Keep editing discoverable. Check how the description is opened and edited. If an icon replaced a label, inspect its accessible name and visible explanation.
4. Protect the draft. Use a separate interruption case: leave and return before saving. Check that the interface explains what will be lost and offers a usable way to stay.
5. Identify saved versus unsaved. Inspect the text and focus after saving, then reload. Record whether a disabled save control or changed label explains the state without relying on color.
6. Preserve access at small widths. Check the new layout at mobile width and zoom for clipped controls, changed reading order and sticky panels covering focus.
7. Compare evidence, then propose. Keep each build's screenshot, actions, focus path and outcome together. Separate a reproduced obstacle from an AI preference about layout or copy.

Worked illustrative evidence

Fictional example. These records were written to explain the review. They are not captured screens, customer results or a run of Variantly.

For a real review, retain the starting state, build, condition, action and outcome beside each screen. Include the accessible names, focus trace and rule output where available; mark missing evidence as unchecked. A person's screen-reader check is separate evidence.

A product change to consider

Proposed change: Retain a named edit action and show saved-state feedback beside the edited description. Keep the logical focus destination visible when the layout collapses on mobile.

The new information architecture can stay while the task retains its recognizable entry and outcome. Judge a redesign against what a person needs to do; decorative preference is insufficient reason to revert it.

A person decides

A designer and product owner inspect the paired records. Fix reproduced name or focus obstacles; keep wider layout claims Not sure yet until a matched participant study. Record Working as intended only with the tradeoff and remaining access path explained.

What to recheck

Run the same task on the changed build with equivalent reset fixtures. Verify the accessible name, visible keyboard focus, local saved feedback and persisted description at each width. Keep the old-build record as context and state which conditions were not repeated.

A recheck records whether the condition was seen again, not seen, not checked or couldn't tell. A person decides whether the issue is resolved.

What this task leaves open

One matched task does not establish overall redesign quality, preference, conversion or human completion rates. Different model behavior across attempts can also change the route taken. Supplement browser evidence with people and native assistive-technology checks.

Keep task-review findings separate from accessibility report rows. These kits make no claim of human fidelity, conversion uplift or conformance certification.

Go deeper

• Read Designed twice
• Keep the task goal constant
• Focus Not Obscured (Minimum)

Choose another task kit or ask for review of a task on your product. The request starts a conversation about coverage; it does not start an automated run.