Re-order incident sidebar items

Release notes

Problem to solve

After releasing the MVC for incidents, we've added additional items to the incident sidebar, including status, escalation policy, milestone, time tracking. Because these items were added piecemeal, over the course of time, the current order of the sidebar items doesn't feel like it accurately matches their usefulness during an incident. Severity, for example, is buried near the bottom of the list. Is this the right placement?

Proposal

In user feedback sessions, people reported that the most important widgets on incidents are assignee, severity and status. As a small iteration here, let's move the severity widget from its current position near the bottom of the widgets, to near the top, just under assignee.

Here's how that looks:

Figma file

Intended users

• Sidney (Systems Administrator)
• Ingrid (Infrastructure Operator)

Feature Usage Metrics

Got some feedback on the sidebar order in latest rounds of user testing. Full details here. Quick summary:

Assignee, status and severity. Order looks right to me.

Milestone and time tracking are completely irrelevant, as is due date. I would get rid of all three of those. Assignee, severity are important. If you're showing status here, you may not need it in the highlight. Escalation policy is interesting. Are we looking at the policy at the start, currently, or at the end of the incident? It could start at EMEA and hand off to the Americas. It's not clear from this UI what it's actually referring to. So that one's of questionable usefulness. Labels and confidentiality are important, too. Maybe one day we can have configuration and people can choose which sidebar items are most important to them?

added Category:Incident Management UX featureenhancement grouprespond labels

added typefeature label

@kbychu, the work in this issue, for re-ordering the widgets in the incident sidebar, was originally included as part of #360009 (closed). I split it into a separate issue as they are really two separate efforts: they would be implemented separately, and would probably need to be validated separately, as well. Just letting you know about this change!

changed the description

Setting label(s) devopsmonitor sectionops based on grouprespond.

added devopsmonitor sectionops labels

@kbychu - have added a proposal to this issue based on what we heard in our most recent batch of user feedback sessions. Any concerns with what's been proposed?

Looks like a good iteration @ameliabauerly

What about having labels above escalation policy?

I was thinking about that, @kbychu! The reason I didn't recommend it at this point is because the escalation policy and status dropdowns interact with each other. The status dropdown is tied to the escalation policy dropdown such that, changing the status from triggered to acknowledged will stop the paging. Here's what it says within the status dropdown:

For this reason, it felt like it made sense to co-locate them together, so people can quickly refer to the escalation policy dropdown if/as needed as they are changing the status, even if the escalation policy dropdown is less used overall than the labels dropdown. Thoughts on this?

Thanks for the explanation @ameliabauerly. Makes perfect sense.

added workflowready for development label

changed milestone to %15.3

@ameliabauerly Assigning this one to 15.3

Cool, sounds good!

added [deprecated] Accepting merge requests label

mentioned in issue gitlab-org/monitor/respond#128 (closed)

assigned to @rkadam3

mentioned in merge request !94183 (merged)

Was a low-hanging fruit.

Fixed in - !94183 (merged)

Thanks for doing this, @rkadam3!

added workflowin dev label and removed workflowready for development label

removed [deprecated] Accepting merge requests label

Closing this as done. MR is in workflowproduction

closed

added workflowproduction label and removed workflowin dev label