Usability Evaluation

Usability is a measure of interface quality that refers to the effectiveness, efficiency and satisfaction with which users can perform tasks with a tool. Evaluating usability is now considered an essential part of the system development process. Evaluating a system’s usability is very important because it can tell you how usable the system is for the users. Sometimes developers are concentrating on developing the correct product in the correct way but they omit making the product usable, and as a result the users will not use it to it’s full potential.

Considering the above, we have to make sure that while developing Hive, we must consider that it has to be usable. Since Hive has not been developed by us, we could not conduct a proper usability evaluation, so we explain how the usability evaluation will be achieved after Hive is finished. For this, we state below the 10 rules of Heuristic evaluation by Jacob Nielsen, and we explain in every rule what we will consider and what measures we can take so Hive meets all of these 10 rules.

1) Visibility of system status

The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.

Considering this rule we have to make sure that Hive keeps the user informed using techniques such as site maps and appropriate status messages.

2) Match between system and the real world

The system should speak the users’ language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.

Considering this rule we have to make sure that Hive’s messages and images will have a meaning to the real world too, so the users can understand them easily.

3) User control and freedom

Users often choose system functions by mistake and will need a clearly marked “emergency exit” to leave the unwanted state without having to go through an extended dialogue.

Considering this rule we have to make sure that Hive will give the opportunity to user to easily escape from an unwanted state.

4) Consistency and standards

Users should not have to wonder whether different words, situations, or actions mean the same thing.

So to make sure that Hive meets this requirement we will make Hive consistent without having unambiguous objects.

5) Error prevention

Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.

Considering this rule we have to make sure that Hive will prevent users doing mistakes, by using confirmation buttons in almost every significant action they do.

6) Recognition rather than recall

Minimize the user’s memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.

Considering this rule we have to make sure that Hive is going to be as easy to a new user as an experienced user to use. This is achieved by making them recognizing options and objects, not recalling them.

7) Flexibility and efficiency of use

Accelerators — unseen by the novice user — may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users.

Hive will allow users to tailor their experience with frequent actions by including options such as hotkeys, or user-created shotcuts.

8 ) Aesthetic and minimalist design

Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.

We will try to make Hive as minimalist as possible without using much pictures, colours or animations that are redundant and not needed. Also, the information given to the user will be as small as possible so the user observes the right information.

9) Help users recognize, diagnose, and recover from errors

Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.

Considering this rule we have to make sure that Hive will provide good error messages so the users understand what they did wrong and give them the opportunity to recover from them easily.

10) Help and documentation

Even though it is better if the system can be used without documentation, it may be necessary to provide help.

Every big project needs to have a help option that will guide the user how to use the system. Hive is not an exception so we will make sure that help options are provided.

So having set these rules we can evaluate Hive’s usability by a simple table.

To make sure the results are reliable we have to make sure that we will give this table to many people from different cultures, social status and educational status. Also we (developers) are going to rate the usability of Hive too.

Also if we want to be more precise we can break these rules into points so the users who will evaluate the system will understand better what each rule means. So for example, the rule ‘Aesthetic and minimalist design’ can be divided into some criteria as follows.