Volume 1, Number 2
The phrases "user friendly," "ease of use" and "usability" have become enshrined in everyday parlance, and are littered throughout marketing brochures for many IT products. The phrases alone, however, fail to convey anything of substance or value in helping users and buyers 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 beyond the design and choice of systems which support the organizations into which they will be placed. This is achieved by ensuring that systems actively enable users to perform the tasks they are required to carry out in pursuit of their day-to-day work objectives. In short, 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 be removed from the realms of marketing ploy and
elevated to the status of design aid.
Engineering Usability
Jerry Banks opens his excellent article ("Semantics of Simulation,"
CiME, Spring 1996) on the rhetoric of ease of use with the
following line: "When simulation software is advertised as 'easy to
use,' what does that mean?" We would like to extend the question to
read: "When asked to design a system that is easy to use, what does
that mean?" and pose the follow up question: "When would you or
anyone else know if you had succeeded?" In considering these
questions and suggesting some answers, we will 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."
There is an often held and erroneous belief that graphical user interfaces are inherently easy to use. As Banks points out, in 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:
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 can be described 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, for instance. 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 usability 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 measure. 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 they will be trying to accomplish, and the levels of performance they must be able to achieve for the system to be regarded as displaying an acceptable level of usability.
The International Standards Organization (ISO 9241, draft) provides the following framework definition for usability: "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 modeling queues. For instance, this modeling might be performed during the design of the customer area of a retail bank.
The above criteria clearly state: who the user is; what the user is expected to accomplish; how long the task(s) is (are) to take (i.e., a statement of the expected productivity); how much time the user can be expected to invest in familiarization with the product (i.e., a statement of the target learnability); how the users' satisfaction with the system will be judged; and what is an acceptable error rate.
This is a simplified set of criteria for illustration purposes only, but, as can be seen, they specify unambiguously who is doing what, and to what levels. Such criteria enable assessments to be made of whether a system passes or fails against the required levels of usability, thereby enabling us to quantify and assess "ease of use." Once usability in quantified in this way it becomes possible to engineer usability. That is, it makes the process of designing user interfaces and assessing their usability an engineering discipline. Targets can be set and tests performed, and modifications can be made to the design until the assessors are satisfied that the system will or does achieve what is required in an operational setting.
Criteria should be only as specific and rigorous as the situation requires. An organization 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 following objectives: 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 using their simulations in validation activities with their clients.
In this case, we can see that they would in all likelihood define a battery of criteria 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 usability criteria cluster [Browne, 1994]. These are:
We call these the PLUME metrics. The metrics can be used to check that the full set of usability 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.
Usability 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 for bespoke developments for individual organizations, and also for the development of commercial products for sale to a large marketplace.
The value of a product is ultimately measured by how well it supports its users to do the things that they need to do. 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 usability requirements and unsuitable designs can be identified and discarded or reworked until the criteria are achieved or surpassed.
To effectively engineer usability and ensure that 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 his tasks. When applied appropriately, this approach is called user-centered design. It makes use of techniques such as task analysis, user analysis and usability engineering to focus and assess designs early in the development process.
When the opportunities for developing usable systems are grasped, we can change slightly the emphasis that Jerry Banks put in one of his concluding paragraphs. He said: "In focusing on ease of use, purchasers do themselves a disservice. Purchasers should be more concerned with whether the purchase is usable for their situation. � Too often new users insist on software that is easy to use, possibly sacrificing the value that simulation can provide."
In this paragraph Banks hit the nail on the head: identifying the need for usable systems and also the fact that many claims for ease of use amount to little in terms of enabling users to carry out their tasks. In bringing together the points we have made in this paper, we offer the following conclusion:
Purchasers (and developers and users) should all be concerned to the highest degree with whether a system is usable for their situation. Usability is defined in terms of the users and what they need to be able to do. This at once 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, and ways in which to use it in complex tasks.
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 purchaser and supplier to agree on together. 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.
|
Reading There are many fine texts which deal with the issue of defining and then designing for usability. Some of those which have been most influential in shaping our work are listed below:
|
2555 Cumberland Parkway, Suite 299
Atlanta, GA 30339 USA
Phone: +44 23 8110 3411
e-mail:
URL: http://207.69.204.147