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
1 Strive for
consistency.
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.