Presentation
The Devil’s in the Details: The Usability Process as it Applies to Software Service Activities
SessionHuman Systems Thinking (DH5)
DescriptionIn the context of medical devices, we typically focus usability activities on clinical users or the patients that interact with the devices, while service personnel are a historically overlooked group of device users. Therefore, we may not give this set of users the same level of attention as we do to the clinical or lay users. This is perhaps even more of an issue for software-only medical devices, where the perception may be that service users do not interact with the medical device at all. Service personnel for a software medical device may perform different tasks, such as installing, configuring, or upgrading software, applying critical patches, infrastructure setup and maintenance, patient data migration, cloud configuration and maintenance, etc.
Service for software-only medical devices is complicated by numerous factors. For example, there may be a wide variety of users, including service users “internal” to the device manufacturer, or employed by the customer that perform the same tasks. On the other hand, there could be a few specialized users that perform a certain task, such as several contractors hired to perform a remote critical patch update to customer sites. The software service engineers are typically remote and are not co-located at a single site. The workflows performed by the users are complex (e.g., software installation or upgrade activities), and involve lengthy documentation (install manuals) and training materials, and handoffs between multiple experts (e.g., CloudOps and database experts). Furthermore, other required activities during product development (mock implementation testing or service validation) may have overlap with service usability testing, leading to additional pull on the service engineers’ time, and confusion about the purpose and value of various test activities.
Based on our recent experience, we have learned a lot about the different types of service users for software-only medical devices, their tasks and workflows, and how to most effectively and efficiently plan usability activities for this user group. While the high-level usability framework is the same for service users as it is for clinical users, the details can be significantly different. The first step in a usability process is typically defining the users. For software service users, this is complicated by the wide variety of characteristics, skill levels, and specialized tasks that the users perform. Second, recruiting and scheduling participants requires abiding by constraints on their time since these users may be actively performing customer service activities and are not compensated for the additional time required to participate in a usability study. Third, planning the study requires clearly communicating the purpose of usability testing, identifying which workflow(s) will be evaluated, setting up test environments that can function well in a remote environment, and creating training materials. Finally, addressing usability findings may be difficult due to constraints of these service processes.
This submission will focus on the challenges we have encountered in planning and executing service usability studies. We will also address our experiences and lessons learned when it comes to understanding and applying the usability process to the software service user.
Service for software-only medical devices is complicated by numerous factors. For example, there may be a wide variety of users, including service users “internal” to the device manufacturer, or employed by the customer that perform the same tasks. On the other hand, there could be a few specialized users that perform a certain task, such as several contractors hired to perform a remote critical patch update to customer sites. The software service engineers are typically remote and are not co-located at a single site. The workflows performed by the users are complex (e.g., software installation or upgrade activities), and involve lengthy documentation (install manuals) and training materials, and handoffs between multiple experts (e.g., CloudOps and database experts). Furthermore, other required activities during product development (mock implementation testing or service validation) may have overlap with service usability testing, leading to additional pull on the service engineers’ time, and confusion about the purpose and value of various test activities.
Based on our recent experience, we have learned a lot about the different types of service users for software-only medical devices, their tasks and workflows, and how to most effectively and efficiently plan usability activities for this user group. While the high-level usability framework is the same for service users as it is for clinical users, the details can be significantly different. The first step in a usability process is typically defining the users. For software service users, this is complicated by the wide variety of characteristics, skill levels, and specialized tasks that the users perform. Second, recruiting and scheduling participants requires abiding by constraints on their time since these users may be actively performing customer service activities and are not compensated for the additional time required to participate in a usability study. Third, planning the study requires clearly communicating the purpose of usability testing, identifying which workflow(s) will be evaluated, setting up test environments that can function well in a remote environment, and creating training materials. Finally, addressing usability findings may be difficult due to constraints of these service processes.
This submission will focus on the challenges we have encountered in planning and executing service usability studies. We will also address our experiences and lessons learned when it comes to understanding and applying the usability process to the software service user.
Event Type
Oral Presentations
TimeTuesday, April 110:30am - 11:15am EDT
LocationPier 2/3
Digital Health (DH)