During a redesign of our product, we discovered that error messages for specific fields were painful to use. So, we decided to redesign the experience.
Duration: 2 weeks
Methods: Discovery, analysis, prototyping, moderated usability testing
Tools: Figma, Webex, Trello
Context
Several data points in our application have strict formatting or uniqueness requirements. Messages regarding formatting and duplicate checks popped up in a modal, disconnected from the data points. The text was confusing and the different parts of the message were spread apart, making reading difficult.
Duplication messages didn’t include a way to navigate to duplicate records. This meant that the user would have to leave their work-in-progress to find out if the record already existed in the system.
Our users are data management experts who need to be both efficient and accurate as they enter and check data. The current design wasn’t helping them reach those goals.
Process
First, I researched design patterns and came up with three typical patterns for validating data: asynchronous validation, inline validation, and masking. In asynchronous validation, error messages are triggered by an action, such as clicking ‘Save’ or ‘Submit’. Inline validation is displayed next to each field as the user types. Masking formats the data as it is entered, preventing bad data from being entered in the first place. Each type of validation is appropriate for different contexts, although research shows that inline validation is easier, less frustrating, and more efficient to use than asynchronous validation. And masking is more effective than instructional text in ensuring correct data entry.
Asynchronous validation is best used for validation checks that take too long or are too resource-heavy to run inline. Working with industry best practices, I set a time limit of 5 seconds for asynchronous validation checks – anything faster than that could be displayed inline. Then, I collaborated with the development team to establish that all of our duplication and formatting checks were faster than the cutoff.
Next, I identified the fields that had strict, easily defined formats and wrote masking requirements for those fields. Our UI library, PrimeNG, provides this ability OOTB. A few remaining fields required more complex formatting, so I defined inline messages for those.
The last validation to tackle was the duplicate checking. Some fields needed strict duplicate matching, while others generated a warning, still allowing the user to save. I designed inline messages for both scenarios, including links to the duplicate records and careful microcopy. The messages appeared after the user exited the field, and disappeared when they began typing a new value. I also designed a success message to reassure the user that the value they entered was unique.
Lessons Learned
After implementation, we ran into an edge case that we hadn’t considered. Showing validation when the user clicked away from the field worked fine with data entry, but the message didn’t appear if the user was editing an existing record with faulty or missing data. We modified the requirement to also run validation when the user started editing and display any pre-existing errors up front.
Another hiccup was that one of the fields I identified for masking actually had another variation I didn’t know about. The faulty format made it through requirement reviews and QC before our domain expert spotted it. It turned out that my source for the field’s format was outdated – oops! Regardless of how much you’ve tested a design, always run it past an expert who can verify the details.
Impact
With this approach, we were able to significantly improve error-checking UX. Usability testing the new design showed that users easily understood both the inline messages and masking patterns. One user even expressed delight: “I don’t expect [to have a duplicate value], but I’m glad the system is checking it. And I like that the message shows up right away! Usually it would pop up when I submit.”
The feature hasn’t yet been rolled out to end users, but it was a talking point in sales discussions. And, this pattern can be extended in the future to tackle any formatting or checking needed by a client. Taking initiative to solve this issue translated into enhanced business value for both Kingland and our clients.