Bad Pattern: Pre-Scolding

Here’s a crappy little form field pattern I encountered a few days ago. I haven’t seen it mentioned anywhere yet, so I’m claiming naming rights and calling it “pre-scolding.”

I’m sure you’ve encountered something like it: you’re filling in a website or app form, you enter a particular field set – in my example, it’s a DOB field set – and the second you enter what is definitely valid data, you’re scolded with flaming red error indicators.

Notifying users of an error as quickly as possible – that is, without waiting for them to submit the whole dang form – is a good practice. But this is an overzealous application of the principle. A better and more common pattern would be to validate input and flag errors when the user leaves the last field of a set. The way this validation scheme is working, I feel like I’m being scolded before I’ve actually made a mistake. In other words, I’m being pre-scolded.

One situation where the pre-scolding pattern might be useful is when the field asks for a password with complexity requirements. In that case, flagging the field as errored upon entry and until the user satisfies the complexity rules is actually a good practice. This can also be done with dynamically refreshing content and strength meters. Here’s one example:

As you can see, the interaction make use of both textual guidance and color to guide the user toward creating a stronger password. Thanks to Misha Rudrastyh for the example.

But before you run off implementing password strength indicators everywhere, you might want to give this article a read.