3

enter image description here

I'm currently redesigning an onboarding flow and i've come to this question with an engineer about designing an error message form field box that persists in our fixed header. This would of course be in conjunction with inline error states on the actual field itself.

The form field box will act exactly as many notifications boxes act within a webapp/native app. The only difference is that this will consistently show the user what the issue is until they either fix it or close the box.

I'm curious as to why this isn't done more often and instead the message is moreso always closer to the "submit" or "continue" button.

1

I would like to quote here few things i have learned from book "Designing with the mind in mind Simple Guide to Understanding UI Design Guidelines"

First Factor: When we are filling form fields, our eyes are focused on the current area/field of that form..What is not in our eyes current focal point is all blurry and meaningless until something moves or pops up somewhere else

Our Peripheral Vision only detects motions and see everything in blur mode. So error messages, or status should be close enough to the area where user is focusing.

*** I forgot the exact Milimeters our eye can focus while we are focusing on something but its a small number

Second factor is Chunking Information/Grouping related items should stay together. So if error is related to a form on the page then it should be in that form, not in the header of that page...

This is the same reason we do a Eye Sqeeeze test to see what item on page is highlighted and which is not (In case of landing pages)

These are basically guidelines of UI Design but most of us ignore and try to invent new ways to show information

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.