Senior UX Designer & Researcher
(SaaS/B2B and E-Commerce)
3 min read
Alerts & Error Prevention
(Case Study)
"Beth can always be counted on to dig into the
discovery of problems and systems to uncover critical
business requirements or customers needs."
—Josh Smith, Manager
The Problem
A newly acquired app was added to our suite. The goal was to improve the alert system and the UI to ensure accuracy of user's data and to ensure that users would meet federally mandated deadlines. Federal funding was on the line for users. The original assumption was that we would keep the alert system and add inline validations. It quickly became evident that the alert system looked impressive but was actually seriously flawed and could lead users into error.
My Role
I was tasked with understanding the system in order to make recommendations for UI changes and provide assets for developers.
Methodologies
-
Personas
-
User Stories
-
Workflows
-
System audit
-
Interviews
-
Review of best practices for alerts
-
Inspection of UI & UI components
The Process
• User Stories
-
I, as a special education teacher, need to accurately complete forms for my students on time in order to meet federally mandated requirements and deadlines.
-
I, as an administrator, need to monitor and ensure that teachers complete their work accurately and on time in order to stay in compliance with federal requirements and deadlines.
• Alert System Audit
The alert system had dropdown menus with alerts next to student names. This was used to inform teachers about which forms needed attention. First, it was easy to see that this alert system over communicated. All alert types were available on each page of the app in three places. There was little visual higherarchy and alerts from form fields were mixed in with deadline warnings. Also, depending on where a user was in the system, sometimes, different data would show up in the dropdowns. This gave users an inconsistent, confusing experience.
• Interviews
I interviewed a developer to understand what triggered the alerts. It became apparent that on forms any unfinished field would be marked as an "error" and show up as an alert. So, if a user started a form, filled in one field, and went home for the night, all unfinished fields will be marked as "errors" and would appear in the alert system.
In the next interviews, I needed to confirm how users applied this system. “Teachers use it to prioritize their work.” “It shows teachers what they need to do next.” And, "Administrators use the dashboard summary to see which teachers are falling behind in their work." All of this was a giant red flag. This flood of "errors" was screaming for attention while truly urgent deadlines were less visible. For example, if a teacher started a form that was due in two weeks but didn't finish the form right away, many alerts would appear in the alert system. This same teacher could have three forms that were due today, but these forms only had one empty field each. These three urgent forms would not visually stand out because they have fewer "errors." This alert system could actually cause users to prioritize work badly and miss critical deadlines. Deadlines are the highest priority.
Next, I spoke with the developer who had designed this system. Hesitantly, he confirmed that, "yes," the system was flawed.
• Audit of "Alert Types"
The system had 15 alert types. I reorganized them into three categories that would inform where the alerts could live in the system. Most alerts belong at the "inline" level on a form. Removing them from the alert system would declutter the UI and visually prioritize deadlines.
• Error Correction
In the alert system, users could click on a specific student and link through to the page where the errors could be fixed, but these errors were not visibly marked on the forms themselves. It was extremely difficult to find and correct any error. Inline validation—in context guidance—was needed.
• UI Inspection
Radio buttons were used incorrectly as they were not visually near each other. It was difficult to see what the choices were. Additionally, forms did not employ progressive disclosure. ALL options were visible to users. This created vast amounts of clutter on each form. and increased the likelihood of user error and slow input.
Using the right UI Component for the right job would ensure the accuracy of data. There were many text fields that could leverage dropdowns or radio buttons because there were specific answers. This change would improve the accuracy of data and the speed of data entry for users.
Outcomes/Recommendations
• I won a recognition award for finding the serious flaw! ($100 Amazon gift card).
• I presented my findings to product to explain the recommendations that I was making. It was an eye opening experience for everyone. Later, I created assets for developers.
Recommendations included:
-
Sunset the alert system.
-
Leverage new dashboards to guide users in meeting deadlines.
-
Leverage inline validations.
-
Use progressive disclosure by giving users a small choice, and then showing applicable fields. This would clear 80% of the noise on forms, and increase accuracy & speed.
-
Use correct UI component. When input data is predefined use radio buttons or dropdowns, not text fields.
-
Use UI components properly (ie radio buttons).
-
Mark required fields.
-
Accessibility was factored in with the assets to meet WCAG 2.1AA standards. Validation assets included icons and alt-text to avoid using color alone to convey meaning.
