Improved error handling

Long form design considerations to ensure smooth customer journeys

---

Background

During my time working within the financial retail space, I have gained extensive experience in long form design. Digitising paper forms comes with its own set of challenges and ensuring a user has the means to get through to submission successfully is vitally important.

At a field level, any number of issues could be experienced, so it’s important to empower users to be able to recover from errors themselves and move forward in a confident manner.

Working as the design & front end lead on a digital forms team, I worked closely with the development, business, QA and publishing teams to ensure we removed as many technical obstacles as possible so a customer can focus on the task at hand: completing their application so that they can get one step closer to their personal goals.

One such issue customers faced related to the final submission, which I describe in this article. To start, I’d like to first give some background about the architecture of the application engine.

Description of the application engine

The applications engine customers interact with is a React front end, submitting to a separate back end, where applications are then routed to appropriate areas within the bank. We opted for a React front end as it allowed us to create a much more user-centric interface, where we could ensure that the applications themselves became a conversation between the bank and consumers. We were able to introduce a range of improvements that directly benefitted users:

• Improve real-time validation so users were given immediate feedback as they answered questions throughout their application
• Develop more user-friendly micro interactions at a field level
• Streamline the management of the company brand to ensure a much higher level of consistency across the applications engine.
• Amend form journey structures, working with areas of the business to split a long application into meaningful, task-based sections, ensuring we grouped questions that naturally should be asked together.
• Incorporate personalisation throughout the journey in order to increase a level of trust between applicants and the bank.

Uncovering behaviours through usage log reviews

Following SDLP best practice, we regularly monitored usage logs to ensure we were aware of any serious issues that users might be experiencing. We discovered multiple logs that showed us that users were hitting critical submission errors related to validation on various fields.

Because all values are validated again at the server level when a user clicks that final submit button, it essentially meant we needed to replicate field validation on the React front end so that any potential validation errors on submission would be caught early and in the context of the field that triggered an error. The front end validation was part of the main development of the application engine, but the logs were showing some serious gaps that directly affected our user base.

The reality for those users was that on submission, instead of being presented with a comforting confirmation screen letting them know their submission was successful and someone would be in touch, they were instead being faced with an error page that they could not recover were.

Because the front end was essentially an SPA (single page application), this meant that if a user clicked the browser back button or refreshed the page, they were brought back to the first page of the application, losing all the data they had dutifully entered.

Analysis

A plan was put in place to ensure customers could recover from submission errors themselves and successfully complete their applications. Taking each focus area uncovered:

1. Real-time field validation oversights
This was the easiest problem to fix. We knew from the logs what fields were throwing validation errors, so it was a matter of creating development stories for our team to investigate and rectify the gaps in the front end validation. Doing this ultimately reduced the chances of users hitting submission errors going forward and increase the robustness of the application. Over time we improved validation and improved the experience for our users.

2. Missing scenario related to form submission error
This required a lot more thought. We knew that even if we fixed field validation gaps as they were identified in the logs, ultimately we could never be sure users weren’t going to face this type of submission error again. With new field development taking place regularly, at any point a validation mismatch could easily be introduced in the future.

The most obvious solution to ensure we didn’t lose application data would have been to develop ‘Save and Continue’ type functionality. However, this was beyond the scope of the operating model of our team. At an organisational level, we simply weren’t in a position to address this just yet. It would have meant evolving our team from being a data collection team to being a team that stored and served back customer data on the UI. A change like that meant a longer journey through risk and compliance and, although it’s ultimately a position that could enable us to serve our user base better, our users needed a faster response from us.

So we concentrated on bridging the gap and developing a meaningful user story that ensured that, rather than throwing an unhelpful error that left a user with no choice, we would give them a path to recovery.

We could see that we had enough information being returned from the back end validation to identify the following:

• The offending field ID
• The error returned for that field

We also knew that, given a field ID, our React application had access to important information, such as:

• The label for that field
• The page the offending field sat on

So we had enough information to allow the user to return and fix the issue.

Feeling we had enough to start visualising an improved flow, I began work on developing an example prototype that illustrated improved error handling.

I began by creating an example flow, consisting of about 4 pages to cover about 10 fields to be filled in.

I knew that the point at which this error was occurring was detrimental to our users. It was happening right at this moment when a user was clicking on the submit button – that final click that signified the end of their application. This was a moment that should have been filled with relief & satisfaction. So it was important that when fixing this, we didn’t lose that feeling and the momentum that came with it for our users.

At this point, I discussed with development what might be possible next. We knew it was possible that an error could occur on any page of the form – for example an error could trigger on, say, page 5 of a 40-page long form. We pondered a few approaches, such as:

• Should we render the fields that caused the error in a block right there on the submission screen?
• Should we use a modal to show the offending fields and allow users to fix them there?
• Should we send them straight back to the page the offending field lived in the journey?

Rendering fields out of context of the pages they appeared on was ultimately seen as risky for the simple reason that any given field on an application could potentially trigger a different journey depending on the answer provided by the user, which would mean extra questions that may need to be answered. Had we rendered the offending fields out of context of the flow they originally appeared, any number of unforeseen issues could happen with the journey logic.

Ultimately we decided the best option available was to:

• Inform the user of the errors that had triggered, displaying them on the final submission screen.
• Give them the means to return to the page that field sat on

I mapped out what I wanted to see if on submit an error was encountered. On the final submission page, I added extra alerts and details of the fields that had thrown the error, along with links back to the page these fields sat on. Once they had correct the error, we wanted to provide them with a means to return to the submission screen so they could move forward with submitting their application as quickly as possible, provided the field they altered did not trigger a new journey. So I incorporated a conditional ‘Back to last page’ button that could be used to fast forward to the final submission page.

The final prototype was agreed and, through close collaboration with the development and QA team, we rolled this improvement out to our production environments. The final prototype can be viewed on sketch.com:

Conclusion

We continue to monitor usage logs and, even though we occasionally see field errors on submission, we also see that the users experiencing this ultimately return to the page in question, fix the problems and successfully submit their application, hopefully with a feeling of satisfaction.

There are always improvements that can be made and to ensure we’re doing the best we can for our customers, the most effective way to enhance the experience for a user base is through iterative development. It is true that some problems are so deep that a large scale overhaul is necessary. But where possible, small incremental improvements are the way to go.