Use scenario – user story – user task: finally getting the big picture

IEC 62366-1 uses the concept of (hazard-related) use scenario.

The FDA recognizes critical (user) tasks. In development, use cases and user stories are used.

This variety of terms makes it difficult to achieve a common understanding. However, this is necessary to create a consistent and legally compliant usability engineering file and avoid regulatory problems. This article provides clarity.

1. Why you should concern yourself with use scenarios and user tasks

a) Because it is required by law

Manufacturers must demonstrate the usability engineering of their medical devices and their safe application. This is required by the FDA as well as by laws in Europe and other markets.

Manufacturers should describe use scenarios and user tasks for both the US and EU markets. Neither use cases nor user stories are required.

Overview

Regulations / concept to be described	FDA	MDR/IVDR	IEC 62366-1
Use Scenario	Yes	No	Yes
Hazard-related use scenario	No	No	Yes
User Task	Yes	No	Yes
Critical Task	Yes	No	No
Use Case	No	No	No
User Story	No	No	No

FDA requirements

In its guidance document Content of Human Factors Information in Medical Device Marketing Submissions, the FDA requires manufacturers to identify critical tasks and eliminate or at least reduce usage-related hazards. The exact requirement can also be found in the FDA’s HFE Guidance.

In the same document, the FDA also requires manufacturers to describe use scenarios:

“The submitter should also describe each use scenario included in the human factors validation testing and list the critical and non-critical tasks that constitute each use scenario.”

FDA Draft Guidance: Content of Human Factors Information 
in Medical Device Marketing Submissions 

Requirements of MDR and IVDR

The EU regulations MDR and IVDR only require that “risks caused by application errors” be excluded or minimized. The terms “use scenario” and “critical task” are not used in the regulations.

Requirements of IEC 62366-1

As with all general safety and performance requirements, manufacturers should benefit from harmonised standards to demonstrate conformity with these requirements.

In the case of usability engineering, EN IEC 62366-1 is the standard to be harmonized. It requires manufacturers to

• identify and describe the hazard-related use scenarios. This requires manufacturers to have identified and described the use scenarios as a whole.
• describe the tasks and their sequence,
• select the hazard-related use scenarios that are to be part of the summative evaluation (usually usability tests),
• justify this selection,
• specify the UI based on the use scenarios, and
• plan and carry out the summative evaluation for each selected hazard-related use scenario.

b) Because it enables the development of better products

Products are considered usable if they comply with the tasks of their users as effectively and efficiently as possible and to their satisfaction. This is the definition of the term “usability engineering” (according to DIN EN ISO 9241-11:2018-11).

To achieve this, it is necessary to identify the tasks and consider the order in which users should interact with the product. These are the use scenarios (as expressed in the definition).

2. Definitions and distinctions

a) Use scenario and hazard-related use scenario

IEC 62366-1 defines the term “use scenario” as follows:

The subset of hazard-related use scenarios is particularly relevant:

The standard notes that hazard-related use scenarios are often associated with a use error. In practice, this is likely to be the case almost always.

b) (User) Tasks and Critical Task

Although IEC 62366-1 refers to tasks, it does not define the concept of “critical tasks” in the normative part. In the informative part, it states:

“A TASK in a HAZARD-RELATED USE SCENARIO where a USE ERROR can lead to significant HARM can be considered a ‘critical task’.”

In contrast, the FDA recognizes and defines the term “critical task”:

In the same document, it also defines the terms “task” and “serious harm”:

When defining the term “harm,” the FDA refers to the definition in IEC 62366-1.

The definition of “serious injury” can be found elsewhere:

c) Distinction between use scenario and user task

A use scenario comprises a sequence of user tasks on a system (product) (see Fig. 1).

d) Distinction between use scenario and use case

Definition „Use Case“

Unfortunately, there is no standard, binding definition of the term “use case.” The following definitions are examples:

