If you’re working on a product and have no particular understanding of UX, you can still do a basic UX review to stop the most obvious disasters. This will not be as good as getting a UX expert or experienced UX-QA to review the product, but it will be much better than nothing.
We’ve all worked with testers who were bad at their job; it was frustrating and felt like a giant waste of time and effort. But hold on to those bad testers: they’re more useful than you think.
Some bugs, even quite severe ones, can seem to your users like very nice features. Bugs that are likely to reach this status are those that make work smoother at the expense of security (for example, not enforcing part of the permissions mechanism), faster by letting users skip steps that should be mandatory (for example, leaving fields blank) or simpler by making assumptions (for example, setting default values where a user should really be forced to make a choice). When you fix these bugs, your users won’t thank you. In fact, they might complain; as far as they’re concerned you just damaged their user experience.
Designing something? “Simplicity doesn’t happen accidentally. It needs to be actively cultivated. Complexity is what happens when you aren’t paying attention”.
Technical writers have a very clear goal: explain the interface. That means they notice, instantly, when it’s inexplicable. If your interface is a confusing mess with overly-complicated procedures, buttons that make no sense, important options hidden in sub-menus and related options kept a mile apart, it’s not only hard to use – it’s hard to explain.
So if you, as the QA, are not sure about your UX – ask your technical writers. They know, and are quietly seething. And if you ask nicely, they’ll give you a well-worded document explaining just how bad it all is, saving you lots of work.
The only way to improve, the internet keeps telling us, is to push yourself past your comfort zone so that you’re always learning new things. Writing day in and day out, however, can mean you start to churn out documents on semi-automatic, settling for your current skill level and never improving. In fact, some of your skills, like editing, may deteriorate from lax use.
Here’s a quick writing tip for user manuals: don’t add your images to the manual until you’re done writing your text.
This has two advantages. The first is that when you add images one at a time over the long course of writing a manual, it’s easy to overdo it. When you add them all at once, you’re likely to reduce the overall number of images to just right.
The more important advantage is that it will help you write a text that can stand on its own, without the aid of the images. Remember that applications that read out text (for the visually impaired) don’t describe the image, nor are they always very clear when the manual is printed out. Make sure your text can stand on its own.
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.
The User Experience Stack Exchange has a nice discussion about confirmation buttons and colours, with lots of good points about clear communication in UI.