News:

Usability Engineering

The phrases ‘User Friendly’ and ‘Ease of Use’ have become enshrined in everyday parlance, and are littered throughout marketing brochures for IT products. The phrases alone, however, fail to convey anything of substance or of value in helping users and choosers determine whether products will meet their needs. Ease of use is a very subjective concept until related in a definitive way to specified users and specified uses of a product.

In this article we aim to illustrate the importance of defining Ease of Use in a way that makes it useful when designing and choosing systems. We aim to take the phrase ‘ease of use’ out of the rhetoric of the marketer and place it in the engineering domain where it can be used as part of the quality control measures which are brought to bear in any product design/procurement lifecycle.

Usability can then be removed from the realms of marketing ploy, and elevated to the status of design aid.

A user-centred approach to designing for ease of use

"When software is advertised as ‘easy to use’ what does that mean?"

In considering this question and suggesting some answers, we draw on our experiences of providing consultancy to purchasers and developers who are seeking that elusive ‘ease of use’. In addition, we will provide a framework for achieving and measuring ‘ease of use’.

Before concluding that any interactive system is easy to use we must first understand both the meaning of ‘easy’ and the meaning of ‘use’. The list below contains various dictionary definitions of ‘easy’ and suggestions for the implications this has when applied to software:

• Effortless - requires little training or mental investment;
• Obvious - the software is clear, instinctual and non-misleading;
• Simple - anyone can use the software;
• Uncomplicated - there are no hidden meanings.

When we move on to ‘use’, there are again a number of possible meanings:

• to demonstrate;
• to understand;
• to generate output;
• to explain to a manager;
• to learn;
• to teach.

Various consumer standards propose that a quality product must be fit for the purpose to which it is to be put. We should extend this notion of quality to the development of usable systems. In order to define ease of use we must first understand the purpose to which the system is to be put (and by whom).

In most disciplines, that would describe themselves as a form of engineering, there is always a measurable definition or set of definitions by which the quality or at least suitability of deliverables can be judged. For instance, in mechanical engineering structures have to be able to withstand predefined stresses. In chemical engineering the quality of chemicals are judged in terms of their entropy or catalytic qualities at certain temperatures and pressures. Software engineering is similar, in that measurable requirements are established possibly in terms of system response delays, reliability, maintainability and errors per lines of code. However with respect to the "ease of use" of software systems there appears to be a lack of measures by which quality can be assessed. This does not have to be the case and should not continue to be the situation.

When purchasing or designing software it is important to define suitable quality measures. We call the definitions that we use to guide the choice and design of a system ‘usability criteria’. These define the users of the system, the situations under which they will use the system, the goals that they will be trying to accomplish, and the levels of performance that they must be able to achieve for the system to be acceptable.

The International Standards Organisation provides the following framework definition:

A system can be said to be usable when specified users, in specified circumstances, with specified goals, can use it with effectiveness, efficiency and satisfaction.

When we populate such a framework with details relating to a particular domain, or set of requirements, we might produce such criteria as outlined below. In this case we have assumed that we are discussing a system used for modelling queues. For instance, the modelling of the customer area of a retail bank.

"The prospective users of the system are simulation engineers who have previously used simulation software as a necessary aspect of their job. After a two hour training course, these users will be able to use the queue modelling system to see the effects of changing the number of customer service points and the shape of the customer waiting area on the throughput of customers. The engineers will be able to model the queues and interpret the simulation.

Specifically, the engineers will be able to build the model of the customer area and customer service points in a maximum of 40 minutes. Modifications to the parameters of the design including changes to the shape of the customer waiting area and adding or deleting customer service points will take a maximum of 10 minutes to generate and simulate.

The engineers will be able to prioritise potential designs in terms of the maximum number of customers who can be accommodated in the area and the maximum throughput that can be achieved. Reports including supporting graphics, summarising up to four alternate designs and their particular pros and cons will be producable within a further 30 minutes.

