9

When addressing and triaging usability-related bugs, I frequently find that I must resort to making a show or elaborately and dramatically describing the user's pain around an issue. While I'm sure I'll always have to do some of this, I wish there was a more standardized way of communicating how severe a problem is / feels. I read about people at Mozilla tagging bugs with which heuristics they break, which I think is a great idea, but it doesn't really help with severity. Does anybody have any good ideas or processes out there?

An example might be, one bug can feel to a designer, oh my god we should never release this in this condition, but to a developer who programmed it the behavior may seem obvious so it seems not very severe at all.

Improve this question

5 Answers 5

Reset to default
8

User Focus have a good article on the topic of prioritising usability problems.

I agree with the sentiment of the opening post. If you're working in an engineering environment or with a large complex system, then having a consistent and understandable methodology and reporting process is of vital importance. Part of why it is important is to be taken seriously, and the other part is to practice good communication and to integrate meaningfully with the other teams and processes that you're working with.

To really drive home that something really really really is an issue and is a huge pain for users then supplementing your reporting with video clips of the interaction can do wonders to shift opinions.

Improve this answer
1
  • That is an excellent article! Thank you so much, that was exactly the kind of thing I was looking for!!
    – Becky
    Nov 18, 2010 at 20:22
8

After struggling with this problem for a couple of years, and ending up creating a product with relatively poor usability in it, I've solved this problem a different way.

There are two sources (at least where I work) to the problem: 1) "The Business" will never schedule/prioritise usability issues as a) they'd rather have new functionality/bugfixes and b) they have no real way to conceive of or quantify the cost of poor usability (they're domain experts after all, not software experts).

2) The (traditional) developers will never schedule/prioritise usability issues as they a) often can't see the extent/cost of the problem and b) are often less confident in front-end development and c) their focus is constantly stolen by issues that are more core to a developer's job.

Consequently, usability suffers.

As such, IMO, you essentially need a separate channel of development to address usability. It's much the same as technical debt (which I would also advocate gets 'solved' this way). Create a new channel of dev, whether it's as small as dedicating a couple of agile points per iteration (or a couple of days per two week release, whatever) to, in an ideal world, hiring a front-end engineer with his own priority-list. This new channel of dev constantly and consistently churns through usability issues, and usability issues are no longer prioritized against non-usability issues but rather against each other.

Now, for both of the audiences in my first paragraph, if you go off and spend a couple of days collecting some research summaries, case study outcomes, quotes from the recognized gurus etc, you should be able to build an argument that will convince people. But who has the time to put in 4 hours of research and argument-building to sufficiently prioritize a 1 hour job? But if you get an argument together (citing a few examples of poor usability in your app) not in support of justifying the prioritization of a single issue but rather justifying a separate channel of development, the payoff is suddenly much more worth the effort.

I am an ordinary C#.Net developer, with an increasing interest in usability. What I did is formulate an argument for the importance of looking at usability issues, went to my CTO with a proposal, and now I'm dedicating a percentage of my time for usability issues. My team has lost some core development resources (we're were hiring so it was an easier argument to make anyway) but now some usability will finally get looked at.

Long-term I am thinking part of my new job is to educate the other developers in such a way as to not release features that exhibit poor usability. Amplify the effects, as it were.

Good luck!

Improve this answer
2
  • thanks mark! nice approach, i'm happy for you! we don't have an agile process; we have an unusual development situation. We've been pushing for more funding for usability but it's true, people often want more stuff rather than better. Also some teams given some free reign to make usability improvements have done a poor job of utilizing their budgets - so that doesn't help!! Partially I think this is because they had difficulty understanding which bugs were most important. We actually have many usability-oriented developers, however, so making improvements within dev teams is possible! thanks.
    – Becky
    Nov 18, 2010 at 20:37
  • I couldn't agree more, @Mark. Although, I've been thinking of it the other way around. Understanding usability risks along the same lines as technical debt (why not call it "user debt"?) makes it easier to make an argument for an iterative approach to design. The bigger the upfront design, the bigger the user debt accumulated, and the bigger the upfront usability research required to mitigate that debt.
    – Justin
    Nov 28, 2012 at 23:40
2

The standard gauges come to mind, possibly combined with a color gradient going from yellow through orange to red.

Other analogies could be used: icon of a lady bug, a crockery pot, a drinking glass, a person, in various stages of "brokeness". Ie: a plaster on some part, a crack (or a wrinkly "smile"), a piece broken (off), ... completely shattered/squashed

Just be careful when using animal/human analogies that it doesn't become too graphical.

