Remember error handling as part of a user journey

Posted by on 2.21.22 in Uncategorized

It’s surprising how many times I still forget to ask about error states when discussing a new user journey. It often seems to feel like a bit of an after thought, but it shouldn’t be. I think that the misconception is that it is an easy thing to add at the end, but depending on the application you are working on, there could be many nuances to consider.

I tend to work on Single Page Applications (SPAs) built using Vue.js and a Node.js backend. Typically when a view loads an API call is made to fetch some data and at that point we already have an opportunity to consider what to do if that request fails. Do we keep showing an indication that the view is loading and try again (how many times before we give up?) or do we present an error to the user and an option to try again?

Then there is third party code such as analytics monitoring or perhaps you have a chat widget for customers to interact with. What happens if one of those things goes wrong? Are they critical to the journey? I don’t suppose we would want a user not to be able to use the application simply because our analytics code misbehaved, but then how do we track this so that our numbers aren’t skewed when stakeholders scrutinize them.

As you can see, our application has barely done anything and already so many questions. Quite a common journey would be for a user to input some data and another request would be made to a service to process it. What if that goes wrong? Do we let them retry? Do we retry for them in the background? How many times before we give up? How can we track these errors so they can be investigated? So many questions.

Maybe that’s the point. There are too many questions to ask before we get started, but we do need to find a balance between getting started and having enough information so that some of these issues don’t slip through the net. In my experience of working in Agile Scrum teams, stories are often discussed for the first time during a refinement session. The meetings tend to be relatively short and we have a lot to discuss. The stories we talk about are also varied, they might touch one platform or all platforms and if we go into this amount of detail then we aren’t going to have enough time. I don’t want to hold everyone up, but at the same time I don’t want to start on something until the requirements are clear or at least we have a plan to define them more clearly.

One thing I rarely do is review the backlog before attending one of the refinement sessions. I’m going to try and be more pro-active about reviewing upcoming stories and asking for clarification earlier so that during the refinement some of the detail has been added to the story. It’s challenging to push back, particularly when you are eager to get going on something, however, I’m sure the rest of the team would be grateful if we manage to catch something earlier on in the process rather than it catching us out unexpectedly during the sprint. It could be that a missing bit of information would influence the complexity of the task or whether or not we take it into the next sprint at all.