Developing the Wrong Devices with User-Centered Design

The aim of user-centered design is to involve users in the development process from the very beginning. As obvious as this approach sounds, it often leads to fatal mistakes in development that achieve the opposite of what you intended, meaning you end up developing unsafe devices with poor usability that do not comply with the regulatory requirements.

But with three steps it is possible to achieve to real goal of user-centered design – developing usable medical devices that:

  1. Users can use to safely and effectively diagnose, treat and monitor their patients
  2. Manufacturers can be successful in the market with and
  3. Authorities and notified bodies will authorize

 Definition

“Approach to systems design and development that aims to make interactive systems more usable by focusing on the use of the system and applying human factors/ergonomics and usability knowledge and techniques.”

Source: ISO 9241-210:2010

It would be better to use the term “human-centered design” rather than “user-centered design” because this would make it clearer that human-centered design also takes into account stakeholders that are not users. However, in practice, the two terms are often used synonymously.

1. User-centered design: why you have to be careful with it

a) Expert users are not usability experts

When you talk to users about device design, you are not discussing user requirements but rather a system specification (system requirements).

This is hardly surprising since users are experts in the use context. They have in-depth knowledge of the associated tasks, problems, goals, requirements, roles etc.

But users are not usability, requirements or device experts. They are not interaction designers. They do not have the expertise, in their role as users, to design usable user interfaces (UI).

 Note

Please note that ISO 13485, like the FDA, requires you to document both stakeholder requirements (e.g., user requirements) and system requirements.

b) Painful consequences of a suboptimal user-centered design

Not using the user-centered design approach correctly can result in three problems from the user's perspective:

  • The available functionality is difficult to access
  • Required functionality is not available
  • There is unrequired functionality instead

For you, this can mean:

  • The users (other users) do not, or do not efficiently, achieve their use goals. This makes the devices unsafe to use, puts patients at risk and leads to regulatory risks.
  • Users are dissatisfied with the use of the device for other reasons and prefer competing devices.
  • You have spent unnecessary money on a suboptimal user-centered design.

c) What manufacturers need to know

However, this doesn’t mean that you, as a medical device manufacturer, should not involve users at all. On the contrary: only users can provide you with the user requirements as part of a context analysis.

Users know about the problems. Developers know about the solutions. Usability and requirements engineers speak the language of both and have the ability to create specifications for devices that enable users to meet their use goals.

Fig. 1: The different roles have different knowledge and different skills. Therefore, they are responsible for different tasks in the user-centered design process. (click to enlarge)

2. Three steps to successful design and conformity with IEC 62366-1

User-centered design starts before the actual development of the device. Used correctly, it helps you develop devices that users are enthusiastic about. It also ensures the economic success of your device. If the user-centered design is applied correctly, it also helps you meet the requirements of IEC 62366-1.

Fig. 2: User-centered design is a process in which context analysis, the design and its evaluation are performed iteratively. (click to enlarge)

Step 1: Use context analysis

Before you start device development itself, you start with the context of use analysis. In this phase you learn a lot about the future users and their context:

  1. Precise knowledge of the actual users and their use environment
  2. Precise knowledge of the problems to be solved by the device
  3. Precise working out of user requirements
  4. You can then translate this knowledge into the relevant system requirements

The user's context of use always includes the tasks, the available work equipment, and the environment in which the user uses the device.

 NB!

User requirements are not the same as device system requirements – they describe the user's problems. Users cannot describe requirements, they describe their goals!

 

Step 2: Design and implementation

Once you have specified the system requirements, translate them into system requirements and develop the first prototypes. You then test these prototypes iteratively in formative usability evaluations, with users if necessary (see step 3). The results of the formative usability evaluation flow back into device development and you test the next prototypes.

You can start with low-fidelity prototypes using, for example, the following methods:

  • Paper prototyping
  • Clickable wireframes
  • Mockups from a 3D printer

Once the device development process is further advanced, you can use the following methods to develop what is known as high-fidelity prototypes.

  • Complex visual prototypes with complex interaction possibilities
  • Coded and functional prototypes

Step 3: Evaluation

Evaluate the developed prototypes iteratively until you have developed a final device. Depending on the stage of development, you can use methods such as:

Once you have a final device, carry out a last summative usability evaluation in the form of a usability test.

You can find an overview of other usability testing methods here.

3. Conclusion, summary

The belief that you only have to involve users closely enough during the development process to achieve usable devices is not correct. In the worst-case scenario, you just involve a lot of people who

  • Just give their opinion
  • Steal your time
  • Propose solutions that cannot be used
  • And, at worst, endanger patients.

There is also a risk of something like hive stupidity.

Users are experts in the context of use. But in their role as users they are not requirements engineers, interaction designers or usability experts. They do not have these skills and do not have a full command of the process for compliant “usability engineering,” as IEC 62366 calls it. As a manufacturer, however, these are the skills and expertise you have to specify and demonstrate. Every time you develop a device!

Therefore, you should involve users in the development of your devices but limit their role as we have described in the three steps above.


Do you have any questions about user-centered design? The Johner Institute's team will be happy to support you every step of the way. Contact us now

Autor Immanuel Bader

Author:

Immanuel Bader

Starter-Kit_rot_dunkel

A quick overview: Our

Starter-Kit

Learn More Pfeil_weiß
blog_rot_dunkel

Always up to date: Our

Institutejournal

Learn More Pfeil_grau