2.1 Allow sufficient response time to accommodate the slowest users
Users should be able to ensure that operations such as logging on or reacting to an alert are not timed out or interrupted by system prompts until even the slowest users have had sufficient time to complete the operation.
Completing an operation in the application will require the user to carry out a number of separate activities. These may include reading and understanding instructions, 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 understand them fully.
Having read the instructions, choosing the appropriate action will take longer for users who have an intellectual impairment.Recalling information such as PIN numbers 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.Some response delays may also be caused by the use of assistive technology used to read the screen. 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
Allow up to 10 times the average response time in order to accommodate the slowest users
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.
Use timeouts only where necessary and reminders only where helpful
It is easy to include timeouts and reminders in software without much thought having been put into whether they are required for security and whether they are actually helpful to users.
Allow user-selectable settings
Applying the previous techniques should result in an application which 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.
How you could check for this:
Guidance on how to test whether this guideline has been met, at different stages during the development and release cycle.
Gather time-to-task data
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.
About user testing