Errors are something I personally hate encountering when using any product. It will terminate my user journey, if I can’t resolve an error within 30 secs, I’ll grow frustrated.
This is particularly true for B2B enterprise products, where users are often professionals with tasks critical to their business needs. Effective error handling becomes crucial as it helps users continue their work without unnecessary delays.
The AI startup I worked at implemented a new Error Handling feature. Our product is made for process engineers to monitor operational data for industrial manufacturers. Collaborating with four engineers and an instructional designer, I immersed myself in a sea of errors while designing this new feature.
Why did I write this article?
While researching the Error Handling feature, I noticed that most articles focus on designing error messages or preventing errors altogether. I learnt a lot from the articles but had a hard time to decide where to start.
To address this gap, I will explore how to organize a variety of errors, acknowledging that they are bound to happen. This article focuses on the practical aspects of dealing with errors, steering away from the usual discussions about error message design or complete error prevention or explore different design principles.
I hope this article provides insight into how my team tackled these challenges.
So.. How did we start?
Research First
To begin, I conducted research on how other companies and products handle errors. This involved two main research parts:
- Exploring Public Design Systems:
Examining existing design systems offered valuable insights. This approach had two key benefits:
- Understanding the users’ mental model for errors.
- Saving our research time by leveraging the groundwork they’ve already done.
2.Analyzing Everyday Product Usage:
I observed how products we use daily handle errors, documenting the process through screenshots or screen recordings when necessary. While intentionally encountering errors can be challenging, capturing them during regular usage provides a more authentic representation.
Just added this line — Medium allowed me to ‘publish’ an article that failed to save. As a result, the article I had spent 4 hours working on disappeared. The draft file, named as ‘3 hours ago,’ actually shows the article I put together a month ago. What you are reading now is reconstructed from my memory. This can serve as an example of poor user experience that we’ve encountered. Quick quiz: What do you think the solution can be?
After researching, I made a document to record key takeaways from researching and UX guidelines for later design.
Document errors
Of course as a product designer, I’ve designed some error states. However, there’s a limitation for us since I could only imagine some parts of system errors and user errors. Especially for enterprise software, the real world scenarios are far more complicated than our designs.
Even though the product team has documented some errors, it’s not sufficient. Due to technical constraints, there are back-end errors that designers won’t notice. Consequently, the back-end engineering team has invested a significant amount of time in documenting all possible errors.
To organize these errors, we decided to categorize them into three parts based on the our product’s workflow. This approach not only helps break down such a significant feature but also aids engineers later when designing error codes.
We categorized the errors based on where in the workflow they occur. Like I mentioned before, the platform required process engineers to monitor datas. The main workflow can be summarized as upload data and train data. So we categorized the errors into three phases: upload, curation, and training. Later we designed the error codes based on it. e.g. The uploaded file has an empty header: UP-EV-01
Notably, at the beginning, we didn’t organize it this way, making it a bit challenging for us to review and lacking a clear mental model. (We tried to follow the architecture and use primary pages as the category.)
Design a message
Here comes one of the key takeaways from research: Adobe suggests to design the message before delving into UX and UI design.
Therefore, the initial step in crafting the message involves identifying the actions users can take to resolve each error. The message significantly influences the next steps for users, offering a valuable opportunity to comprehend the reasons behind the error, particularly when it originates from both back-end and front-end issues. Determining which solutions users are allowed to take, especially for software error design, can be challenging, often involving complex actions that may be difficult to explain. This step necessitates close collaboration with the engineering team to make informed decisions.
Throughout this phase, we revisited the Error Documentation, enhancing its details. Our instructional designer played a crucial role in ensuring a seamless connection between the error message and the corresponding help page. It’s worth noting that we added the messages to the Error Documentation, allowing us to easily review any details if needed in the future.
Error Types
Various types of errors, such as inline text errors and global errors after completing all fields, need consideration. Prior to creating mock-ups, I organized the anticipated error types in the system using a mind map. This approach made it easier to decide and catalog the interactions and making interactions consistency.
Creating mock-ups
Finally! We can start to design interfaces and components.
Well, as a company who owns existing library, it probably be hard to make change to existing components. Generally, I don’t recommend frequent alterations to components. However, given the goal of enhancing error handling, I made some adjustments to the Error Toast components. we aimed to minimize changes to reduce both engineering efforts and potential user discomfort.
For this feature, I met with the engineering team daily to gather feedback and made numerous iterations, considering technical and time constraints.
Insights
- Scoping the feature down would help team members to maintain passion.
- Documentation plays a crucial role in managing the significant changes.
- Gathering feedback early in the process is imperative.
- Creating a mind map for all errors not only aids in design but also serves as a valuable resource for QA testing.
Thanks for reading!
This is my first time writing a Medium article. Typically, for case studies, I follow the structure — problem, solution, research, iterations. However, this time, I would like to try writing it in chronological order, following a timeline
Feel free to leave your comments or connect with me if you have any questions.
