Some bugs are a work of art. Consider a login page I encountered a few weeks ago. Two fields, one Submit button – so far so obvious. But above the button was the text “Do not press Enter to log in; use the Submit button”. I pressed Enter, of course: the page was refreshed and the fields were cleared. Someone at that company recognized the bug with the Enter key, understood that it’s very likely to happen to regular users, and rather than fix it – warned the users against it.

Another example: on a recent project, I could group items only with drag and drop, and un-group them only with Ctrl+Left Arrow. As if this was not confusing enough, there was no clue in the interface that you could perform either action, let alone how.

What these bugs have in common is that they’re UX-based. Accepting Enter (or at least not clearing the form) and making the do-undo options match are basic user experience decisions. These things went through design, development and QA without anyone saying “we’re abusing the users here”.

Let’s talk about the QA. It boils down, as so many things do, to mindsets and ignorance.

I’ve met three mindsets that make QA ignore UX bugs. The first is a mindset that accepts the design without comment; if the problematic UX was in the design, then it’s not problematic. Since accepting the design as gospel is all-round the wrong way to test (there’s no such thing as a perfect design; designs have as many bugs as the developed product, sometimes far worse ones), this is a mindset that simply needs to be washed away.

The second mindset recognizes that UX bugs exist but refuses to deal with them. I’d hoped this one had died out already, but I can’t help thinking it’s behind the “Do not press Enter” bug. Much like the previous mindset, it’s pretty much binary (my problem/not my problem), and the switch is simply flipped to the wrong side.

The last mindset is where it gets difficult. Testers look first for the big, juicy logical bugs that are fun to find and block the whole version. This is not at all a bad idea, but it shifts the UI/UX testing to the end of the cycle, when the testers are already very used to the interface. They become blind to its problems, even ones that they once found annoying. There are three easy solutions to this: assign a tester to spend a day or two just on the UX, teach your testers to jot down every UX bug they see and file reports later on, or hire testers so cranky that they never get used to UX bugs.

There is also the factor of ignorance of good UX; it’s a huge area, with lots of nuances. But: you’re not asking testers to design the interface or come up with solutions. You’re simply asking them to point out the worst and most obvious mistakes. That’s much easier, and a skill they can pick up with a fair level of competence in a fairly short time. It will not be as good as having a UX expert come in, but it will be better than nothing. So while ignorance might deter testers from starting UX testing, it’s not a good long-term excuse.

The short version: ignoring UX bugs is a sign of either bad testing mindsets or ignorance. Find out what your QA team is suffering from, and help fix it.