Severity Based Permissions

Rootly is an incident management and on-call tool with the main goal of making sure that when a service goes down we both alert engineers and help facilitate the incident.

Severity Based Permissions

Rootly is an incident management and on-call tool with the main goal of making sure that when a service goes down we both alert engineers and help facilitate the incident.

Problem

Incidents of higher severities were sensitive to information change. A high severity incident like a SEV0 may be editable my a senior engineer, while a junior engineer should only be able to view it. (Above is a crude screenshot of what we already had).

Problem

Incidents of higher severities were sensitive to information change. A high severity incident like a SEV0 may be editable my a senior engineer, while a junior engineer should only be able to view it. (Above is a crude screenshot of what we already had).

Granular permissions

Severity based permissions are deeply layered in comparison to a typical permissions set.

  1. Is it a Private or Public incident?

  2. Is it a new incident? Sev 0? Sev 3?

  3. Can this user create, read, update or delete an incident?

  4. Can this user set Sev 0 incident to "Resolved"?

This granularity was required when considering teams of more complex compositions, with different levels of engineers, communications, CSuite involvement.

After interviewing users, we came away with specific requirements of which permissions needed that granularity for our first release.

Iterations

With a short timeline I iterated with feedback from our sales and CS team, with some feedback from the product team as well.

Iterations

With a short timeline I iterated with feedback from our sales and CS team, with some feedback from the product team as well.

First design I settled on

After processing the feedback, I came back to the team with a design that focused on minimizing what appeared on screen - allowing the user to more easily digest information.

First design I settled on

After processing the feedback, I came back to the team with a design that focused on minimizing what appeared on screen - allowing the user to more easily digest information.

Feedback with Product and Design

The main piece of feedback was difficulty in reading what was happening.

"Permission to set status to…" was in the header, while each status that would finish that sentence like "In- Triage" "Active" were below.

It didn't flow as easily as we would have liked.

Final design

We landed on an accordion style nest for related permissions, favouring a form where checkboxes could wrap below for users that had many severities/sevrities with longer names.

Final design

We landed on an accordion style nest for related permissions, favouring a form where checkboxes could wrap below for users that had many severities/sevrities with longer names.

Retrospective

We landed the deal! Users found it incredibly easy to understand in our beta feedback calls.

However, if I were to repeat this work I'd go with a table view.

Users can create many severities with different length names, which is why we went more towards a design that favoured variable text size.

Compared to where we landed, tables provide a much cleaner overview to review the decisions you make or come in and make changes - with a bit more friction on learning or possible horizontal scrolls for users with many severities.

Prototype

Made with Figma Make

< Back home