KP-Lab heuristics

KP-Lab heuristics are understandable

In the evaluations executed by persons not involved in KP-Lab the statements about KP-Lab heuristics, in general, were positive. The categorisation of the KP-Lab heuristics were understandable. The KP-Lab heuristics were seen to be close enough to the well-known Nielsen’s heuristics, but still giving a different perspective and emphases than the Nielsen’s heuristics.
It was also stated that the categories in the KP-Lab heuristic list could be made clearer by introducing a subdivision under the category, for example, indicating the description of the meaning of the categories by giving subdivision: a), b), etc and by having bullet lists as well as more images as examples.

KP-Lab heuristics were also used for categorising the found usability problems

Using KP-Lab heuristics for clustering the problems and improvements according to the KP-Lab heuristics was seen to be a good practise. The practise emerged from the evaluators outside of KP-Lab.
The practise to categorise according to KP-Lab heuristics was adopted to present a summary of the problems found, but it is not an effective manner to give feedback, for example, about GUI problems to the technical partners or about the pedagogically related usability problems to the pedagogical partners. It is too extensive for these practises, but it does work as background information when needed. To avoid this problem a reporting template was formed (see Reporting template).

Current KP-Lab heuristics

The aim of the KP-Lab heuristics is to create a common understanding amongst usability experts in order to evaluate the user interface of tools.
(The term “usability expert” refers to any person that has enough knowledge about usability and heuristic testing/evaluation manner that s/he can perform the test/evaluation. These types of persons could be experts in at least one of the following fields 1) user interface design or evaluation or 2) trialogical principles.)

1. Visibility of system status:

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

1a) Feedback on user actions

  • When a user initiates an action, some indicator should be provided, visual or auditory (or both), that the application has received the user’s input and is operating on it.
  • This also applies during the operation (e.g. when doing multiple selections, when dragging/dropping…): some visual indicators should be provided for the “progress of work”.
  • As much information as possible should be provided about how long operations might take.

1b) Feedback information (including error messages)

  • When application cannot respond to user input because it’s processing a different task, the user should be informed of what to expect and description should be provided of any delays, why they occur, and how long they will take (e.g. “loading times”).
  • The user should be told of how to get out of the current situation whenever possible.
  • Direct, simple feedback that people can understand should always be provided. For example, most people would not know what to do if they saw the following message “The computer unexpectedly crashed. ID = 13".

2. Match between system and the real world: proximity

2a) Use users’ language
The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms (The underlying layer should not be made visible to the user) or KP-Lab terms (KP-Lab terms should be made understandable) or specific design jargon, etc.

Note: “Be aware of technology slang, pedagogical slang, theoretical slang, end user slang.”

2b) Follow conventions
Real-world conventions should be followed (also visual conventions), making information appear in a natural and logical order.
Proximity in this context means that whenever there is a need to go beyond the existing conventions it should be done in a manner that the new “issues” introduced are in the vicinity (near proximity) of the users. Too broad leaps from existing conventions to new appearance and actions add cognitive load, make interpretation and appropriation harder.

Proximity: It is the distance between the present everyday actions of the individuals and the historically new form of the societal activity that can be collectively generated as a solution to the double bind potentially embedded in the everyday actions. (Engeström, 1987).

3. Consistency

3.a) Visual appearance
Consistency in visual appearance means:
  • to be able to find things in the same places all the time, identical signs mean the same.
  • to the standard elements (of visual elements) of interfaces to ensure consistency
a) within your application and to benefit from consistency b) across applications. Consistency in the visual interface helps users to learn and makes it easier for users to recognize the graphic language/grammar of the interface—for example, once users know what a checkbox looks like, they should not be asked to learn another symbol for executing similar actions.

3.b) Effect of operation.
Consistency in the behaviour/operation of the interface means that people learn how to do things such as clicking and pointing only once. After that they can explore new applications or new types of features using skills that they already have (example of inconsistency in operations: shortcut for open file: Microsoft: ctrl + c = copy and Mac apple key + c = copy)

Questions to help detecting consistency:

Is your “application” consistent:

  • Within itself?
  • With earlier versions of your product?
  • In its use of metaphors?
  • With people’s expectations?

