After some fruitless searches on Google, it became obvious to me that there wasn’t a set of Usability requirements I could grab off a helpful website and drop into a contract for delivering government IT services.
There is a plethora of blogger information, with typical unimaginative titles like “the top ten principles of Usability”, or your academic types which are around “Usability heuristics” and HCI theories.
This search started out because feedback from the supplier I’m working with was that the Usability Maxim’s that I referenced on the Wikipedia page about usability are too esoteric to be used formally in a functional specification. By that last term, you can tell we’re working with the Waterfall methodology, which doesn’t have the best track record around user centred design.
But without changing the whole system development model to an Agile/UCD approach, how can you improve the user experience that is churned out at the far end?
Well, here’s my first attempt at creating a generic set of usability requirements that cover what I think are the main areas for any website or web app.
Feedback welcome.
Draft Usability requirements
| Usability Category |
Requirement |
| Ease and intuitiveness of use |
- User interface elements should have a consistent design style – this supports the user to recognise what is an action button, a hyperlink, a help prompt, a read-only section, an error message, etc
- User input forms should have a clear path to completion – smart defaults are set, mandatory fields are clearly marked, content groupings are used to logically organise and optional fields are avoided
- Users should not have to remember information from one section of a process/workflow to another – the relevant information should be presented when needed.
- Users should not be asked to perform calculations – the system must perform all calculations on behalf of the user.
- The user interface should compliment the other user interfaces within the customer’s online environment.
- The solution should follow the conventions of the web – follow accepted design patterns to support the solution to feel “familiar” to users – this supports the user in not having to learn a new interface.
- The aesthetic design should be of good quality – this is an indicator of an organisation’s credibility and trustworthiness. This also increases user buy-in to the solution.
|
| Navigation and Interaction |
- The solution informs users about their Progress in any long or multi-stage process
- this supports the user to complete their task/goal and creates a feeling of progress and achievement.
- this prevents the users from being forced to memorise a process.
Consideration should be made about whether to offer an ‘exit and save’ facility
- Users are kept informed about their current page/location in the solution – this supports user orientation and familiarity with the solution.
- Users should be provided with an “emergency exit” to return to previous location or the home page if they get lost in the solution.
- Expert users should be supported with shortcuts to complete tasks.
- Users should give users a clear next step – secondary actions on forms (i.e. reset form, cancel) should be avoided where possible, otherwise a clear visual distinction between primary & secondary actions is required.
|
| Meaningful outputs |
- Users must receive clear communication/feedback when data submission is Successful – this helps user confidence that their task is complete
- Users should receive feedback when interacting with the solution – for instance receives a message to highlight an issue that needs to be resolved
- Users should not be overloaded with irrelevant or rarely needed information which is superfluous to their goals – simple is better.
- Users should not be asked for information that does not relate directly to the task they are trying to complete unless there is a specific need to do so. If there is, explain to them why they should provide the information.
|
| Guidance and Error messages |
- Most of the time the web application will be used without any documentation but sometimes it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large.
- Preventing an error is better than a good error message and minimises the pain for users – consider using techniques such as
- inline validation (before form is submitted) to signify errors
- instructions about user entry displayed adjacent to the input field (or at least easily retrievable)
- suggested inputs to disambiguate (i.e. date of birth 01/01/1900)
- Error messages should be clearly communicated
- Messages should be positioned at the top of the screen, with high visual contrast
Use plain
- English to support users to resolve errors, and suggest actionable remedies to errors
|
| Consistency / Language |
- All terminology used in guidance text, labels and interface elements should be consistent.
- The solution should speak 'the user’s language', using words, phrases and concepts familiar to the user
- this means not using industry specific jargon and technical terms
- and avoid using the names of data items as they appear in the database schema as these usually don’t mean anything to users.
|
| Accessibility |
- Users should be able to control forms using keyboard inputs such as ‘tabbing’ between fields in a logical order, and hitting enter to submit the form.
- Accessibility guidelines make the solution accessible to a wide range of people with disabilities. This will also make the solution more usable to users in general.
- For detailed guidance on Accessibility, see the Web Content Accessibility Guidelines (WGAG), webstandards.org and for automated testing tools see WebAim.
|
Sources/Influences
