You don't want to have to acknowledge that the printer is out of paper when you're trying to shut down the nuclear reactor. (Russ Benel)

Ah, yes, prioritization …

As a usability engineer, I typically see prioritization as a matter of ranking the severity of issues that I uncover in tests. I think most of us in the field recognize the need for this, though I am always surprised at those usability engineers who see it as somewhat optional.

From my standpoint, I just assume that the audience for my reports would very much like to know my opinion on which issues were particularly thorny for my users. We could set priorities as a group, but I figure they will come up with their own estimation of impact (if they’re the business) or technical feasibility (if they’re IT) on their own. What we need to do, as a team, is to identify all the variables that are in play. And for that, the team’s going to need your honest opinion – as the expert – for the usability side of things. 

Is this less important in these days of sticky-note reports, continuous collaboration, and 2-week sprints? Possibly. I don’t think Agile and Lean methodologies obviate the need for severity ratings altogether though. I mean, they might be more informal, or developed more as a group effort, but there’s absolutely no reason for them to simply disappear.

Are severity ratings subjective? Well, yes, they could be. There are, however, some fairly agreed-upon standards. The best ones are typically simple (i.e., high, medium, and low) and fairly operational (usually centering around whether the user can complete their task and how many users have that same problem). Whichever you use, though, you do need to be consistent – over time and for all your reports and report authors.

Another objective I’ve heard is that severity/prioritization can be very evaluative. In other words, I know I’ve had some reports where the executive summary had a ton of red on it. I think the objection here was that this will make an audience defensive and possibly even shut down right off the bat.

At the same time, though, a report with an executive summary like that is pretty rare. And when they do come up, I think it’s essential to get my audience’s attention and communicate that, yes, there is a very real problem here.

In particular, I want them to know – very clearly – that one issue (a major mismatch in mental models, say) really is the equivalent of a core meltdown, while another (faulty punctuation in an error message) is not exactly the end of civilization as we know it (and probably more like that dopey printer confirmation modal).