Building UX for Error Validation Strategy

Error validation strategies are often neglected in the product design field, despite being crucial to ensuring a smooth user experience. While many designers understand the importance of well-designed “Sign In” and “Sign Up” pages with fully-covered username and password validation cases, a more in-depth and big-picture approach for the entire system is often overlooked. Although there is no shortage of information available on the importance of error validation types and patterns, building a comprehensive strategy for a large, complex product can be daunting. This can lead to anxiety, uncertainty, and many questions:

• Where should we begin?
• How can we create a cohesive and safe solution for the entire system?
• And perhaps most importantly, how can we effectively execute and maintain this strategy?

My story

As the lead product designer, I faced a significant challenge when transitioning the product from legacy code to new technology for the entire ecosystem. Despite a tight deadline and no access to users and analytics, my objective was to develop and execute a digital “happy path” that prioritized error prevention and recovery as a strategy.

The product was complex, comprising various services within the ecosystem, including the Service Management Platform (SMP) — a critical platform for admin users to manage system setup, entities and objects, users, permissions, feature enablement and workflows, as well as access and data governance controls across other applications. SMP is common for B2B applications and SaaS and is organized in terms of Information Architecture as a set of Entity List views and Object Configuration forms.

We understood our Admin Persona and their tasks primarily involve performing CRUD (create-read-update-delete) operations within entity objects. Each action served a specific purpose in managing the overall product, and a lot of activities occurred in Object Configuration form.

Our team recognized the need to implement a robust validation strategy with no room for failure or significant improvements post-implementation. It was a now-or-never challenge that demanded our best effort.

Let’s begin.

Part 1: Research

I’ve researched inline form validation extensively and gathered valuable insights I’d like to share with you. While I’ll provide a brief summary and key takeaways, I strongly recommend reading the articles I’ll be linking below for a more comprehensive understanding.

To make the information more organized and accessible, I’ve categorized it into three blocks for a well-rounded perspective:
1. Accessibility.
2. UX.
3. Development.

Block 1: Accessibility

If you are not ready to read the complete documentation, save it for later. But I urge you to consider the following part at least:

• WCAG guideline “3.3 Input Assistance” (3.3.1 to 3.3.6)

Here are the main takeaways:

✅ Always identify and describe errors to the user when they occur, and provide a solution to fix the error if possible. A standard approach is highlighting the field border in red and including a placeholder for the error text. This is a widely-used pattern that works well for most cases.

✅ Provide a clear visual indicator when user input is required. The most typical pattern for this is using an asterisk “*” to mark required fields or labeling them with the word “required”. However, be careful not to overload the user with too many indicators. Keep it simple and clear.

Block 2: UX

I would like to recommend reading the following excellent articles to dig deeper:

• Usability Testing of Inline Form Validation Study by Christian Holst (Baymard Institute)
• A Complete Guide To Live Validation UX by Vitaly Friedman
• Inline Validation in Web Forms by Luke Wroblewski
• Hostile Patterns in Error Messages and How to Report Errors in Forms: 10 Design Guidelines by Rachel Krause (Nielsen Norman Group)
• A Guide To Accessible Form Validation by Sandrina Pereira, Staff Frontend Engineer

After reviewing various sources on the topic, I’ve distilled a few critical considerations for UX designers:

✅ Familiarize yourself with the different patterns of validation: AFTERWARD (“on blur” in technical speak), WHILE (“on key press”), BEFORE AND WHILE (“on blur and on keypress”), SUBMIT (clicking on “Submit” or “Save” button).

✅ Avoid premature validation and only display error messages after an error has been made.

✅ Validate empty fields (required) only on submit to avoid interrupting the user’s flow.

✅ Use AFTERWARD (on blur) validation for optional fields.

✅ Make it easier for the users when possible, such as by allowing multiple inputs separated by commas or periods.

✅ Prioritize displaying severe errors sooner rather than later, but ensure the interruption is appreciated.

