Since the introduction of touchscreen smartphones, the way people interact with machines has changed dramatically. The trend is toward ever-larger touchscreens and the elimination of hardware buttons. A similar trend is gradually emerging in medical technology as well. Operation should be efficient, effective, and satisfying for the user. In this article, I would like to show you how DIN EN ISO 9241-11 defines the term "usability" and why the discipline of usability engineering is so important for today's products.
Usability
DIN EN ISO 9241-11, entitled “Requirements for usability – Principles”, defines the term usability as follows:
Usability is the extent to which a product can be used by specific users in a specific usage context to achieve specific goals effectively, efficiently and satisfactorily.
To understand the exact content of this definition, some further explanations are required. If we develop a smartphone app, this represents our product for which usability is specified and evaluated. user are those people who want to install and use the product on their smartphone, namely effective, efficient and satisfactoryEffectiveness means how completely the result is achieved in relation to the desired goal. Efficiency, on the other hand, relates the result to the effort expended. Satisfaction is defined in the standard as: "Freedom from impairment and a positive attitude toward using the product." Usage context It consists of users, work tasks, work tools, and social and physical environments. All of these concepts can be represented in a coherent graphic:
What do you need the usage context for?
As described above, the usage context consists of users, work tasks, work equipment, and the social and physical environment. It is collected to facilitate the identification of usage requirements. Design solutions are subsequently developed based on this usage context. The usage context for an automated external defibrillator (AED) could look like this:
- Users of an automated external defibrillator:
Nobody would like to be in the situation of having to use a defibrillator. However, since ventricular fibrillation occurs suddenly, anyone can find themselves in that situation. Here, we can distinguish between two user groups:
– A layperson who may never have had contact with a defibrillator
– A medically trained person (doctor, nurse, etc.) - Work task:
Return the heartbeat of a patient/injured person to a regulated state. - Work equipment:
This does not include the defibrillator itself, but only the additional resources that are required and that influence the product design.
– Electrodes
– First aid kit
– Cell phone - Physical environment:
The location where the defibrillator is used. AEDs are usually located in public facilities.
How do you collect data for the usage context?
In the analysis phase of usability engineering, there are various methods for collecting data for the usage context. The most common are:
- interview
– oral survey of users
– Individual interview or group interview (focus group) possible
– Process must be well planned - questionnaire
– written survey of users
– no “intervention” in the process possible
– Users need a well-structured guide
– pay attention to the question - observation
– directly on site or via video recording
– takes place in the work environment
– silently accompanying and noting observations - Diary study
– Users document themselves
– Tasks can be specified
– online or paper - Contextual analysis
– Observing and interviewing people on site
– Preparation necessary
What all methods have in common is that data collection takes place on-site, either by you or the user themselves. Detailed information about the location, target audience, and tasks can only be obtained where the product is actually intended to be used! How you choose to collect the data is up to you. If you would like to learn more about the methods mentioned, please feel free to contact us.
How do you document the data obtained?
The analysis is complete, and the data now needs to be documented. There are various options here, too. I recommend creating personas. Personas are imaginary prototype users of the system. Here, you filter two primary users and, optionally, several secondary users from the collected data. Particular emphasis should be placed on the interests of the primary users if you don't want to miss the target audience. Write down the user's age, possible name, interests, and previous knowledge, and visualize them. Once you're satisfied with all the personas, you can hang them in the office during the development process. This way, you'll never forget who the device is intended for. Here's an example of what personas could look like:
Once all personas have been established, scenarios can be created. These form an extension of personas. Scenarios can be used to describe the processes a person performs during a workday. Scenarios can be developed to varying degrees. In some cases, short lists are perfectly sufficient, while in others, detailed elaborations can be useful.