• “A use case describes a sequence of actions a system performs that yields an observable result of value to a particular actor.” [Ivar Jacobson].
• “A use case is a sequence of actions or steps that typically define the interaction between a role (also called an actor in UML) and a system to achieve an objective.” [Source]
• “A use case specifies a sequence of actions that the system performs in interaction with the environment.” [Source]

Comparison of definitions with use scenarios

These definitions are not identical.

1. According to Ivar Jacobson, it is only about the system. It is NOT about the actions of a user.
2. The second definition refers to “actors.” Examples of these actors are not only users, but also other systems.
3. The third definition refers to a sequence of actions. However, these are actions that the system performs with the environment, not actions that a user performs with the system.

This makes it clear that use cases (as defined by Ivar Jacobson) and usage scenarios are not directly related to each other:

Use Scenarios	Use Cases
Use cases specify the sequence of user actions and system responses at the usage level in such a way that the user requirements are met.	Use cases translate usage scenarios into scenarios that specify the system’s performance. From a usability engineering perspective, this takes us to the solution level: What must the system do to ensure compliance with the user requirements?

This is precisely what makes use cases valuable: they allow you to translate usage scenarios into system performance with minimal effort, entirely naturally! Consequently, use cases are used after user requirements and usage scenarios have been specified.

e) Distinction between use scenario and core task

A use scenario does not correspond to a core task. A core task is a task that a person must perform to achieve an objective (typically in terms of intended purpose).

A core task does not have to relate specifically to the use of a product. A core task could be, for example, “measuring your pulse,” which could also be done without a product. A use scenario, on the other hand, includes the technical solution and describes the use of a heart rate monitor from the user’s perspective.

A core task usually consists of several subtasks. Systems support some of these subtasks, sometimes even all of them. The subtasks that users perform on the system form the use scenario.

f) Distinction between use scenario and workflow

The term workflow has multiple meanings, which leads to difficulties not only in usability engineering.

Workflow and Processes

There are workflows in the sense of processes. They define the cross-role and cross-organizational collaboration between people.

These workflows can be modeled and described using Business Process Modeling Notation (BPMN), for example.

Workflow in usability engineering: usage scenarios and tasks

On the other hand, the term “workflow” is used as a synonym for “use scenario.” In this case, a workflow describes how (individual) people interact with systems within the scope of a task.

g) Distinguishing between use scenario and user stories

Objectives and wording templates

Many manufacturers use user stories to formulate requirements – usually for software – in the language of the customer or user. They benefit from “natural” formulations that correspond to everyday language, but typically fall back on sentence templates such as “As a <role> I can <activity> so that <business value>.”

An example of a user story is:

„As an EPAT (Extracorporeal Pulse Activation Technology) technician I can adjust the energy delivered in increments so as to deliver higher or lower energy pulses to the patient’s treatment area.

Comparison with use scenarios

User stories do not specify the sequence of activities. They are therefore not a substitute for use scenarios.

User stories from a regulatory perspective

There are no regulatory requirements that oblige or even suggest that manufacturers use user stories.

The Johner Institute even explicitly advises against this, as user stories often result in manufacturers not achieving regulatory compliance precisely. More on this in chapter 4 b).

3. How to document use scenarios and user tasks

a) What the regulatory documents say

Neither the FDA nor IEC 62366-1 specifies concrete requirements for how manufacturers should document use scenarios and tasks. IEC 62366-2 only states that there are many possibilities:

USE SCENARIOS can be written in many different forms, ranging from story-like narratives to simple lists of user TASKS or steps in a TASK.

IEC 62366-2:2016, Chapter 11.1

A task list is often not sufficient to meet the requirements of IEC 62366-1 to describe use scenarios. For example, the results to be achieved or post-conditions are missing, which can be used for review to verify whether the user has completed the task.

b) What the Johner Institute recommends

For this reason, we recommend describing each use scenario as follows:

Part 1: Cross-functional aspects

First, the following aspects are described:

• Intended user groups
  This can be a reference to the roles specified in the intended use or “use specification.”
