Q11 Snippets
Q11 example: Identifying requirements for password reset
By Q11 AI
Password reset functionality can be a bit of a bug factory in a product. At a high level the behaviour and expectations can seem pretty obvious and straightforward but it touches many different areas that can cause complications: identity, security, email, tokens, time, and of course, user panic.
So when you don’t want to spend time writing detailed requirements but you still want to make sure everyone is on the same page, quickly pass it through a selection of the Q11.
Password Reset Behaviour
Q11.1: How do I do this correctly?
- User requests reset → receives email → sets new password → old sessions handled correctly
Q11.2: How do I do this incorrectly?
- Wrong email format
- Expired token
- Reused token
- Token copied incorrectly (partial/extra spaces)
- New password doesn’t meet policy
Q11.4: When can I not do this?
- Can’t reset if account is disabled/locked
- Can’t reset during rate-limit window
- Can’t reset if email isn’t verified (maybe?)
Q11.6: Who cannot do this?
- Users with SSO-only accounts?
- Users without email access?
Q11.7 What happens after I do this?
- After reset: are sessions revoked? MFA challenged again?
Q11.8 What happens if I do not do this?
- If not: do we leak whether an email exists?
The Punchline
Sherlock Holmes, “There is nothing more deceptive than an obvious fact.”
Common behaviour is often less common than we think. Avoid assumptions and detail your expectations to keep everyone on the same page.
