Work exactly as their name suggests:
* encourage verbalisation in interaction
* designer does not interfere with interaction
* discussion between designer and user
* user can ask designer for clarification or help
* designer can ask user to explain what they are doing and why
Designer sees actual interaction in practice, and can see obvious mistakes as users press wrong buttons etc. In practice, designers need to observe carefully (but unobrousively) in order to see the confusion, the indecision and so on that may precede even correct actions. Remember you are looking not just at initial walk-up-and-use effects, but those that cause problems even after some usage.
Sessions can be freeform and unstructured, as the user plays with the interface and explores the areas they are interested in, or can be task-oriented, in which relevant tasks are posed to he user who then works on solving them using the new system.
It is possible to extend these sorts of evaluations with video analysis, timing analysis (either from embedded software or from the video analysis - if one camera is on the user and one on the screen so that things can be synchronised), eyetracking systems (to see where the user's gaze goes) and so on.
Popular, relatively easy. Heuristics are a set of principles or guidelines culled from experience and practice that work. Can be general purpose, or specific to a particular domain.
Generic principles for heuristic evaluation
1. Feedback: inform the user about what is going on using appropriate feedback in a timely manner.
2. Everyday language: use simple language, avoid technical terms, follow real-world conventions to make things appear logical.
3. Undo: people make mistakes, so it should be easy to recover to a sensible point.
4. Consistency: doing similar things in similar places should have similar effects. Also, support the conventions of the specific types of computer and operating systems such as Windows or MacOS.
5. Recognition not recall: make next steps and critical information visible and memorable. Allow people to recognise what they should do next, not remember what it is.
6. Simple design: keep things crisp and simple, to minimise the information presented to the user. Make the design aesthetically pleasing to the target audience.
7. Expert use: provide accelerators (keyboard short cuts and advanced techniques) that allow experts to work faster.
8. Error recovery: try and design the system to prevent errors occurring, and when they do provide clear messages and suggest appropriate solutions.
9. Documentation: it is best to design a system that requires no documentation, but complex features or very different systems may need it. It should be well organised, (searchable and well structured), focussed on the task of the user, simple to follow with concrete steps, and concise. It should ideally be available on the system so it is accessible when needed.
Typically, a heuristic evaluation session for an individual evaluator lasts one or two hours. The evaluator goes through the interface several times and inspects the various dialogue elements and compares them with a list of recognized usability principles (the heuristics). In addition to the checklist of general heuristics to be considered for all dialogue elements, the evaluator obviously is also allowed to consider any additional usability principles or results that come to mind that may be relevant for any specific dialogue element or for the specific application.
The first pass: general feel for the flow of the interaction and the general scope of the system. The second pass then allows the evaluator to focus on specific interface elements while knowing how they fit into the larger whole.
Since the evaluators are not using the system as such (to perform a real task), it is possible to perform heuristic evaluation of user interfaces that exist on paper only and have not yet been implemented. This makes heuristic evaluation suited for use early in the usability engineering lifecycle.
If the system is intended as a walk-up-and-use interface for the general population or if the evaluators are domain experts, it will be possible to let the evaluators use the system without further assistance. If the system is domain-dependent and the evaluators are fairly naive with respect to the domain of the system, it will be necessary to assist the evaluators to enable them to use the interface. One approach that has been applied successfully is to supply the evaluators with a typical usage scenario, listing the various steps a user would take to perform a sample set of realistic tasks. Such a scenario should be constructed on the basis of a task analysis of the actual users and their work in order to be as representative as possible of the eventual use of the system.
The output from using the heuristic evaluation method is a list of usability problems in the interface with references to those usability principles that were violated by the design in each case in the opinion of the evaluator. It is not sufficient for evaluators to simply say that they do not like something; they should explain why they do not like it with reference to the heuristics or to other usability results.
(summarised from Nielsen)In the cognitive walkthrough, experts follow the series of actions that an interface will require a user to perform in order to accomplish some task to check the interface for potential usability problems. Usually, the main focus of the cognitive walkthrough is to establish how easy a system is to learn. More specifically, the focus is on learning through exploration. Experience shows that many users prefer to learn how to use a system by exploring its functionality hands on, and not after sufficient training or examination of a user's manual. So the kinds of checks that are made during the walkthrough ask questions that address this exploratory kind of learning. To do this, the evaluators go through each step in the task and provide a story about why that step is or is not good for a new user.
To do a walkthrough, you need four things.
1 A description of the prototype of the system. It doesn't have to be complete, but it should be fairly detailed. Details such as the location and wording for a menu can make a big difference.
2 A description of the task the user is to perform on the system. This should be a representative task that most users will want to do.
3 A complete, written list of the actions needed to complete the task with the given prototype.
4 An indication of who the users are and what kind of experience and knowledge the evaluators can assume about them.
Given this information, the evaluators step through the action sequence (item 3 above) to critique the system and tell a believable story about its usability. To do this, for each action, the evaluators try to answer the following four questions.
A. Will the users be trying to produce whatever effect the action has?
Are the assumptions about what task the action is supporting correct given the user's experience and knowledge up to this point in the interaction?
B. Will users be able to notice that the correct action is available?
Will users see the button or menu item, for example, that is how the next action is actually achieved by the system? This is not asking whether they will know that the button is the one they want. This is merely asking whether it is visible to them at the time when they will need to invoke it. An example of when this question gets a negative supporting story might be if a VCR remote control has a hidden panel of buttons that are not obvious to a new user.
C. Once users find the correct action at the interface, will they know that it is the right one for the effect they are trying to produce?
This complements the previous question. It is one thing for a button or menu item to be visible, but will the user's know that it is the one they are looking for to complete their task?
D. After the action is taken, will users understand the feedback they get?
Assuming the users did the correct action, will they know that. This is the completion of the execution/evaluation interaction cycle. In order to determine if they have accomplished their goal, the user needs appropriate feedback.
The details of the walkthrough should be documented well, noting the problems with each action and why they were caused (A-D) - if possible, feedback from the evaluator about positive things should also be captured.