UX Severity Tracking
Our design team faced a problem that's common among UX folks: once you're past the prototyping and iteration phases and production-level testing starts, how do you convince your triage teams that UX bugs need to be treated with the same urgency as performance or functional failures? For years our teams tracked bug severity according to functional criteria (performance metrics, the presence of a workaround, etc). On a large production system with a technically-ambitious agenda and limited resources, this meant that as long as there was a workaround, no matter how painful, UX bugs were relegated to enhancements or low-severity "normals" unless we rustled up a bucket of feature funding specifically to address them, or someone with a lot of clout complained. Just as often, the UX bugs that bubbled their way into production got there through channels that felt kind of random and personal. It wasn't that our development teams didn't want to fix UX issues; the problem was in how we were measuring their severity.
One of the designers on our team, Becky Torbochkin, sat down to devise a system for measuring and tracking UX bugs on a scale of their own. She began by defining the system's "Red Routes" or key user journeys, and then created a simple flow-chart that anyone could use to objectively measure the severity of a UX issue. We presented the Red Routes and bug severity guidelines to our development team, and in no time we had a new field in Bugzilla for tracking UX severity. And people used the hell out of it.
Our deve