Development Challenges, Design Solutions

As a Developer, I want to solve problems. After a decade of solving problems, it could become easy to consider daily tasks as ‘problems’ that need solving, rather than opportunities to innovate with design. There is a better mindset..


I was moved to write a post this morning (After somewhat of a hiatus) when I noticed a tweet from Ryan Florence pointing out a frustrating interaction with Input fields which is likely familiar to many of us:

Shared by Ryan Florence (@ryanflorence)

In a Nutshell – The error message that appears here is to inform us that there are certain requirements around email formatting, but friction is introduced into the conversation because the message is presented when the user attempts to type into the field.

I refer to this interaction as a conversation not only because that’s how I like to think about UI, but also because it is so fitting in this scenario.

Nobody want’s to be interrupted mid-sentence and told that what they’re saying is erroneous, even when it is! It’s not very polite.

A technical Red Herring

It would be easy for a Developer to fall into a trap at this point. Why not move the prompt to the <input>‘s blur event – That would be less abrasive.. right? No, we can do better. Look at the content of this message..

‘Email address must be populated, follow the format, and cannot contain special characters.’

That’s not strictly an error message and however you feel about what is polite and what isn’t, there is a more proactive way to approach this situation that I want to share.

Prevention over Cure

First of all, here is a replication of the problem:

See the Pen Proactive UX 1 by Danny Chambers (@DannyClaydenChambers) on CodePen.

No bueno.

A better example

For the sake of comparison, let’s look at an example of this interaction as I might solve it with the Red Herring approach above.

In the following Codepen I have created an equivalent UI but softened the interaction, moving the prompt from the fields Keyup event to its Blur event. You will notice I have also given the error message an animation effect to lighten it’s impact. These kinds of subtleties can go a long way in changing what was once an interruption into a suggestion.

See the Pen Proactive UX 2 by Danny Chambers (@DannyClaydenChambers) on CodePen.

Better still

Above we noted that the message itself is not strictly an error message. In this version I have interpreted it as information that can provide context rather than friction to the conversation. Supporting the user as they engage with the field using the focus trigger.

See the Pen Proactive UX 3 by Danny Chambers (@DannyClaydenChambers) on CodePen.


This is what I would recommend – No need to over engineer, let’s just make the guidance persistent next to the field. This should reduce visual disruption for the user, not to mention no reliance on JavaScript!

See the Pen Proactive UX 4 by Danny Chambers (@DannyClaydenChambers) on CodePen.


Isn’t this all so obvious? Well, yes it is..

But the point really is that it’s important for User Experience to be a consideration of Development and Development (Opportunity, not only restriction) to be a consideration of UX Design.

Not every development ‘problem’ needs to be solved technically and design challenges can absolutely benefit from technology!