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).
Change does not necessarily always equal good. Something new does not always mean innovation.
Consider the poor transfer user. These are simply folks who have gotten used to doing things a certain way. Then along you come with your improvements.
But, are they improvements? Or are they just one more thing in the user’s way that day? Do they actually make the user’s job easier? Or are they just one more thing they have to figure out and deal with? Do they add new functionality? Or have you simply added something that no one will ever use, and made the interface that much more busy in doing so? Is it better than before? In your eyes? In the user’s?
Sometimes change comes for all the wrong reasons. Perhaps the higher ups simply want a new look and feel, a refresh. Or you could simply have been shanghaied into somebody’s pet project. I often accuse my marketing friends of monkey see, monkey do. Perhaps management is simply flailing away. They know they need to be innovative. But how to do that other than issuing the directive to “go innovate!” might be beyond them.
True innovation comes from seeing what users are having issues with. The brainstorming and ideation (I really don’t like that word) can help you come up with a creative solution, but unless you’re trying to solve a real problem, you may simply be creating new problems.
Even if you have a good idea, though, you still need some kind of change management. As a former instructional designer (who mostly worked on new internal systems for banks), I actually spent as much time on rollout as I did on anything else. I’m always amazed at how little that’s thought of, though, in good, old-fashioned B2C. And I don’t mean just training here, but communications and even selling.
Other ideas to support what Jared calls “embraceable change” include tours; demos; coachmarks; complete mock systems; allowing the user to switch between the old and new systems whenever they feel like it; making small, incremental changes over time rather than one big one … There are no shortage of ideas. You do, however, have to come in with a mindset that change is not always welcomed with open arms, and that it is up to you to make sure that the changes that you make really do add value, and that you are presenting them in such a way as to maximize their benefit – and minimize their disruption –
to the user.
Just solve the problem! Honestly, people! What is wrong with you?
So, that’s what I want to say. What I typically say instead involves some lame hedging about standards, KISS, design patterns, never having tested that particular design before ...
Interestingly, this issue does often come up when a team is tasked with fixing something that came up in usability testing. And, in that context, my response is usually to compliment them on their effort but to point out that we won’t have to time to test their complete redesign of the system with just that one user coming in at 4:00 on Friday afternoon.
In other words, what you’ve come up with may solve the problem, but I can’t guarantee it. In fact, I honestly have no clue if it hasn’t introduced new problems. So, instead, I usually just try to get them to solve the problem, or – in Steve Krug’s great advice – to do the least possible to do so. And that is actually something I can feel pretty good about.
Maybe it’s a digital creative thing. I know we are all encouraged to be innovative these days. And simply making an easy fix is probably not going to impress the higher ups or look good in your portfolio or make you feel all warm and tingly inside. If it solves the problem, though, why not just do it? You can then save all the creativity and innovation for something that really needs it.
Interestingly, Don’s quote was actually in the context of his famous doors. “Norman doors” are doors that are so poorly designed that they give you no affordance of whether to push or pull them. They were the example par excellence in his ground-breaking book The Psychology of Everyday Things, and have pretty much come to be the poster child for poor design. (“Norman Doors” would also be a great name for a band, by the way.)
Now, there are plenty of examples of “misplaced creativeness” in industrial design (where I guess doors would fall). Lately, though, I’ve been seeing lots and lots of examples of it in software, websites, and apps. And this is as functional a space as that for doors, and coffee pots, and stoves, and bathroom fixtures … and all the other real-world stuff Don liked to talk about.
So, UX designers: save the creativity for where it’s really needed. And if that means the print shop or potter’s wheel or woodworking shop that you hit only on the weekends, so be it!
And then there’s this