4. Back and forward tracking (awareness of users past and present operations):

Users should be provided with a possibility to easily see the sequence of operations made and a possibility to jump back to previous state of operations and back again.

This might include an automatic save to have the different states the user has passed (somewhat like versions) or a Photoshop-like history pallet that enables jumping back and forth. Figure 1. is only an example and is not meant as a suggestion as to what the feature should look like or how it should be implemented.

Figure 1 Example image of history tracking

Of course utility of such a feature should be evaluated case by case. Various granularities must be contemplated ranging from simple one-step undo/redo up to the example provided in figure 1.

5. Recognition rather than recall (or WYSIWYG):

  • GUI objects (affordances/possibilities and constraints), operations, and options should be made visible.
  • The user should not have to remember information from one part of the dialogue to another.
  • Features in the interface should not be hidden by the use of abstract commands.
  • If there is a need to initially “hide” features, it should be done in a way that gives people information (clues, affordances/possibilities) about where they can find more choices/features.

6. Flexibility of use

The user should be able to personalize/customize the interface to his/her taste. This means surface customization for example:
  • The ability to change the places of menu bars,
  • Size of menus,
  • Change font choices, colours, etc.
  • It also means that the user can find and define accelerators and is not forced to use for example menus.
  • Users should be allowed to tailor frequent actions.

The freedom must not imply a lot of customization menus/tools that complicate the interfaces. It can also mean that the system has skins where a skin entails a set of configurable items.

7. Providing relevant information:

Dialogues should not contain information, which is irrelevant or rarely needed. Information should not be duplicated unnecessarily. A well-organized interface that supports the user's tasks fades into the background and allows the user to work with less distraction. Reduction of information can be done, for example:
  • By placing additional information and settings in a separate window that can be hidden or shown by the user
  • Complexity can be reduced by letting the user customize the interface
  • Clear structure of the importance of the presented information should be used

8. Awareness:

8 a) Enough affordances and clues for enhancing awareness of others should be provided. Such are, for example:
  • Who are on-line,
  • What is their status,
  • Means to communicate with other user and
  • Action logs per session
8 b) It should be possible to perceive relevant history in relation to the context and content (i.e. items of use), such as:
  • Recent changes and
  • Versioning

8c) Transparency of access rights and ownership:

  • The user should be provided with an unambiguous indication of access rights and ownership of pieces of information used.
  • The system should provide the user with information on the current status of a particular piece of information (document, object of activity, etc.), e.g. it is only visible for the single user or accessible for a particular group.
  • The user should always know whether s/he actually acts in a private or shared space.

9. Help & documentation:

  • The more complex the system, the more important it is to have an on-demand help system (e.g. right click, help with the task at hand and/or an instant problem-solving feedback system of already often asked issues, including explanations of why something is done the way it is).
  • This can lead, when necessary, to a true wizard approach, with a list of concrete steps to be carried out, which can also include images or animations of steps to be done.
  • Care should be taken that the act of reading the “help” does not prevent performing other activities at the same time.
  • A space/place should be provided for the user to interact which each other to discuss different ways of tool usage and to present their own solutions to found problems (appropriation support)
  • A place should be provided to report bugs to developers e.g. bug collector, that collects bugs automatically or as a possibility send a “note of the problem” to a collection system.
    (For similar approaches see: Apple Computer Inc. 2006, Dourish, 1993, Mørch, et al. 2005, Nielsen, 2005, and Pakdel, 2006).


Apple Computer Inc. (2006). Apple Human Interface Guidelines. (Retrieved January 31, 2007, from

Engeström, Y. (1987). Learning by Expanding: An Activity-Theoretical Approach to Developmental Research. (Retrieved January 17, 2007, from

Nielsen, J. (2005). Ten Usability Heuristics. (Retrieved January 31, 2007, from
Pakdel, A. (2006). Dokeos User Interface Guidelines. (Retrieved July 2, 2007, from

This page is a category under: usability and under Category Of Usability Heuristics

  Page Info My Prefs Log in
This page (revision-3) last changed on 18:24 25-Mar-2017 by merja.

Referenced by

JSPWiki v2.4.102