When working with designers the output is usually a Figma showing the happy path of a user flow in the system. It is good to have this but great systems aren’t just defined by what they do right, but also by how they work when something goes wrong.

Whatever framework or library your codebase uses for the UI on the web it loads the initial page then makes further requests in the background to perform tasks for the user. Often the Figma design assumes that these requests will always work and there will never be a network error or a response that says the server couldn’t process the request.

The frontend code can also make this assumption, leaving the application in an unusable state if the backend doesn’t respond as expected. We’ve all experienced a web app hanging and seemingly doing nothing until you refresh the page.

It is worth thinking about what the most likely failure modes might be up front. Once you have a list you can ask the designer to include designs that show what happens and what the user should see when these occur.

Doing this up front means it can thought through as part of the overall UI design. Your users can have a consistent experience and the engineers working on the UI can build it in from the start.

It also makes your engineers figure out how they will keep the UI in a usable state if there is an error talking to the backend. When you don’t do this up front adding it later means pretty useless error messages while you rebuild the UI code to include the error handling.