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.

Partway through my internship at GuideOne Insurance, the department director called me in to work on a technology project. He told me, “We want to implement a live chat service with our new web portal, GO BOP. You’re in charge – figure out what we need.”

In two weeks, I came back with a plan for integrating the chat with our site and setting up an internal support team. Senior leadership approved the project, and I worked with information architects and developers to set up the backend and test the service. I collaborated with the business team to organize a support team and designed the chat interface to match company branding.

Partway through the project, we discovered that our chosen service didn’t work with Internet Explorer. My team and I moved quickly to pivot to another service and even found a lower price, saving money for the company.

The project stayed on-schedule, and I presented it to the CIO a few weeks later for approval. I also trained the internal support team on the interface, and the chat service went live on the website soon after.

…In further pursuit of ease-of-doing-business, GuideOne has implemented and is currently piloting live chat, Beving relates. “This allows our agents to receive live assistance for their questions about the product, underwriting, and the GO BOP portal navigation,” he explains. “Once the pilot concludes, we plan to release this functionality to all portal users. In addition, we are actively reviewing all questions and answers so that we can build chat bot functionality to answer commonly asked questions instantaneously.”

– Insurance Innovation Reporter

The best part of this project was creating a great user experience! The chat app launched with a redesigned agent portal, and the support team received over 100 messages from users on the first day alone. It allowed users to directly reach out with subject-matter questions, website support issues, and feedback on the new portal. This feedback channel was valuable both for external and internal users, and good UX helped everyone transition easily to the new portal.

First, I evaluated qualitative research data for themes. One major problem with the existing interface was that the UI for both modes looked almost identical. Data showed that users were effectively blind to the feature intended to distinguish the two. Also, the single entry point for the metadata mode was hidden on a little-used tab. I used these themes to guide my concept explorations.

A competitive review of mode awareness in Google Suite, Adobe XD, and other apps provided patterns to explore. I sketched 15-20 ideas for differentiating modes and another 10 for entry point discoverability, then narrowed them down based on technical constraints and collaborative feedback. To share out the project with my development team, I created a mid-fi click-through prototype in Balsamiq and presented research data to support my design choices.

One option for entry point discoverability involved changes to ecosystem patterns, the application’s building blocks of code and UI. I worked with the UI team and developers to estimate feasibility for this change, and determined that it was out of scope. Instead, I altered the design to produce a Minimum Valuable Product with less development effort that still met user needs. Further refinements are slated for second-pass development.

Both the discoverability and mode differentiation designs were approved, and are currently in development. Once the project is live, I’ll collect and analyze additional data via analytics and user testing to further validate my assumptions.

This was a personal project with limited scope, so I created three personas to define my audience and their needs.

Gabby, age 10

Gabby is a budding engineer and loves making paper airplanes. She wants to be just like her older brother, Sam! Gabby gets distracted easily, but she can spend hours with digital devices, especially her tablet. She wants to experiment with building new plane designs – all by herself. She also wants to build her favorite designs over and over and show them to her friends.

Sam, age 20

Sam is Gabby’s older brother. He’s in college, studying to be an engineer, and he misses his sister. Sam is a creative guy and likes to build and invent. Before he went to college, he spent a lot of time building things with Gabby. He’d like to see what she’s working on and send her blueprints for new airplanes he creates.

Danielle, age 42

Danielle is Sam and Gabby’s mother. She’s a tutor and works from home most of the time. When Gabby’s not at school, Danielle is constantly looking for things to keep her busy. She doesn’t mind Gabby playing with her tablet as long as she’s actively engaging with her environment too. Paper airplanes are a great way to keep Gabby busy! But Danielle does worry about privacy and keeping Gabby safe on the internet.

• The app is usable and attractive for both children and adults.
• The app can share designs between users, but there is no chat feature.
• The app saves the user’s favorite designs to build again.
• The app allows users to upload their own designs.

I kept the app design simple so children and adults could use it. Instead of in-app sharing, it integrates with existing social media like Facebook so users can safely share content. Each plane design has a difficulty level and flight characteristics, so users can discover new types of plane. In the instruction screens, the paper is shown before and after folding.

The app includes a library that saves designs and shows users their stats. It also gives instructions for users to photograph and upload designs.