• Intended use environment
  Here, too, such a reference is recommended if the (extended) intended purpose describes this information in sufficient detail.
• Preconditions
  This section should describe preconditions that must be complied with by the system or the use environment, e.g.:
  • In the system, Authorizations have been assigned, and data have been recorded.
  • In the use environment, information or additional tools are available.
• Postconditions
  The type of postconditions is comparable to the kind of preconditions. An example of a postcondition is that certain information must be recorded in the system.

Part 2: Tabular description of tasks

This is the consequence of a table that specifies the tasks with their attributes line by line:

Task, e.g., user action	Reaction of the system (via UI)	Possible usage errors	Possible reasons	Hazard situation	Possible harm with severity level	Critical task (y/n)	Measure for risk control
Enter new medication for selected patients	Show new medication for patient	Medication administered to wrong patient	Benefit was interrupted or there are patients with similar names	Patient takes wrong medication	High	Yes	Plausibility review (medication and diagnoses); Display of patient photo

4. Practical tips: What you should keep in mind

a) Select the right granularity for use scenarios

Manufacturers should choose the right level of granularity when describing use scenarios:

• Excessive granularity means unnecessary effort and results in even the most minor changes changing the use scenario. This increases the effort required for “re-validation.”
• Too low a level of granularity may prevent individual critical tasks from being identified, which means that these tasks may not be selected and evaluated collectively. As a result, potential usage errors may be overlooked during identification, and an unsafe product may be released onto the market.

Therefore, the following heuristics can be helpful, especially for software UIs:

• A core task consists of seven +/- two subtasks, whereby core tasks should not be confused with use scenarios (see above).
• Individual mouse clicks do not constitute a task.
• For screen-based products, a screen often represents a subtask or a task within the use scenario.

b) Be cautious with user stories

The user stories combine the various concepts that medical device manufacturers need to describe:

Section of the wording template	Content	Appropriate documents
As a <role>…	Characterization of users	Intended purpose or/and use specification
…I can <activity>…	Description of what the benefit must be able to do on the system	User requirement. If it has already been described how the user can do this, it is the system specification.
… so that <business value>	Purpose of this action	Intended purpose

The regulations require traceability between the intended purpose, stakeholder requirements, and system requirements or system specifications. This will not be possible if everything is mixed in one sentence.

Working with user stories is no substitute for requirements engineering, especially not for the systematic derivation of usage requirements.

Therefore, avoid using user stories. They do more harm than benefit.

c) Use of professional requirements Engineering

Instead, proceed as follows:

• Formulate the intended purpose, including the medical purpose and the specified users.
• Use the context method to derive the requirements, user requirements, and core tasks.
• Use this to specify the usage scenarios and, based on these, the interactive product.
• Validate this specification.

5. Conclusion and summary

a) Variety of terms

There are a large number of terms that sound similar but must not be confused with each other:

1. Use scenario and “hazard-related use scenario”
2. User task and critical tasks
3. Core task or core task
4. Use case
5. User story

Manufacturers must not confuse these terms. Otherwise, they may face regulatory difficulties.

b) A look through regulatory glasses

From a regulatory perspective, only the first two points are relevant. Even though the FDA places slightly more emphasis on the concept of tasks or “critical tasks” and IEC 62366-1 places more emphasis on the idea of “use scenarios,” it is essential in any case to identify use scenarios and their tasks in as much detail as possible and to describe potential hazards and the severity of any harm that may occur in as much detail as possible.

c) Procedure

The description of use scenarios does not replace requirements engineering, nor does it mark the beginning of requirements engineering. Instead, use scenarios to represent an intermediate step. This is because use scenarios are already part of the solution domain.

d) Importance

Precisely identified use scenarios are crucial for

• task analysis and risk analysis,
• safe medical devices,
• the summative evaluation of medical devices,
• a compliant usability engineering file and problem-free approvals,
• usable medical devices that are sought after by customers.

Manufacturers are therefore well-positioned if they systematically identify and describe use scenarios and evaluate them in usability tests.