Show composition rules before typing starts
Aliases: password policy visibility · composition rules up front
What it is
If the password field waits until submit to say “must include uppercase, a digit, and a symbol,” the person has already planned a string and is sent back. Showing rules before typing means the constraints are visible when the field is focused (or earlier), and as the person types only unmet items stay marked—not a post-hoc “does not meet requirements.” This entry is about when rules are visible. It is not about whether the rules are too strict, and not about whether paste is allowed.
Why it happens
Choosing a password is planning: retrieve or generate a candidate, then trim it to the rules. Rules after submit turn planning into trial-and-error. Each failure rewrites the secret in working memory; what remains is often a predictable patch such as appending 1!. Showing rules first makes them an input to planning, not a verdict. Live checkmarks (length met, digit still missing) turn a legal paragraph into a completable list and cut guessing about which clause failed. Rules parked in a help link away from the field are not shown in advance—they are invisible at the point of typing.
Studying it
Compare “rules only after submit,” “rules listed on focus,” and “per-item live satisfaction,” looking at attempt counts and the structure of the final secret.
Independent variables: when rules first appear, per-item checkmarks, whether failure copy is a blanket or names unmet items. Dependent variables: failed submits, rate of characters appended at the end, time to finish, ability to recap every rule without submitting.
Labs often issue throwaway accounts, so people type a fixed test string that already fits, and interrupted planning never appears. Use the person’s own password strategy (or a manager’s generator) to see patching after late rules. Faster completion with live marks is not evidence of a stronger secret—speed and structure are separate. NIST SP 800-63B discusses whether composition rules should exist at all; if a product still keeps them, visibility is an independent variable.
Where it stops holding
When a password manager generates and fills, people may never look at the list; it still matters at failure, which must name the clause that collided with the generator (for example a banned symbol). A single “at least 8 characters” rule can be repeated in the placeholder; it does not need a dashboard. A sign-in field is not a choose-password field: sign-in failure must not display the registration composition list, which would extra-inform a bystander. Screen-reader users need the rules programmatically tied to the field; green icons below the box are not enough.
Applying it
- Show every constraint that will be enforced when the password field is focused, as a list; check off met items while typing, and on submit highlight only what remains unmet.
- Generate the copy from the same source as the validator; help-center text and front-end checks must not diverge.
- Do not restate composition rules on the sign-in page; the choose-password and reset pages share one ahead-of-time list.
- Verify by asking someone uninvolved in the design to state every rule without submitting; then violate exactly one clause and submit, and check that feedback points at that clause rather than “password does not meet requirements.” From recordings, count how many people changed the candidate before the first submit—successful advance display should move most planning before that submit.