✅ Avoid disabled buttons and instead allow users to click buttons at any time, displaying error messages with instructions.

✅ Consider auto-focusing invalid inputs, particularly for long configuration forms, so the user doesn’t need to navigate to them manually.

Block 3: Development

Now let’s talk about development. While it may not be a designer’s area of expertise, it’s essential to have a basic understanding to ensure the system is feasible and stable while meeting HTML requirements and recommendations.

I recommend reading the following articles to gain insight:

• The HTML5 input types and Client-side form validation by Mozilla
• HTML5 Form Validation Examples

As a recap, UX Designer should consider here the following:

✅ Client vs. Server validation. Validation done in the browser is called client-side validation (AFTERWARD, WHILE, BEFORE AND WHILE), while validation done on the server is called server-side (upon “Submit”) validation. It’s essential to communicate with developers to determine when client or server validation is appropriate, as some validation can only be done on the server side, such as uniqueness and special data formats for some cases. Forcing client-side validation over server-side validation can result in poor performance and potentially compromise the system’s security and architecture.

✅ Understanding the basic input types and their parameters in HTML5 can help to accelerate design decisions and ensure that the experience aligns with development requirements. Common validation attributes, such as “required”, “minlength”, “maxlength”, “min”, “max”, “type”, and pattern, should be taken into consideration when designing the user input rules.

Part 2: Gathering product requirements

Now that we’ve completed our research, it’s time to gather the product requirements and see the big picture. This is where we could collaborate with our product manager to identify what user data we need and which format to collect across the system's various entities.

• Begin with the basics, such as User name, Address, Email, Password.
• Consider any restrictions on input, such as character limits or format validations.
• Look out for fields that require cross-validation attributes. For example, some fields may need a minimum length and a specific format validation.
• Identify which data is required (mandatory) for input.

Predicting the future can be challenging, and teams may struggle with forward-thinking. But that’s okay! We don’t need to come up with the exact set of fields for each entity. The goal is to understand and capture the broader perspective as much as possible. At the end of this exercise, we should have a draft list of possible user data input with corresponding requirements and restrictions.

If your team challenges to do this exercise, you could ask for Chat GPT assistance. Just give him the brief product details and request to come up with possible fields for user input. See the results below.

Sometimes Chat GPT can give you a hand.

While the initial concept is promising, there are some improvements we can make to tailor it more closely to our product’s needs and ensure clarity. After some adjustments, the concept can take the form shown in the image below, which we can bring into the next phase.

Part 3: Testing research takeaways

In order to evaluate the insights gathered from our research, we will create an imaginary form for a New User configuration that includes all the fields from our previous phase, imagining the worst-case scenario with the most complex possible structure. This exercise will help us determine the appropriate layout, design of text fields, and placement of error messages.

We will conduct three tests to assess our research assumptions collectively, with each test encompassing multiple assumptions.

• Test 1: Enabling “Save” button and displaying errors for required fields upon submit.
• Test 2. AFTERWARD validation.
• Test 3. Exploration of different validation patterns altogether.

Start point

Imaginary worst-case scenario of the user configuration form.

I’ve put together all of the fields we listed in the previous phase. Also, I add more inputs to make it closer to reality just a little in order to add complexity. This concept layout features components from our company’s design system.

At this stage, I am good with how it looks so far. Let’s start to test it!

Test 1: Enabling “Save” button and displaying errors for required fields upon submit

This GIF demonstrates a scenario in which all required fields are left empty, and the validation message appears upon clicking the “Save” button.

Examining the validation of required fields upon submit in the prototype.

But as we begin validating one assumption, more questions arise. Let’s take a moment to review our progress.

✅ Enabling the “Save” button and validating required fields upon submission is a strong approach. It helps prevent premature error messages and reduces user anxiety when the primary button is disabled without indication.

