Your incident declaration form is (probably) too long: The power of concise reporting
It’s 10am, your coffee is ready and piping hot, and you have just been paged.
Looks like [insert relevant feature of your own choosing here] is down, and customers are starting to notice. With no time to lose, you open up your organization’s incident declaration form and you spend the next thirty minutes filling out the fifteen required fields, while the incident grows bigger and more complex, messages are rolling in, and your coffee grows cold.
More fields, more problems
When it comes to incident reporting, many organizations tend to err on the side of asking for too much information up front.
The intent behind this is understandable—we want responders who join the incident to have as much information as possible, so that they can hit the ground running. We want to know who has been impacted and which services are affected, so that the incident can be prioritized. We may also want data for analysis and future prevention.
Unfortunately, the result often ends up being counterproductive.
Lengthy and complex incident report forms can be daunting for responders, leading to delays in reporting, incomplete and inaccurate forms, and even underreporting of incidents.
When analyzing the average time it takes to declare an incident, the results are clear: organizations with forms having three to six fields can declare incidents under a minute.
However, when the form has over ten fields, the incident declaration time nearly doubles.
These declare times seem to be primarily driven by users inputting a summary of the incident so far; users may be searching for the right words to describe the state of affairs.
If we remove any incident declarations that provided a summary, we should be left with the time taken to declare incidents where the declaration process was solely filling out the forms.
As expected, we see a clear linear increase in declaration time as the field count increases.
How can I improve my declare form?
Luckily, incident.io makes it very easy to streamline your declare form, by allowing users to completely customize the form structure, as well as each field within. Consider the following options when considering cutting back your overgrown forms:
Hide fields when they are not needed
Not all fields will be relevant to every incident. Perhaps you only care about which services have been impacted when the severity is Major or above.
Lengthy and complex incident report forms can be daunting for responders, leading to delays in reporting, incomplete and inaccurate forms, and even underreporting of incidents.
By conditionally hiding your Impacted Services field when it is not needed, you can minimize the visual clutter that can overwhelm the incident responder.
Make fields optional
Sometimes a field is not relevant to the incident at hand, but responders are required to input something, anything in order to get the incident declared. By making some fields optional, users have the flexibility to add info only where necessary. This also has the added benefit of making your data cleaner, as incident responders will not need to add “n/a”, “not applicable” or the classic “asdfhalksdfh” into the field in order to proceed.
Consider eliminating the field altogether
If a field is not crucial to the investigation or fixing stage of an incident, it might be worth eliminating it from the declare form. While important data to collect, responders might be more inclined to fill out these fields when things are no longer on fire. At this point, you may find it useful to…
Move the field to a different form
Some data you may been keen to save after the incident has been resolved, such as solutions and underlying causes. By moving these fields to a resolve form, you can ensure that all necessary information is captured without overcomplicating the initial incident form.
Concise forms = happy responders
It is easy to overload your forms, but by customizing your form to be more flexible and placing your trust in your responders to provide the information necessary to complete the task, you will likely see speedier incident responses, cleaner data, and faster onboarding of new responders.
We believe that incident management is for everyone, and by making your incident reporting more user-friendly, you give every member of your organization an opportunity to report issues, wherever they may arise.
And if you are still worried about information loss when responding to an incident, we hear incident.io has a new AI summary feature that can help with that…
The Debrief: Incident management for data teams
In this episode, we chat with Jack Colsey about why data teams should be using incident management to respond to pipeline errors.