SPlash: CUSTOM ERRORS
This project is from my time as the designer on the forms team at Splash. Every event our customers host requires guests to sign up via a form. Every form is customizable; both visually and in terms of the information a host can collect.
As our client base grew, we had brands that needed to use very specific language on their form. The only part of the form that wasn’t editable was our default error messages. As requests for this rose, we made the decision to create an interface that allowed a user to customize error messages as part of their form setup.
Demo of the custom error message feature live!
Team: Michael Siegel (Product Owner), Blás Castellano (Senior Engineer), Iván Rodriguez (Engineer), Zlatian Iliev (Engineer), Guillermo De La Puente (Scrum Master), Izzy Bulling (Product Design).
01. TALKS WITH CUSTOMER SUCCESS
Our ever-accommodating CS team had been using a workaround long before we decided to productize custom error messages. For each client, they would insert custom javascript, manually entering new copy for every message.
While this method was costly in time, it did provide us with information that became crucial later. CS had insight into the messages that were most commonly requested for edits, which helped us narrow down the amount of customizable errors from 38 to 13.
Why not allow users to customize every error we have?
Some of our errors are very specific – we don’t want to give a host full reign over them, lest they remove crucial information for a guest trying to RSVP. Instead of having a host translate them manually for an international event, we want to do this translation automatically in the future based on event language.
02. DESIGN SPRINT
Adding an interface for customizing errors within the existing form builder was a tricky problem. Do users want to edit their errors while they’re creating questions, or is this a final step after the form is completely set up? Who would be responsible for this task?
Before working on any visual solutions, my PM, our dev team, and I got together in a room and focused on the problem we defined, condensed into a user story.
“As a host, I want to modify error messages on my form, so I may use my own brand voice or language.”
Whiteboarding/Brainstorming with the Development Team
Within our design sprint, we also determined our ideal holistic forms user flow, and how custom errors could fit into this (highlighted in blue). Click for PDF.
03. UI EXPLORATION
Initially, we decided to explore three different options for where this feature could live:
In its own section/tab of our forms content management sidebar
As a node within the “Questions” tab of the sidebar
Within a modal dedicated to this feature
Option 1
Option 2
04. UI ITERATIONS
After critique from the design team and technical discussions with the development team, we decided to move forward with the third option – creating a modal that contained every editable error message, keeping them all in one place. This was based on a multiple factors:
We started with 13 editable error messages, with the possibility of adding more. The amount of text involved was too high for a smooth experience within the sidebar.
“Errors” or “Messages” are not on the same hierarchy level as form questions or form styling – therefore, it didn’t make sense for them to share tab navigation.
Using a modal follow a pattern we already had within the form builder. New questions are selected within a modal, and custom logic is edited within a modal.
Idea for a modal that included a “revert to default” option for each message
Ideas for an “add” icon to navigate to this feature
05. USER TESTING
Once we had an initial design for the modal, we wanted to check for understanding. The main things we wanted to test our users for were:
Are they able to find this feature within the form builder?
Is it clear what will happen when they edit the text in these inputs?
Do they know how to get back to the default message, if they wish?
We created a simple Invision prototype and corresponding scenario to go through with our test subjects.
Excerpts from the post user testing presentation to stakeholders
We measured success both qualitatively and quantitatively. For quantitative data, we used a simple equation of % of success = S(P*.5)/T where S = success, P = partial, and T = total. Each step in the scenario is given a value of S, P or F (failure) based on user performance. Any task with less than a 75% success rate is flagged for improvement.
The answers to our original questions were as follows:
Are they able to find this feature within the form builder? NOT EASILY
Is it clear what will happen when they edit the text in these inputs? MOSTLY
Do they know how to get back to the default message, if they wish? YES
06. POST-TESTING IMPROVEMENTS
Based on the following feedback, we made a few changes to the design before beginning development.
Turned the existing “Add Question” CTA into a multi-action dropdown, instead of having users navigate to this feature via an icon. The icon was unclear, and stood out too much. Keeping it within the multi-action button made it discoverable.
Added a line of explainer text beneath the modal header, to clarify the purpose and result of this feature.
Removed the revert/undo function, as this was a high technical lift without a lot of UX impact. It was just as easy for users to delete their text in the input, and they understood that if they did that, the default message would return.
In the next iteration, we’d like to make the placeholder text (which is the default error message) live text, so a user may make a small change to the message without having to retype the default.