I keep coming back to UI Workflows because it exposes how teams think under pressure. When the release clock gets louder, the weakest assumptions get louder too.
My checklist for UI Workflows is not meant to turn testing into box-ticking. It exists so pressure does not erase the few important questions that protect multi-step journeys, transitions, and the points where users hesitate or recover. The reason I stay alert here is simple: every screen works in isolation, but the full journey breaks when state travels between steps.
A good checklist keeps important risk visible when the room gets busy.
Before I Start
- Make the change area explicit
- Write down the most expensive failure in one sentence
- Confirm which designers, product managers, and front-end engineers should review open risk
- Choose the environment that will tell the truth fastest
During the Check
- Exercise the normal path that should protect multi-step journeys, transitions, and the points where users hesitate or recover
- Run an awkward-path example based on a checkout wizard that saves progress on step two and quietly loses it on step four
- Watch for mismatches between visible success and hidden state
- Capture the one detail that will matter during sign-off later
Before I Close the Work
I finish by asking whether the evidence would still make sense to someone who was not present during testing. For this topic, the evidence I want usually looks like end-to-end walkthroughs with real user choices, backtracking, and interrupted sessions.
If the answer is yes, the checklist did its job. If the answer is no, I am not done yet. That is the point where QA stops being ceremony and starts helping the team decide well.