Heuristic Analysis of v4 Prototype
Resources
Syntax 2.0:
Heuristic Evaluation
Summary
Two types of Heuristics have been used:; Normans 7
principles and Schneiderman’s 8 Golden
Rules
Problems: some of the heuristics apply to more
complex or screen-based systems so some cannot be applied to the project. However,
in large I feel that it was a useful analysis of the prototype. There is no
room for error except of failure to interact, and the design offers informative
feedback at every stage. There is help and documentation available and there is
a low demand on the users memory.
Table
1: Severity Rating; used to rate problems identified
0 - don’t agree that this is a
usability problem
1 - cosmetic problem
2 - minor usability problem
3 - major usability problem;
important to fix
4 - usability catastrophe; imperative to fix
Tasks:
A. Turning
on the prototypes
B. sending
the message
C. receiving
the message
D. receiving
feedback that the message was sent
As the system is so small, the tasks will be
analysed as a whole rather than individually. Individual analysis was
attempted, see below but it was noticed that it this was a less effective
method of analysing the system.
Task
|
Heuristic
|
Analysis
|
Problems
|
Severity
|
A. Turning on the prototypes
|
1 Visibility of system status
|
On/off switch has o/1 indicator.
|
No
|
n/a
|
2 Match between system and the real world
|
n/a -it is a tangible interface
|
|||
3 User control and freedom
|
1 Visibility of system status
The system provides feedback at
each of the four task stages. The receiving (Tiger) system sends feedback
communication prior to the playing of the audio track, so the end user knows
that the other user is aware that they got the message if they hear the audio playing.
The system is very simple. It is useful that the two feedback systems (LED and
Buzzer) are different in their form to remove any confusion.
2 Match between system and the
real world
The system is not screen based,
which is different to many of the interactive systems that users would have had
access to. Whilst this poses some problems, users are generally familiar with
soft toys. Information doe appear in a logical order, and in the same way each
time.
3 User control and freedom
The user only has the option to
interact in a single way, so the only error that can occur is the failure to interact
at all. There is no support of undo or
redo. My severity rating: 0
4 Consistency and standards
There is no ambiguity within the
interface; the two feedback systems in the Monkey are distinct i.e. one is
sound and one is light. This was an improvement from testing on the the version
3 prototype.
5 Error prevention
Because of the limited amount of
errors that can be made, there is little error prevention. However, to prevent
people from thinking that they have interacted with the monkey when they haven’t,
there is an indicator buzzer. It is the same with the light validation of the message
reception.
6 Recognition rather than recall
The system is fairly simple, but
it is not self-explanatory. This is one of the security features; anyone
stumbling upon it would not necessarily know how to use it. However, once a
user has been introduced to the design it is so simple that it is difficult to
forget, and the visibility of certain physical elements i.e. metal contacts in
the hands would help users to recognise how to interact with it.
7 Flexibility and efficiency of
use
There are no accelerators for
experienced users due to the simplicity of the design
8 Aesthetic and minimalist design
The design has no dialogue, but
the equivalent here is the light/buzzer feedback system which does not contain
anymore information than is required.
9 Help users recognize, diagnose,
and recover from errors
The system uses a deductive error
handling technique; the user is not told ‘the other user isn’t there… here’s
what to do, they simply do not get an indication light if something goes wrong.
There are error symptoms instead of statements. Severity=0
10 Help and documentation
Error handling is included separately in a manual
which helps users with heuristic 9. There is a troubleshooting section which
specifically deals with error systems. An ideal system supposedly needs no
documentation, but this does due to the specialism of tasks and the need to
illustrate its purpose and functionality. Users cannot relate it to anything
else, so they have no conceptual model to compare it with. This system has to
have a manual by default, so the severity rating=0
Normans Heuristic Analysis
Only a single action can be executed, so this heuristic does not apply.
2 Enable frequent users to use shortcuts.
There are no shortcuts to the simplicity of the interface.
3 Offer informative feedback.
Description: For every operator action, there should be some system feedback. For frequent and minor actions, the response can be modest, while for infrequent and major actions, the response should be more substantial.
There is system feedback for every operator action. However error feedback is deductive; where there is no feedback the user knows that there is a problem. Another way to address it would be to provide a specific indicator if a message received confirmation is not received by the monkey within a certain length of time. Severity=1. This possible improvement could be implemented, but the need would be determined by further user testing.
4 Design dialog to yield closure.
Description: Sequences of actions should be organized into groups with a beginning, middle, and end. The informative feedback at the completion of a group of actions gives the operators the satisfaction of accomplishment, a sense of relief, the signal to drop contingency plans and options from their minds, and an indication that the way is clear to prepare for the next group of actions.
There is only one set of actions; sending a message and then receiving conformation that it was sent and then successfully delivered. There is feedback once this is completed so I feel that it meets these requirements.
5 Offer simple error handling.
Description: As much as possible, design the system so the user cannot make a serious error. If an error is made, the system should be able to detect the error and offer simple, comprehensible mechanisms for handling the error.
The only error that the user can make is either forgetting to turn the system on, or not successfully closing the Monkeys hands together. Error handling is provided by the manual, and there are straightforward solutions.
6 Permit easy reversal of actions.
Description: This feature relieves anxiety, since the user knows that errors can be undone; it thus encourages exploration of unfamiliar options. The units of reversibility may be a single action, a data entry, or a complete group of actions.
There is no room for error, just of failure to execute tasks. Reversibility would go against the concept of ‘transient memory’ so this cannot be implemented. Severity=0
7 Support internal locus of control.
Description: Experienced operators strongly desire the sense that they are in charge of the system and that the system responds to their actions. Design the system to make users the initiators of actions rather than the responders.
The operators roles are designed as one initiator and one responder.
8 Reduce short-term memory load.
The limitation of human information processing in short-term memory requires that displays be kept simple, multiple page displays be consolidated, window-motion frequency be reduced, and sufficient training time be allotted for codes, mnemonics, and sequences of actions.
The systems simplicity removes
any memory load on the user. The user only has to remember how to execute the
single action correctly.
No comments:
Post a Comment