Operation

The language that is used for things such as operating instructions, button labels and displayed information should be clear, unambiguous and easily digested. It should not contain unnecessary jargon, colloquialisms, idiomatic expressions or convoluted grammar. Where possible, use explanatory icons, pictures or diagrams to aid understanding and provide for written text to be spoken for the benefit of users who have difficulty reading.

smartcards_operations

Supplement written instructions with pictures.

The user should be able to abandon any incomplete or unconfirmed requests at any time during a transaction. This should result in all inputs, such as money and cards, being returned and no further outputs being generated. The terminal should then return to the starting point of the transaction.

Operations such as entering a PIN, choosing from a list of options or typing in information, should not be cancelled or interrupted by system prompts until even the slowest users have had sufficient time to complete the operation. This includes reminders and timeouts.

Rationale

Some users may get a certain way into a transaction before finding that they are unable to continue. This could be due to a variety of situations, such as having become confused, coming across instructions or information that they cannot understand or being requested to provide inputs that they cannot make. This could happen at any time. They may feel that they will be able to carry out the transaction successfully if they start again or they may have to give up completely and try an alternative service. In either case, they will need to have any money or cards returned to them.

Completing an operation on the terminal will require the user to carry out a number of separate activities. These may include reading and understanding the instruction, choosing the appropriate action, recalling information and making the inputs. Each of these activities will take some time and different users will require different amounts of time, depending on their abilities and confidence.

Users who have poor reading skills or have difficulty understanding written text may have to read the instructions very carefully a few times before they can fully understand them.

Having read the instructions, choosing the appropriate action will take longer for users who have an intellectual impairment.

Recalling information such as PINs or personal details is more difficult for many older users or people who are tired or stressed.

Making inputs by pressing buttons or typing on a keypad can take much longer for users who have physical difficulties.

It can be very frustrating to be constantly prompted to complete a task and the stress that this can cause makes it even more difficult for the user. Ultimately, the worst thing is to be timed out after a lengthy process and asked to start again.

Directions and Techniques

The main technique is to keep it simple. Use everyday, jargon-free explanations. Avoid idiomatic expressions such as "on the one hand". Avoid long sentences by writing directly and concisely. Phrases like "on the one hand" are mere padding and can be removed without changing the meaning of the sentence. It is best if all instructions and information are written by experienced professional technical writers.

People who cannot read are often perfectly able to understand the same text if it is spoken. This can be achieved using either pre-recorded audio or speech synthesis. Speech synthesis, whilst more flexible, is often of much poorer quality and may be difficult to understand for some users and in noisy environments. An inductive loop facility may help hearing aid users.

Icons and diagrams can convey large amounts of information in an easily and quickly digested form. This may be the only medium that can be understood by people who are deaf and have poor literacy.

Audio warning signals should:

  • Use frequencies between 300 and 3,000Hz because the ear is most sensitive to this range;
  • Use signals with frequencies that differ from any background noise to minimise masking the warning sound. Attending to audible information may reduce the processing of other audio sounds;
  • Use a modulated signal (1-8 beeps/s or 1-3 times/s for warbling sounds) because it differs from normal sounds to demand attention;
  • Be clearly discriminable if different warning signals are used to differentiate between responses required.

If the terminal relies on visible correlations between changing prompts and unlabelled buttons, users may still not be able to know which button is associated with each prompt. In this case, it may be best to develop a separate audio menu that prompts the user to press a number on the keypad for each choice. This can be done along the lines of telephone interactive voice response (IVR) systems, which ask the user to "press 1 for this option, press 2 for that option" etc.

Applying the previous techniques should result in a terminal that suits all users. However, in some cases, what is best for one group of users is not necessarily best for all. If this is the case, it may help if the user interface can be adapted by the user, or automatically for the user, to fit their individual capabilities. For example, some users may wish to choose spoken output, graphical buttons or fewer choices, whilst others may prefer to have only written text and more detail. The choice could be made by the user selecting from a number of displayed options. Alternatively, information required for the terminal to switch automatically could be encoded on a user's smart card at their request.

Provide a constantly available Cancel button. However, it is essential to be consistent on what this means; on various systems it means:

  • Delete the last character input;
  • Go back one page; or
  • Go back to the start of the interaction.

Not surprisingly, consumers tend to find this inconsistency very confusing.

To accommodate the slowest users, a good rule of thumb is to allow up to 10 times the average response time for each individual activity – reading and understanding, choosing, recalling information and making inputs.

It is easy to include timeouts and reminders in software without much thought as to whether they are required for security and whether they are actually helpful to users.

Consistency is achieved by defining a standard style and following it. This can outline standards for aspects such as colours, control sizes, positioning, task order and writing style for instructions and information. It should be written down in the form of a style guide and one or more members of the development team should be assigned to act in an editorial role, reviewing the design to ensure it adheres to the style guide.

It may be possible to enforce the standard automatically, by using templates or some kind of content management system.

Avoid inserting extra steps into the sequence, such as advertising or promotion messages.

Achieve consistency with other public access terminals by using international or industry standards wherever possible. Standards exist for things such as symbols (e.g. EN 1332-1 AM-1 (2005), ISO 7000 & 7001), colours and keypad layouts.

Applying the previous techniques should result in a terminal that suits all users. However, in some cases, what is best for one group of users is not necessarily best for all. If this is the case, it may help if the user interface can be adapted by the user, or automatically for the user, to fit their individual capabilities. For example, users who need more time to read, think and act could choose longer timeouts and no reminders, whilst users who are quick may prefer to have shorter timeouts for security. The choice could be made by the user selecting from a number of displayed options. Alternatively, information required for the terminal to switch automatically could be encoded on a user's smart card at their request.

How you could check for this

Try to ensure that all instructions and information are covered in the user tests, which should include users who have low English literacy, preferably for a number of different reasons (education, nationality, hearing or cognitive impairment).

During user tests or after a first release, it is possible to gather data from a broad range of users about how long they take over each activity – reading and understanding, choosing, recalling information and making inputs. This can then be used to produce more accurate rules determining how long to allow. However, this should only be done by trained statisticians and the amount of data required for statistically significant calculations will be quite large.

During development, test the prototype in a realistic situation with real people who have various forms of visual impairment. In particular, include people who are recently impaired and have not yet developed enhanced perception or coping methods.

While carrying out a task, write down the sequence of operations performed, in terms of physical actions such as button presses. Try to repeat the task a number of times by following this sequence exactly, without looking at the displayed instructions. If the result is in any way different, there is inconsistency.

During testing, the following key checks should be made:

  • Good contrast labels are provided in a clear typeface;
  • The vocabulary used is simple.