The “design engineer” role should go beyond front-end | Josef Richter

1){history.back();return false}}catch(e){}">

Design engineering · One interaction, followed all the way down

The "design engineer" role should go beyond front-end

The industry currently narrows down a design engineer to a "designer who ships AI-generated front-end". Let's aim higher than that, and let me take you on a fascinating trip behind a simple password input.

Josef Richter

Type something into this. It is the main subject of the post.

Password

✓ 8 characters minimum

✓ One uppercase character

✓ One number

The evidenceWhere did this come from

This pattern is one of the better-evidenced things in interface design.

The “after” condition from the study itself. Each field resolves on its own as it is filled in.<br>From Real-Time<br>Feedback in Web Forms: After version, recorded by Luke Wroblewski, 2009.

In 2009, Luke Wroblewski published<br>Inline<br>Validation in Web Forms on A List Apart, reporting a study that compared the then-standard<br>approach (validate form after submit) against inline validation (validate as you go). Same form, same fields , same<br>people. The inline version produced:

+22%successful completions

−22%errors made

−42%completion time

+31%satisfaction rating

−47%eye fixations

The study had 22 participants and six variations of the form; these are the reported differences between the best-performing inline version and the control.

These numbers are massive. That's the kind of difference that can turn into real BIG MONEY—and as designers, we should never forget we're designing for impact . But this was a small usability study, not a production A/B test, so it would be a mistake to read it as “inline validation increases signups by 22%” everywhere.

That last number is especially interesting for designers. Fewer eye fixations mean less confused jumping around the page, figuring out what went wrong. It's a useful proxy for visual effort , not a direct measurement of cognitive load.

And the qualitative finding: users did not just need to know that something was<br>wrong. They needed to know what was wrong , while they could still do something about it.

The study also found that timing matters : showing errors before somebody has finished can be worse than waiting. The positive checklist here is a slightly different interaction—it shows progress as rules become true instead of declaring the unfinished value wrong.<br>Note: the research is from 2009, yet you still find plenty of sites that do just post-submit validation in 2026. And if they wipe your form on error, that's the tableflip moment.

The craftTaking the design to another level

Mailchimp redesigned their signup around 2012. They printed all the individual rules under the field, and checked them off as you type. You are<br>not being corrected, you are reading instructions and following them.

Mailchimp’s version: five rules listed before you type, each resolving on its own. Via<br>GoodUX<br>on Mailchimp’s real-time password checker. They still use a similar version to this day.

Nothing in the 2009 study asked<br>for that. It measured completions, errors and eye movements, and had no opinion about whether feedback should<br>be pleasant. But resolving each rule separately turns the list from a set of demands into something closer to<br>a progress bar , and that is most of why people remember this particular component.<br>Up until here it's the "design" portion of the "design engineer" job. A fantastic design case study, where quality research found a goldmine, and was further refined to a delightful experience (well, turning an annoying step into an almost pleasant one).

A note before we build : these password rules are here because they make a beautifully visible demo, not because they are current password-policy advice. Modern guidance leans toward length, blocklists and password-manager support instead of forced uppercase-and-number composition rules. And many products now avoid password creation altogether with magic links, social login or passkeys.

Now comes the "engineer" part. Because it turns out it's not so easy . And it ultimately takes us on a fascinating journey through web technologies, and even deeper.

← Design

Requirement oneIt has to happen as you type

Not on submit, not on blur. Every keystroke.

So something has to run on each keypress that does three things in order:

Read the current value.

Evaluate it against the rules.

Update the interface to match.

Those are three distinct jobs and only the second one is validation. The other two are the hard part.

Back in 2009 you would already be reaching for jQuery, the library that had become the default way to find<br>elements and manipulate the DOM without minding which browser you were in.

the checklist, in jQuery<br>$("#password").keyup(function () {<br>var value = $(this).val();

$("#rule-length").toggleClass("ok", value.length >= 8);<br>$("#rule-upper").toggleClass("ok",...