With a go-live, we all know that things can get a little hectic. User complaints streaming in, 2 AM debug sessions, regular hotfix deploys, and stakeholders spamming developers.
Before a go-live (and during) it is important to categorize user issues into critical and non-critical bugs. When a user starts complaining about a disabled button and the wrong colour on a grid, it can become overwhelming to differentiate between critical and non-critical bugs. Developers normally just start with the first bug and work their way through — or sometimes the easiest.
It is important to set a proper understanding of critical and non-critical bugs with stakeholders, users, and developers. Sometimes by the urgency of emails, tickets, or phone calls, a developer might feel obliged to work through the night to fix the issue- only to find that the user did not even need that function the following day. This can be very upsetting and demotivating. A stakeholder could also submit a list of bugs and expect the most urgent ones to be fixed as soon as possible. When an update arrives, the stakeholder might be upset that all bugs except the important ones were fixed. This is also very frustrating for both parties.
First, let us define what a critical bug is and is not :
- A bug is not critical just because the user says so. It may be “important”, “frustrating”, “take longer time”, “priority”, etc., but not just critical.
- A bug classified as critical means that users can under no circumstances continue with important and commonly used functionality. For example, the save button on a screen throws an unexpected error and does not save at all. Should it just show an error but the data is saved, then it is not critical — just an unpleasant experience.
- As seen above, an issue relating to an unpleasant UX experience (provided that the functionality still works), is not considered critical.
Although sending this blog post to every user would feel great — in practice, a bug may feel critical to a user even when it is not. The best way to get this information from a user logging the ticket, is to not ask them “Is this a critical bug?”. Of course, they will mark every issue as critical. A much better approach is to make a process where they can log bugs — this could be a custom site, in the application itself, or even just google forms. Asking the user to describe the issue and answer the above questions with Yes/No, will inform the support clerk and developer how critical this really is.
Check these top-rated sites for support desk sites: https://www.zendesk.com/help-desk-software/ticketing-system/
