Review a flow as a designer
A task review starts from what you meant someone to do and shows the screens an attempt saw, in order. You decide what each finding means, then hand a brief to whoever changes it. Review a task covers every field.
1. Set what the flow should do
On Tasks, choose Describe a task. Write what someone needs to get done in their words, like “invite a teammate with the right access”, and where they start. Then say how someone would know it worked. Variantly turns your words into checks on the attempt’s last screen, and you confirm them. This is your intended behavior, in a form the browser can test.
Add the perspectives you want it attempted from, such as a new administrator. A trait you type is marked “assumed”. A perspective shapes how an attempt explores. It isn’t evidence that people behave that way.
2. Read the screens in order
Run the review. When it finishes, the top of the page counts what was found: the expected-result check, usability findings, and accessibility findings from rule checks. Under Needs a decision, findings are ordered blocking, improve, investigate, and each says which perspectives and how many attempts it was seen in.
Open a finding and its evidence opens in place: the cited screenshots and steps, what was observed, why it may matter, what to change, and a question for people. Open an attempt to step through its path, with the screenshot beside each step. Read What this review didn’t cover before you draw a conclusion from a quiet result.
3. Decide each finding
The decision panel stays beside the evidence. Choose one:
- Act on it: change the interface, then recheck. This stays disabled until you have opened the evidence.
- Check with people: the question needs research with people.
- Intended behavior: it works as designed.
Each choice needs a reason. It is kept with your name and the date, and earlier decisions stay in the log. Calling a usability finding intended behavior never hides an accessibility finding on the same screen.
4. Hand off and recheck
Copy brief gives a designer, engineer or coding agent the finding, links to its evidence, the proposed change and the recheck condition, as text. After the change, choose Recheck this on the finding. A fresh attempt runs for the same condition, and the original and new screens sit side by side with the result: seen, not seen, couldn’t tell or not checked. If the new attempt took another path, the page says it doesn’t show the condition is gone.
What a review can’t tell you
Attempts are AI, not people. Their findings are interpretation from the screens. They don’t say how many customers hit a problem, whether they would convert, or how they feel. Use them to inspect the interface and choose what to take to research with people.