Recently on my project, I spent some time investigating how our app handles loading and error states. The project is fast-paced, with ambitious goals for feature work in a tight timeline. Initially, we were using mock data to build out our features, and the app looked polished during demos. But, once we started using real data, it became clear that we would need to address some jarring loading transitions and overlooked treatment of errors. Here are some of my takeaways.
When should we address loading and error states?
In a project with limited time and resources, addressing loading and error states might not be top of mind. Deciding on when to handle them depends on the needs of the project. The team doesn’t have to make loading and error states a focus immediately. However, it’s worth having a conversation early on to align expectations and practices in this area.
Scaffolding is better than nothing.
Another takeaway from my investigation is the importance of scaffolding. Even a basic framework can provide invaluable feedback and pave the way for future refinements.
For instance, early on in our codebase, we implemented a feature that kept track of the dataState. In this area, we added a small loading spinner and a default blank page with a placeholder error message. While not a comprehensive solution, it served as a starting point for methodically addressing loading and error states. As we continued to build out more features, we kept the pattern of setting the dataState, but we didn’t use that information to change the screen in any way. Though keeping track of this state didn’t improve user experience on its own, it made the process of error and loading implementation much faster.
Not all loading/errors are created equal.
Another key insight is the nuanced nature of loading and error scenarios. In our app, the distinction between GET and POST requests emerged as a significant factor. This highlighted the need for tailored treatments based on the context of data retrieval. For example, in some areas, we had added a full-page error screen, and in others, we displayed an empty state with an error toast with a message that something had gone wrong.
We ended up deciding a full-page solution made more sense to display when the error was related to fetching data. However, an error toast made more sense when the user wanted to modify data but that request failed.
What do you do first with limited resources? How much planning is too much planning? Should we tackle error and loading head-on, despite the risk of over-engineering? Or is it wiser to defer these decisions, acknowledging that they will inevitably require attention down the line? These questions underscore the balance between planning and action, a theme we’ll explore further in my next post.