Improve this answer
3
  • Those are interesting visual representations of different grades of usability bugs, but how could you give a standardize meaning to "orange" or "ladybug"? How do you ensure the UX designer and programmer both understand what "orange" or "reddish orange" mean?
    – Lèse majesté
    Nov 18, 2010 at 10:30
  • The ladybug is a pretty standard symbol for bugs amongst developers... I assume usability experts are just as capable of picking up on the lady bug = bug metaphore? With regard to the color gradient: simply make an icon with the gradient as a sort of rainbow going from one side to the other, grey out the part that isn't interesting: for example yellow and just different shades of grey in the rest of the rainbow for the least sever type, then yellow and orange in the rainbow with the rest still in grey shades, etc. People tend to pick these up pretty easily.
    – Marjan Venema
    Nov 18, 2010 at 19:09
  • And of course if you use the lady bug metaphore, people will pick up on that even faster if you were to use a "whole" (as in one piece) lady bug icon as the icon for all bugs/ issues.
    – Marjan Venema
    Nov 18, 2010 at 19:10
2

Visuals, especially demonstrations, is what I've seen make the most impact.

This was in an Agile setting where the UX team was submitting stories to the product backlog and getting them voted on during estimation meetings.

Visuals always worked in terms of referencing screenshots, but the best was to actually show the problem in action, and describe why it was a problem.

If you're not in an Agile setting you must still be having development meetings at which issues can be raised - be ready to show what's broken and to discuss why you consider it "broken."

(BTW, for those unfamiliar with Agile, when you want something worked on you write it up and submit it to the big list of "what we need to be working on." The list gets reviewed weekly and discussed by development, UX, QA, product management, and key stakeholders).

Improve this answer
1
  • Hey there - we are not in an agile setting exactly, we do agile iterations, sometimes referred to a spiral, but we are a very large team making some pretty complex software. there are lots of triages and designers always attend and weigh in. We are incorporating lots of descriptions, storys and screens, but we are dealing with large numbers of bugs and don't always have the time to give each what they need.
    – Becky
    Nov 18, 2010 at 20:24
0

Usability is not programming.

It would be misleading to create such a gradual system.

If you really think something is so flawed that it somehow breaks the system (such as a missing button to take you to the next step) then fix it.

Otherwise it's just a usability problem and not matter how important we as practitioners might find them they are not by any metrics close to when code don't work.

In programming when thinks don't work they don't work period. To make it work you will have to fix it.

In usability you can get away with much more before the system breaks.

Improve this answer
9
  • 1
    If a usability bug is so bad that a significant portion of users are unable to use the application, then would you not consider this a system-breaking bug? And, sure, usability usually deals with the areas in between broken and optimal, but that's why a metric would be useful here. A meaningful metric might be the percentage of users that the bug impacts. This way you don't spend 90% of your time micro-optimizing for that 1% gain, meanwhile you're losing 50% of your visitors because you put your checkout screen behind a sign-up form.
    – Lèse majesté
    Nov 18, 2010 at 10:27
  • 2
    You won't find that out without doing A/B testing. You can't actually usability test yourself to such a conclusion. The "bug" would be part of the analytics process where you might find a considerable amount of dropoffs. But to test that properly you will have to implement it again and see if it works. I know there are many people who like to think that usability testing is solving these kind of problems. But it's not. AB testing is (which is different). You won't know the severity before you actually tried it out in reality. And then you might as well fix it.
    – ThomPete
    Nov 18, 2010 at 11:53
  • You can figure out some usability problems without testing. But that's not the point. Some usability problems cause users to be unable to use any of the functionality that was developed, or they will refuse to. If you have competition, users can choose the competitor instead. So less functionality that can actually be easily used can make a lot more $ than more functionality that you can't figure out (because in your mind it is not more functionality). Besides, your comment isn't even true of programming - things can work poorly or be hard to maintain, it's not just work or doesn't.
    – Becky
    Nov 18, 2010 at 20:31
  • I should point out that I'm not trying to make the usability bugs more severe or more important than functional bugs. I'm trying to integrate them with the process while using it to communicate clearly amongst widely distributed teams. We have a lot more usability bugs than functional bugs, however, and many developers that care about usability - we just want words for communicating in a clear language about the issues we have.
    – Becky
    Nov 18, 2010 at 20:33
  • You won't know what usability problems cause users to be unable to use any of the functionality unless you actually implement it. It's simply not possible and I am kind of surprised you would seem to think otherwise. Most real usability problems won't be visible until you actually implement them in real life. There are plenty of examples of almost impossible sites from a usability perspective that are doing just fine because people are want the product/service so much that they are ready to endure the pain. So it makes no sense to label different problems unless you are going to fix the worst.
    – ThomPete
    Nov 19, 2010 at 8:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.