In a lot of offices, if you’re not typing or clicking – you’re not working. It’s an odd view for any member of an industry that prides itself on thought and creativity. To analyse a problem, understand it and come up with a creative solution to it, you need to think about it. Thinking, for most people, requires not doing.
So stop. Think. You’ll do better.
If you’re getting dirty looks from your boss, employ some body language. Frown, tap your pen on your lip or your thumb on the space bar, stare at your computer screen as if the answer is about to jump out of it. This is universal for “I’m thinking in the most useful manner possible” and is usually enough.
And if all else fails, just follow this time honoured tradition: go think in the toilet.
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.
Continue reading “UX Review: Emergency Measures”
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.
Continue reading “Lessons I Learned as a Tester, 6: The Secret Usefulness of Bad QAs”
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.
Continue reading “Lessons I Learned as a Tester, 5: It’s not a Feature, it’s a Bug: Fixing Bugs Your Users Enjoy”
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.
Continue reading “Make Yourself a Better Writer: Treat Every Document Like a Writing Sample”
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.
Continue reading “Glossing Over the UX: Why Do so Many UX Bugs Get Past the QA?”