Last week, I had a meeting with two devs and two designers.

The meeting’s purpose was to let developers raise problems and get quick design decisions. One of the devs brought up an issue with a form that had conditional radio buttons.

Here’s what the screen looked like (it’s a bit different to what I’m actually working on but close enough):

When the user selects “Yes” it reveals a field to enter the name:

If you leave it blank and submit the form, the page refreshes and shows an error:

So far so simple.

But then if you select “no” it looks like this:

The developer was concerned that:

• The error link will be broken because when you click it it won’t go anywhere
• The user may think there’s an error to fix when there isn’t one

Seems like a sensible concern, right?

The obvious fix would be to hide the error summary when the user selects “No” which is what one of the other designers suggested.

But this creates 5 usability issues (that are worse than just keeping the error summary on screen):

Issue #1: Errors only appear after submission — they stay visible until the user submits again. So hiding them dynamically breaks that model and may confuse users unnecessarily.

Issue #2: If there are multiple errors, you’d need to hide the specific one inside the summary, not the whole thing. This may be disconcerting as you see an error disappear (and the error summary change size) in your peripheral vision.

Issue #3: The page will jump as the error summary disappears. For example, as you select “No”, it will suddenly move up from where you just clicked. It may disappear off screen. And the same may happen in reverse if you select “Yes”.

Issue #4: Screen readers could announce something like “You no longer need to fix the name error,” but that just interrupts users to tell them something they already know.

Issue #5: It’s more work to design, spec, build and maintain.

But instead of debating whether to hide the error, we should have first asked ourselves if it’s even a problem.

To work this out, you have to consider what the user did and what they’re intent was.

In this case the user changed their answer from “yes” to “no” which means the name field is no longer relevant to them. They’ve already moved past the error summary and won’t pay it any attention now.

For the user to be confused, they would have to forget what they just did, scroll back up, see the error summary, notice the old error, try and finally, click the error link that is no longer relevant as a result of their very own action.

And if they were confused, it would likely be temporary.

But in reality, 99% of users (or more!) won’t do any of that - they’ll just select “No” and submit the form without an issue.

So while I acknowledge that this is not a perfect solution, it’s fine - the trade offs to “fix” it are far worse than just leaving it as is.

So that’s what we did.

If you’d like to design forms that acknowledge that sometimes there’s no perfect solution – but that most of the time there is a simple, boring and perfect solution – and you’d like to see what those simple, boring and perfect solutions are, then you might like my course, Form Design Mastery:

​https://formdesignmastery.com​

Cheers,
Adam