Errors and incidents for logged-in web channels
Yes, we know that this page looks unfinished. Work is in progress!
Sometimes errors will occur and we need to handle them uniformly, and sometimes escalate them to incidents or close the function with a stop page.
Component meta
Component identifier
- pattern-errors-logged-in
Tags
Design principles
Errors
Error types
We try to differentiate the content of errors that happen inside MFE:s into 2 groups:
- Server/programming-generated
Examples of this can be error-codes like 400-BadRequest or 500-InternalServerError. They are happening because we may be experiencing some kind of server, or implementation, problem. - Interaction-generated
Examples of this can be 404-NotFound or 403-Forbidden. They may be because of the user interaction, or the setup for this particular user
Practically for development it's the same types of problems, but we may be more helpful to telling users what to do to solve their own problems when the error is interaction generated.
General usability of error messages
All error texts should follow the following guides:
- Written in plain language rather than technical terms.
- Precise by explaining exactly what went wrong.
- Constructive so users know what needs to be done to fix the problem.
Design of error messages in Nexus for MFE:s
Channel governance
Errors should always be monitored so that we as a bank knows that things are broken. If we start learning more about a certain problem we may change the text of the error to be specific of the situation that is happening right now or if there is an alternate way to handle the users task right now. i.e. “We are experiencing problems with the system X. Technicians are solving the issue and it should be up and running within a few hours. In the meantime you may use the mobile app to perform your task”.
If a problem is causing large issues a decision may be made to close the feature temporary. The page is then replaced with a stop page or incident.
Stop pages
When a part of the site is temporary closed due to maintenance or an ongoing error SEB may choose to close the page or a part of a site.
Stop pages should include information about why the page is closed and information about when it’s planned to open again (if possible). Also include option for the user to continue using other features or if it’s possible to perform the task through another channel.
At a further point we wish to add the possibility for the user to be contacted when the problem is fixed.
Design of stop pages
Incidents
Error types
We try to differentiate the content of errors that happen inside MFE:s into 2 groups:
- Server/programming-generated
Examples of this can be error-codes like 400-BadRequest or 500-InternalServerError. They are happening because we may be experiencing some kind of server, or implementation, problem. - Interaction-generated
Examples of this can be 404-NotFound or 403-Forbidden. They may be because of the user interaction, or the setup for this particular user
Practically for development it's the same types of problems, but we may be more helpful to telling users what to do to solve their own problems when the error is interaction generated.
General usability of error messages
All error texts should follow the following guides:
- Written in plain language rather than technical terms.
- Precise by explaining exactly what went wrong.
- Constructive so users know what needs to be done to fix the problem.
Design of error messages in Nexus for MFE:s
Channel governance
Errors should always be monitored so that we as a bank knows that things are broken. If we start learning more about a certain problem we may change the text of the error to be specific of the situation that is happening right now or if there is an alternate way to handle the users task right now. i.e. “We are experiencing problems with the system X. Technicians are solving the issue and it should be up and running within a few hours. In the meantime you may use the mobile app to perform your task”.
If a problem is causing large issues a decision may be made to close the feature temporary. The page is then replaced with a stop page or incident.
Stop pages
When a part of the site is temporary closed due to maintenance or an ongoing error SEB may choose to close the page or a part of a site.
Stop pages should include information about why the page is closed and information about when it’s planned to open again (if possible). Also include option for the user to continue using other features or if it’s possible to perform the task through another channel.
At a further point we wish to add the possibility for the user to be contacted when the problem is fixed.
Design of stop pages