✅ Alongside the main objective, we also had to tackle the question of how to display error messages on the UI. For our product, we agreed to use a two-column layout as it allows for more data to be displayed on one screen, which is crucial for our personas. When it comes to handling error messages in this layout, I always prioritize creating an unbreakable and solid UI that can respond to dynamic content. In the case of error messages, I recommend not limiting the message height and wrapping the text if it’s too long, considering the possibility of translation copy into different languages. Moreover, I decided to shift upcoming errors below within the whole row as the content is organized from left to right, top to bottom direction, and breaking the column could throw off the balance of the organization.

✅ I suggest implementing a common behavior where the error message disappears once the user fills in at least one character. This approach would enhance the user experience, and users wouldn’t be bothered with error messages once they start filling in the required fields.

Overall, I am satisfied with the results of this test, and I think we can proceed to examine the other assumptions.

Test 2: AFTERWARD validation

This test showcases a scenario where all fields fail validation due to different restrictions, and the appropriate error messages appear, followed by an AFTERWARD validation pattern.

Examining the AFTERWARD validation gathered all together in one mock.

This design needs improvement as it appears cluttered and overwhelming for a single view, even though it is an edge case. Furthermore, the experiment highlights that the user may suffer and lose focus quickly.

Let’s think about preventing user mistakes and improving the readability and neatness of the UI. In the next iteration, we need to address the following gaps:

⚠️ Profile and Media. The error messages are not clear due to limited space. We need to revise the UI to provide more specific error messages and clear solutions for the user to fix.

⚠️ First and Last names, Company, and Designation fields. My assumption here is that showing this validation for such inputs could be redundant. Is this necessary to know for the user precisely limit value? What if we can prevent user mistakes?

⚠️ Email field. Oops, a case with email confirmed status seems missing here and wasn’t executed.

⚠️ Description field. My hypothesis here is to keep the error message. We anticipate that users may enter longer content and value the effort users put into filling out forms. In addition to this, we can complement this field with a character counter. Thanks to Twitter, this feature is already popular as it helps users understand how many characters they have left.

⚠️ Password fields. The plain text of the error message gives no clue about the exact errors that the user possibly made. It would be beneficial to consider implementing interruptions earlier to prevent user mistakes.

⚠️ User rank and Date range fields. My assumption here corresponds with the one I brought for inputs max length validation. We could add logic that prevents users' mistakes here, especially from selecting an end date preceding the start date.

Other fields I didn’t mention look appropriate to me. Let’s continue.

Test 3: Exploration of different validation patterns altogether

How does uniqueness look with the required field if both validate on submit?

An ideal candidate to examine this is the email text field:

Examining different validation patterns in one field: Email.

✅ I think this behavior contributes to our goals, is aligned with the overall logic, and still keeps clear feedback for the user.

Across the board, I’m satisfied with the design system components and validation behavior we’ve checked. While there may be some minor issues with overlapping error messages, the system prevents users from saving the form until all errors are resolved, ensuring they don’t miss critical information. This behavior seems like a safe solution to me, and we are good to go.

Tip 1. Brainstorm all the scenarios that need to be tested before making a final decision. Create prototypes and explore them thoroughly, as demonstrated in the examples provided.

Tip 2. Don’t hesitate to share your first design iteration with your developers, even if you’re unhappy with it. They can provide valuable insights that you can evaluate during the second round of design.

Part 4: Second iteration

After addressing all the gaps identified in the previous round, I have implemented a more or less final layout that addresses all the issues raised in “Test 2: AFTERWARD validation”:

Examining the reworked version.

Contemplating all factors, I believe we are in an excellent position to move forward. Here are my reflections and results of the second iteration:

✅ Profile and Media. I decided to keep the same content organization and transitioned the error message to a toast notification. Although debatable, this input mechanism can be treated differently, and the design solution doesn’t change the layout significantly. However, be careful since this solution might not work well if you approach attachments within a modal window.

