Release review · 9 checks · use with your project

Before you ship your frontend

An interface that works beyond the demo.

For reviewing an interface, including one generated with AI. Nine checks on a real user flow: record what you tested, what blocks release and what you accept shipping.

Your answers stay on this page. They are neither sent nor automatically saved. Download your work before closing or reloading the page.

0 / 9 answers filled in

1. Which flow and version are you testing?

Record the URL, version, browser and steps from the starting point to the expected outcome. Use test data.

Fictional example: a booking form

Staging, version abc123, Edge on Windows. Select a slot → enter test contact details → confirm → find the booking.

2. Does the complete flow work?

Perform the final action. Also check back navigation, reload and opening the URL directly. Record expected / actual / reproduction steps.

Fictional example: a booking form

After reload, the summary still shows the booking details. Going back keeps the selected slot.

3. What happens while waiting or when a request fails?

Simulate a slow network, a failed request and an empty result. Check the message, retained inputs and retry option.

Fictional example: a booking form

Network disconnected during confirmation: inputs remain and a button allows retrying. No false success message.

4. Does it remain usable on mobile and when zoomed?

Test at 320 px, on your phone with its keyboard open and at 200% browser zoom. Look for clipped content, hidden actions and obstructive horizontal scrolling.

Fictional example: a booking form

At 320 px, the date wraps across lines. With the keyboard open, I can reach the error message and button.

5. Can the entire flow be completed with a keyboard?

Use Tab, Shift + Tab, Enter and Escape as appropriate for each control. Follow visible focus. Check order, dialog closing and focus return.

Fictional example: a booking form

I select a slot without a mouse. Escape closes the dialog and returns focus to the button that opened it.

6. Are fields, errors and images understandable?

Check associated field labels, errors that explain how to fix the problem, alternatives for meaningful images and contrast. Colour alone should not convey information.

Fictional example: a booking form

“Invalid email address: use name@example.com” is associated with the field. It is not just outlined in red.

7. Are data and sensitive actions protected?

Using test accounts, check that the server controls data access. Look for exposed frontend secrets and unnecessary personal data in logs. Check what a double click does.

Fictional example: a booking form

One test account cannot read another’s booking. A double click does not create two bookings. No private token in shipped code.

8. What do tools report, and what did you check manually?

Review console and network requests, run relevant tests and an accessibility tool. Record errors, oversized images and testing limits. An automated score is not enough.

Fictional example: a booking form

Form tests pass. A 3 MB image slows mobile loading: compress it. Keyboard navigation checked; screen reader not tested yet.

9. What is your release decision?

Choose: ship / fix and retest / ask for review. Rank defects by impact. For each blocker: step, expected result, actual result and fix to verify.

Fictional example: a booking form

Fix and retest: on mobile, the keyboard hides the button. Repeat the full flow after the fix. Image compression is also planned before release.

Before using your result

Untested areas are identified.
Every blocker has reproduction steps.
This focused review does not replace a complete accessibility or security audit.

Your next step

First fix anything that prevents completing the flow or exposes data. Repeat the steps after fixing it, then keep this review with the released version.