Life is what happens when you are making plans… Well, I made a lot of plans and a lot happened instead, but no complaints here, because what keeps me so busy I have no time for blogging, are good things. I organize my wedding and… I am a captain of Bug Honor Reopen team what will represent PGS Software in TestingCup – the Polish championship for software testers ( I’m sooo proud of our team!).
I personally like heuristics – when properly used they can help you a lot, whether you just start testing a specific thing or in a specific way or you have been doing the same thing in the same way for quite some time and therefor you are looking for some ‘fresh air’. When put to good use heuristic can be like a shortcut to get where you need to be quicker and easier.
Today I’d like to tell You about using ten usability heuristics for User Interface design brought to us by Jacob Nielsen and Rolf Molich. These were listed as directions for UI designers but we testers can use them to check whether the designs prepared for a customer will not only look nice but also be functional and help him in his business or, if we test an already existing things, what improvements could we propose to make the project better and more valuable.
1.2Visibility of system status.
Have you ever gotten lost somewhere? You look around and you can’t recognize where you are or how to get where you were going to before or maybe you are not even sure where were you going to in the first place.
This is how a user can feel, if he is not properly and on time informed where he is in the system.
When testing, pay attention to the information user is getting. Are there breadcrumbs? Or maybe the current position is highlighted in a menu? If you can not easily tell where in the system you are or how to go back to higher level it calls for an improvement.
Note that what is good on desktop may be a problem on mobile – if the breadcrumbs take half of the mobile device’s screen user will probably find it more irritating than useful.
2.Match between system and the real world
Even though being creative and innovative is generally a good thing, sometimes re-inventing the wheel is not the best idea. Whether what we are testing is a mobile application for booking beauty parlor appointment, big system for buying tons of rock material or a simple web game application it always goes back to real, material world somehow. Putting an important button in the least obvious place might be good for a solve-a-mystery game, but for all other instances it won’t be a good idea.
Buttons, link, system elements should be in places where user will look for them.
If You are testing an accounting system – it should not contain not existing operations (like “Book an invoice with minus VAT”) and e-shop with non-existent products categories won’t be loved by users (unless you are selling gag gifts, then it may be an interesting idea).
User has to understand what the system is communicating to him. “Buy” looks better than “acquire an item through a process of exchanging the financial asset for a desired object”. If the words or language used will confuse the user, he will not be happy. And we want him happy, dammit!
3. User control and freedom
Everyone had lived through it at least once: you click something and about 0.2 seconds later you are like “Shit, how do I undo it???”
Check if system asks for confirmations before deleting or updating data. Can user undo certain actions? These are of course issues tightly tied to the business flows inside the system, but error is a human thing and in any case it’s better to be save than sorry.
Let’s say it is a mobile app for ordering food online. If on the design of a specific food page there is no menu or link to the list of foods, no way to go back to the upper category other than back button on the device – that’s not a good design. Lack of a way to go back is a serious bummer for an app’s usability.
4.Consistency and standards
Always take a time to check if the system you test is consistent when it comes to naming things or actions, design of action buttons, placement of similarly functioning buttons and links in different places etc.Different parts of the system should be alike enough, so that user will not wonder if he somehow got to the other side of the mirror. Sub-pages of one website should be consistent in layout and element naming etc.
But don’t make different things too alike…
Let’s say there is a system where people who need a help with some home chores post offers and “helpers” can contact them to offer their services. Offer can be visible for everyone or just for helpers that you already had contact with – if everyone see it, it is in open mode. Also, an offer has a status – draft before publication, open when it’s posted and closed after the helper is chosen. Both mode and status can be open. So when someone says open offer, does he mean status or mode? Possible problems here I sense…
“Better save than sorry” does not sound like the newest rule, and yet it proves to be problematic in implementation.
Was every situation thought about? Are the corner cases taken care of? I admit – I like checking all these little things, conditions that maybe were missed during planning and coding. If you have ever used a similar system, was there something in it it didn’t work properly? Check it here also. What if user will use the search field? What if he clicks the same action button three times quickly, what if…
Having a happy stroll down the let’s-be-a-stupid-monkey may disclose some problems that need to be fixed before they are found by an inexperienced user with a slow internet connection…
Also, trying to break the system is kind of fun.
6.Recognition rather than recall
User has a memory of a proverbial goldfish. Three seconds and… it’s gone. To help him in this predicament system should let him choose from options than making him remember how to do things or where to find things.
Check if the fields user has to fill have labels or maybe just are pre-filled with text that disappears when you start typing? If there is a process user has to go thru – is he informed at each step where is he? Can he go back easily? If there are instructions are they presented in every place where they are needed or only in one place user would have to go back to if he forgot a vital step/detail?
7.Flexibility and efficiency of use
Let’s be honest – when it comes to computers and mobile devices every split of a second feels like an eternity. Especially when you are waiting on something to be loaded on the web site or in an application…. Most users get irritated in a few seconds and will go somewhere else for what they need. That is why testing the loading times is important and may be a good starting point for some optimization done by the dev part of the team.
When it comes to the subjects of flexibility, it is connected with accessibility (at least IMHO). Dark grey text over black background is hard to read for most users and nearly invisible to those with visual impairments. It might be a tester’s duty (and a privilege) to help the team make a product accessible to all users – test the contrast, headings hierarchy, use keyboard instead of a mouse. Tester insights may be what brings the team closer to making a perfect product.
8. Aesthetic and minimalist design
Dev team and graphical designers can do a lot of cool stuff. But sometimes too much of cool stuff put together is not cool anymore. All colors of a rainbow on a web page will look unprofessional and too much information will confuse the user.
Are the information popups helping or just disturbing the view? Is it easy to navigate through the page or maybe it is easy to get lost in the myriad of fancy icons? Are animated elements are showing user important things or are they just making him distracted?
9. Help users recognize, diagnose, and recover from errors
While in the development process it’s perfectly fine to use just codes for errors – it helps dev team to find out what is happening. When the system is out it is not enough anymore. As the 404 and 500-something errors are most common these should be styled and give user an information that something went wrong and a possibility to get back on track (link to home page or to contact form). As for other errors – user should not see blank page with ‘something went wrong’ or a code written over it, he already knows that much. Also, if the page is for example in Polish, errors in English will look bizarre. User should get this information (simple and nice-looking) or maybe a game like Google’s dinosaur 😉
10.Help and documentation
Honestly, without FAQ section users will have WTF moments. It should not be required to read a long documentation to use a system/application it usually is good to have help section available and some additional information in place for the user, just in case.
Check if it is easy to find out what to do, if the user unfamiliar with the system would need a lot of time to orientate himself or would he start using it with occasional helper pop-up or hover-over text.
We testers have our obligations to the user. Do not just test if everything is pixel perfect with the design and step-by-step as in the diagrams. Take time to make sure the user will have a good experience with the system using the 10 heuristics above.
Will you always be heard and your suggestions will be implemented? No, but they may be an impulse to discuss some elements and make changes. You won’t always have time for everything and you (and your team) won’t achieve perfection, but you can try and hey, that matters too!
Any thoughts on the topic? Maybe you tried testing with Nielsen & Molich? Drop a line about your experience!