UI Heuristics — QA With The User In Mind (Part 3)

This is the final part of a 3 part series on UI Heuristics. You can read the first part here and the second part here.

8. Aesthetic and minimalist design

Dev teams and graphic designers can do a lot of cool stuff, but sometimes putting too much of this together just isn’t cool anymore. All the colours of the rainbow on a web page will look unprofessional and too much information will confuse the user.

The more information you put in one place, the less important it all seems, so test how easy it is to fish out the most important stuff from all that’s there.

It’s also an area to consider colour-coding, such as how green usually signifies good and red denotes bad etc. This may mean that a message displayed in red, even if neutral in meaning, might be seen as bad news.

Furthermore, if the icon or picture should be clickable, test that it is completely clickable — even from the bottom-left corner, but not the line just below it, for example. If there is a slider, see what happens when changing pictures quickly, as well as how long it takes for these images to change automatically; is there enough time to read the information? Again, check different devices, resolutions and systems — something that looks clean and neat on a desktop may get a bit crowded on a smaller mobile screen.

Possible questions to ask:

  • Are the information popups helping or just disturbing the view?
  • Is it easy to navigate through the page or maybe it’s easy to get lost in the myriad of fancy icons?
  • Are animated elements showing user important things or are they just distracting?

9. Help users recognise, diagnose, and recover from errors

Whilst in the development process, it’s perfectly fine to just use error codes; it helps the dev team find out what’s happening. When the system is out, however, it is not enough anymore.

As 404 and 500-something errors are the most common, these should be styled and designed to give the user information that something went wrong, as well as the possibility of getting back on track (a link to the home page or a contact form, for example). As for other errors — the user just should never see a blank page with “something went wrong” or a code written on it, as he or she already knows this much. There should always be some element of constructive information — a link, a promise the team is on it, a prompt to reload or try later etc.

If there is something wrong in a form, there should be an indication regarding which field needs to be corrected. If the operation can’t be completed, the user needs to be informed why. If something went wrong — tell the user and propose a solution.

Also, if the page is one language, such as Polish, errors in another (such as English) will look bizarre. User should get clear information that’s simple and nice-looking, or something unique, like a game similar to Google’s dinosaur.

Possible questions to ask:

  • Are the exceptions handled?
  • Do the various 500 and 400 error pages containing user-friendly information?
  • Is the user given a constructive error messages?
  • Are error messages visible long enough for the user to read them?
  • Are error messages recognisable and easy to catch?
  • How hard is it for user to diagnose what went wrong?

10. Help and documentation

Honestly, without the FAQ section, users will have plenty of WTF moments. They should not be required to read long, extensive documentation just to use a system/application, but it’s good to have a help section available, as well as some additional information in place for the user, just in case.

Verify if it’s easy to find out what to do. Check if a user that’s unfamiliar with the system would need a lot of time to orientate theirself, or if they would start using it with occasional helper pop-ups or hover-over text. This “occasional” help should always be contextual — providing just the info needed in that particular place.

You should also see if all the help icons link where they should and have hover-over text displayed at the right point. Make sure that, as a first time user, you would be able to use the system using just what you are gradually being told, alongside the eventual help of the search and/or FAQ/Help section. If using the system requires having these sections constantly opened, something is wrong.

Possible questions to ask:

  • Is is easy for a first time user to use the system?
  • How long does it take to learn how to use the system?
  • How hard or easy is it to get additional help or explanations?
  • Do some processes require additional help? How much?
  • Is the Help/FAQ information useful (as well as concise and understandable)?

Last but not least…

The way I see it, we testers have our obligations to the user (and to our customers for whom we are making sure that the quality of the product made by our team is good). Do not just test if everything is pixel perfect with the design and step-by-step processes, as in the diagrams. This is the most important thing, sure, but most of the time designs, mock-ups, and requirements do not cover 100% of the system. If it’s possible — why not take the time to make sure the user will have a good experience with the system, using the 10 heuristics detailed in this series?

Will you always be heard and have your suggestions implemented? No, but they may be the impulse needed to discuss some elements and potentially 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! Every discussion and idea leaves us with something we learned and gives us possibility to do it even better next time.


Originally published at www.pgs-soft.com.