✅ First and Last names, Company, and Designation fields. Single-string text fields with length restriction (character limitation) will be validated with the WHILE pattern in hidden mode, and input will be disabled once the limit is exceeded. According to the product manager and boarding team insights, long text in such inputs is rare.

✅ Email field. We add an exceptional case for email validation to warn the user whether the email is confirmed. This will be treated as SPECIAL validation, and it won’t overlap with error messages if the user decides to change it.

✅ Description field. Characters counter will be displayed when needed for massive text area fields.

✅ Password fields. It’s safest to check in real-time (the WHILE pattern) and provide instant and relevant feedback to prevent user errors by guiding her/him through the input checklist requirements.

✅ User rank and Date range fields. We will disable input behind the scenes using the WHILE pattern in a hidden mode for min/max value validation. For instance, in the date range picker, we will prevent the user from selecting an end date earlier than the start date and reset the input if manually entered incorrectly.

Part 5: Results and documented strategy

It’s time to summarize everything and create explicit rules and guidelines for in-product error validation strategies. By following these guidelines, we aim to establish a consistent and user-friendly approach to error validation across all areas of our product.

Our documentation of the validation patterns and error messaging guidelines will be an essential resource for our design, development, and product teams, helping to ensure that all new features and updates follow the established standards.

Part 1: Documented Validation patterns

Here are the overall view and explanations of validation patterns we’ll be implementing in the product:

As you may notice, I’ve added two options for the WHILE pattern:

• Option A: Visible. For example, this option is suitable for password validation, where it is crucial to provide instant feedback.
• Option B: Hidden. This option is suitable for text fields where error messages should not be displayed. Instead, we will disable the input behind the scenes to prevent errors. An example of this is text fields with character limitations.

Part 2: Documented validation kinds and error message templates

In order to fully document our validation approach, we will compile a detailed list of all validation types and their associated patterns, alongside a standardized error message template for consistent messaging.

We may also incorporate visual aids, such as snapshots or examples, to provide additional clarity.

This document will serve as the authoritative source for others and set the pattern for future steps. When all the rules and examples are consolidated in one place, it becomes effortless to maintain a consistent UX copy for error messages.

Otherwise, if no such document exists, we may end up with a plethora of messages for required field validation, such as “This field is required”, “This field cannot be empty”, “This field is empty, please fill it”, and so on.

Part 3: Documented UI specs

Don’t forget about the user interface! Make sure to provide detailed specifications for all design system components. This will guarantee that your team can consistently implement the correct visual and interactive elements throughout the product.

Part 4: Documented in page data validation template

Last but not least, let’s explore an example of how to use the framework in practice. When it comes to building a precise layout, such as a User Configuration Form, you can analyze all attributes and convert them into the following format:

This document is essential as it will comprehensively list all the fields and their respective validation requirements, including the exact wording for error messages.

Trust me, this will be highly beneficial for everyone involved in the product development process. It will provide a clear and concise framework for utilizing the validation patterns and provide consistent implementation across the board. Additionally, it will significantly assist QA in reviewing the page by referencing this description document.

Now you are ready to go and share it with the team!

Summary: What’s left to consider

• It’s normal for some decisions to be debatable.
• This guide should give you an idea of the approach you can test in your product. Remember that the validation strategy may differ depending on the product type, intended audience, deadlines, budget, and overall product strategy.
• Submit button placement: configuration forms in SaaS products can be lengthy and complex, with “Save” and “Cancel” buttons sometimes placed at the very top or bottom. This can force users to scroll to reach the Submit button, causing unnecessary stress. To alleviate this issue, assume designing a fixed, scroll-independent bar with action buttons at the bottom that’s always available in the user’s view.
• It deserves a separate article if your configuration forms involve complex nested navigation. When it comes to cross-tab validation, it can get tricky. Be mindful of how the system should react if the user navigates between tabs and encounters errors.

Thank You for reading!

If you found this article helpful and informative, please 👏 so others can also discover it.