Take a testing walk with Nielsen & Molich (or 10 heuristics for UI design) (Part 1)

July 30, 2018 Marta Woźniak-Semeniuk

Few words of an introduction – as a tester I personally really like heuristics – when properly used they can help you a lot. Whether you are testing using an exploratory approach, going step by step with a scenario or you have been doing the same thing in the same way for quite some time and therefore you are looking for some ‘fresh air’ – heuristics can help you do it better. When put to good use heuristic can be like a shortcut to get where you need to quicker and easier.

In this post I’d like to tell you more about using ten usability heuristics for User Interface design brought to us by Jacob Nielsen and Rolf Molich. Though these were originally listed as directions for UI designers, 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 them in their business or, if we test an already existing thing, what improvements we could propose to make the project better and more valuable. These 10 heuristics are also strictly connected to User Experience.

Not to mention, that it is always worth looking at some heuristics or rules prepared for developers – the more we testers know about how they do things, the more ways to test we can come up with.

Let’s go then!

1. Visibility 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 you were going to in the first place?

This is how a user can feel, if they are not informed properly and on time about where they are in the system and/or what has just happened.

When testing, pay attention to the information user is getting about current system status and their position. User should also be always visibly informed about how they can go back to previous place/status (if this is allowed by the system) and how to move to another place/change status.

Generally, every action of a user that has an effect should also be followed by a message to this user regarding that effect. If the user did something right will they expect the conformation info to be rather green or red? [Although that may depend on a cultural context and should be checked as a part of a background check made by UI designer and/or another team members in case of creating a product for the users from a different Kulturkreis].

If you cannot easily tell where in the system you are or how to go back to a 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. A good idea is also to test on both a laptop and a monitor screen – the resolution can be surprisingly tricky when it comes to menu.

Questions to ask:

  • Are there breadcrumbs? Or maybe the current position is highlighted in a menu?
  • Can the user clearly locate themselves in the page/system structure?
  • How easy is it to navigate through the page/system?
  • Can user get to all places he should on a clear path? Or maybe some parts of the system are accessible only by knowing a specific route?
  • Are there specific requirements connected to usability? (legal or otherwise)

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 is always linked to the real, material world somehow.

Buttons, links or system elements should be in places where user will look for them (because they are used to seeing them there). Putting an important button in the least obvious place might be good for a solve-a-mystery game, but for all other instances it will not be a good idea.

If you are testing an accounting system – it should not contain non-existent operations (like “Book an invoice with minus VAT”). An e-shop with non-existent product categories won’t be loved by users (unless you are selling gag gifts).

Users are used to seeing and using certain things in a certain way. Most users will consider an underlined text a link – if it is not, they might think something is broken.

User has to understand what the system is communicating to them. “Buy” looks better than “acquire an item through a process of exchanging the financial asset for a desired object”. This is a very important thing for the messages aimed at the user to be as concise, unequivocal and understandable as possible. Sure – we “only” test but it is better to propose a solution and accept its refusal than to not say anything and know we let go of an opportunity to make it better.

If the words or language used confuses the user, they will not be happy. And we want them happy, dammit!

Potential questions to ask:

  • Are the basic elements (e.g. menu, buy button or the shop basket) easy to find?
  • How hard will it be for a first-time user to get around and understand system messages?
  • Is the language used matching the target base?
  • Would I as a user understand the process I am going through and how to get where I want to be? [This is of course more of a process question, but worth asking nevertheless].

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 “Oh gosh, how do I undo it?!”

Check if the system asks for confirmations before deleting or updating data. Can user undo certain actions? These are of course issues tightly bound to the business flows inside the system, but error is a human thing and in any case it’s better to be safe 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.

Potential questions to ask:

  • Are actions of deleting/changing data guarded from accidental triggering?
  • Is user allowed to do something they should not do or something that may potentially harm their interest?
  • Can user easily go level up? (navigation)
  • Is user asked to make a choice in situations where they cannot really choose?

To be continued.

Last posts