The reports produced by engineers will have no serious flaws on 99% of occasions.

Following eight or more hours of use the engineers will choose to use the software in preference to their previous means for generating simulations."

The above clearly states:

• who the user is;
• what the user is expected to accomplish;
• how long the tasks should take;
• how much time the user can be expected to invest in familiarisation with the product;
• how the users’ satisfaction with the system will be judged; and

• what is an acceptable error rate.

Such criteria enable assessments to be made of whether a system passes or fails against the required levels of usability, thereby enabling quantification of "ease of use". Once measurements are available it becomes possible to engineer usability. That is, make the process of designing user interfaces and assessing their usability an engineering discipline. Targets can be set and tests performed, and on the basis of the findings, modifications can be made to the design until the assessors are satisfied that the system will achieve what is required in an operational setting.

Criteria should be only as specific and rigorous as the situation requires. An organisation should detail the relevant characteristics of their users and the critical and frequent tasks that these users will be expected to undertake. Criteria would then be defined for these users and particular tasks.

It is seldom the case that one criterion alone will suffice to support the process of making a selection decision. There will be different user groups and different tasks to be considered. For example, a business may have the objectives of reducing the amount of training it has to provide to new graduate engineers, increasing the speed with which experienced users can produce complex models, and also wish to use their simulations in validation activities with their clients.

In most cases, a battery of criteria would be required which covered the training time required for new users to reach a level of proficiency, the levels of productivity and accuracy to be demonstrated by experienced users and the level of satisfaction and understanding expressed by their clients when the software is used in validation sessions.

In our experience, there are five areas around which specific criteria cluster. These are:

Productivity - a measure of how much work (in terms of actual tasks) can be accomplished in a given time

Learnability - a measure of how much training is required before a specified level of proficiency is reached

User Satisfaction - a measure of the subjective responses a user has to the system

Memorability - a measure of how robust the learning and performance are. (This can be particularly important for intermittent users)

Error Rates - a measure of the accuracy of the work carried out to complete tasks

We call these the PLUME metrics. The metrics can be used to check that the full set of requirements, and the impact they will have on the working environment have been considered and understood. They can also be used to help cost-justify investments.

Criteria are not only used for evaluation during purchasing decisions, but should also be used during the design of software to drive the design to meet pre-defined and agreed objectives and levels of performance. This applies to bespoke developments for individual organisations, and also for the development of commercial products for sale to a large market.

The value of a product is ultimately measured by how well it supports its users to do the things that they need to do, and evaluation of this should not be left until the end of the development cycle. Prototyping used in conjunction with usability engineering, can be powerful when used early in the development cycle. Design activities can be focused to meet requirements and unsuitable designs can be identified and discarded or reworked until the criteria are achieved or surpassed. In short, usability can be engineered to a precise specification.

To effectively engineer a system and ensure that expensive development resources are not squandered in producing deliverables of poor usability, design must be informed and guided by a knowledge of the prospective user’s tasks, usability criteria and user attributes.

In this way ‘ease of use’ or more objectively ‘usability’ becomes not merely a marketing ploy but a powerful design aid. Systems development is beginning to take this message on board and more developments are taking advantage of techniques and activities which build on an understanding of the user and their tasks. When applied appropriately this approach is called user centred design. It makes use of techniques such as task analysis, user analysis and prototyping to focus and assess designs early in the development process.

Usability is defined in terms of users and what they need to be able to do. This covers new users who require a high degree of guidance and structure which may hide some of the power of a system from them, and experienced users who require access to all of the functionality. The ultimate objective, however, is the same: a system must enable users to perform the tasks they need to undertake with effectiveness, efficiency and satisfaction. The degrees to which effectiveness, efficiency and satisfaction are to be achieved are open to the purchaser to request and the customer and supplier to agree. As with other aspects of software procurement, usability can and should be seen as quantifiable, and therefore a contractually definable quality of a software purchase agreement.

Want to know more? Contact us