What you’ll make
A short record of one launch path you tried from start to finish.
What happens when the email request fails?
A small banner gets in the way of a free sample
Say the sample request works every time you try it on your laptop. Before I put the link out, I’d try it on my phone and make the request fail on purpose. That’s where this shop found the problem.
Issue on the test build
The banner covers the error on a phone
- Start on the sample page at 390 px with the bottom banner open.
- Enter an email and force a failed request in staging.
- Expected · See the error and try again. Actual · The banner covers the message. Tabbing to the banner’s close button gives no visible focus.
Retest on the next build
See the message and get the sample
- The error now sits above ‘Email me the sample’ and the close button has a visible focus ring.
- At 390 px, the address stays in the field after the error. A retry sends an email, and its link opens the PDF.
- At 1280 px, the page still sends the link. A keyboard user can close the banner and finish the form.
Before you start
- Save the preview link and build name or date. Have a phone and a desktop browser handy. Write down what a finished task looks like.
- Use a test account or staging preview for forms, downloads, or checkout. Grab the sample details you’ll enter and find a way to try an empty screen or an error if the flow has one.
Pick one path that needs to work
Open your test preview. Write down what a visitor starts with, what they tap, and how you’ll know they got what was promised. Use sample data or a test address.
Run the path in the browser
Start at the entry screen on a phone-sized view. Follow the route once and check the actual result. Try the same route with the keyboard. If you have a safe way to cause a failure, see what it tells you to do next.
Record the first problem you can show
Keep the screen width, exact steps, what you expected, and what happened. Mark anything your preview can’t do yet.
On the free sample page, I force a failed request at 390 px with the banner open.
The banner covers the error. I save that screenshot and write down the steps so I can find the same spot again.
Run the same check after the fix
Start with the same screen, test address, and width. Repeat the action that failed, then follow the whole path to the promised result. Save the record with the version you tested.
- Check the action and result at phone width.
- Use the main controls with the keyboard.
- Save a pass, fail, or untested note for the route.
Optional: Check another route before launch
Choose a second route people will rely on, such as getting the download after checkout. Start with a clean test account and record the exact screen and input for anything you need to fix.
Make me a launch test I can actually run
Use this with the preview and main visitor task to get a checklist with a clear finish line.
I’m about to launch [site and build]. Here’s [preview or screenshots]. The main thing a visitor needs to do is [task from entry to result]. I have [devices, widths, browsers, staging access, and sample inputs]. Make a short test sheet for structure and the main action, readability and zoom, responsive layout, keyboard and labels, and the complete task. Give every test a starting state, exact actions, and a visible expected result. Include one invalid input and one failure or retry if the task sends data. Tell me where to use a test account or staging and how to tell if the final email, file, or confirmation is actually correct. If you can’t see the preview or a state needs access I haven’t supplied, mark that row for me to run. Leave a spot to record device, build, evidence, and result.
Turn these observations into fixes I can reproduce
Use this with screenshots and notes from your audit to get a prioritized issue log.
Here are [notes, captures, build, and devices]. The visitor task is [task]. Make a table with route and device, starting state, exact steps, expected result, observed result, and evidence. Group repeats when the same cause is supported and keep each affected width. Put blocked tasks and broken recovery first, followed by things that slow people down or confuse them. Give one small proposed fix for each confirmed issue. If the notes don’t establish the cause or omit a step, show what I need to reproduce it before deciding what to change.
Write the retest for the fixed build
Use this after fixing an issue to rerun the original failure and the whole route.
Here are [original issues and steps] and [fix summary, new build, and test setup]. Write a retest list I can run from a clean start using the same devices and inputs. For each issue give the original action, expected result, and what evidence to save. Include a nearby control or layout check if the change could affect it. End with the full main task on phone and desktop and a keyboard pass through the affected route. Give me a row to record pass, fail, or untested and the build I actually used.
Optional worksheet: Prelaunch audit worksheet
Fill this in as you go. Keep this page open while you work. Reloading it clears your answers.
Troubleshooting
What if it only happens on my phone?
Write down the phone, browser, and orientation. Check whether the on-screen keyboard or browser bar is open. Record it and try the same setup on the fixed build.
What if my checker gives the page a pass?
Try the whole task with touch and then a keyboard. Check that the labels make sense, the focus stays visible, and the final link takes you to the right place.