Article
Help Us Build an Authoritative List of SaMD Cleared by the FDA
Bob Moll, Principal UX Architect, Orthogonal
Beth Lester, UX Researcher, Bold Insight
In our last blog, we laid out ways in which frequent medical device product releases benefit user experiences, thereby benefiting organizations overall. However, making the transition to frequent product releases can seem daunting. Over the course of the next two blogs, we’ll outline and highlight some key steps in our blueprint for successful implementation and effective use of rapid, iterative testing for Connected Mobile Medical Devices (CMMD) and Software as a Medical Device (SaMD).
Since the 1970s, the V8 brand has used the slogan “I could’ve had a V8” to call out definitively unhealthy, avoidable decisions related to food.
Dealing with “V8 moments” or other surprises slows the release process, adds cost, and often results in the need to rewrite and reestablish consensus around user needs. Redefinining user needs late in the development process is risky, but can be easily avoided. As cliché as it may sound, effective teamwork is by and large the most sure-fire way to avoid “V8 moments” throughout the release process. By collaborating across teams, organizations can avoid knowledge gaps and minimize risks across the board. Our teams at Orthogonal and Bold Insight rely on and encourage this kind of teamwork internally and with our clients.
Here are five of our most recommended strategies to avoid surprises, minimize risk, and achieve successful frequent releases:
We recognize that the UX process needs to be a full-team effort. Often, teams involved in the UX evaluation process are thought to include only designers and researchers, but we stress to our clients the importance of including personnel from other backgrounds and departments. Members of the development, deployment and risk management teams should be involved in UX activities, such as vetting user flows and identifying edge cases that may arise from characteristics of the technology. Seeing firsthand how users interact with the software can be eye-opening and can bolster stakeholder buy-in to the UX process. This buy-in helps to ensure surprises don’t occur when the design reaches the coding stage, or worse, nears release. To go deeper on this topic, we recommend either (or both) of these two books:
Figure 1. Two books that exemplify the use of teamwork and fast feedback to solve problems and refine products.
We recommend that the entire UX evaluation team, including those mentioned above, collaborates to define the product requirements and to ensure that even design decisions made early in the development process are data-driven. If a major pivot needs to occur later to meet regulations or satisfy newly uncovered user needs, stakeholders will be able to point back to those data-driven decisions to understand how the original solution to the problem was reached. Frequent cycles of user research are critical to ensuring product requirements and user needs stay front-and-center for the whole team. User stories (i.e. the user needs of each persona group) identified during research help us humanize the problems we are trying to solve and can help exemplify why design or development decisions are or are not wise choices. Artifacts such as wireframes, wire-flows, and task flows are often embedded into the user stories for reference to assist team members in “baking” stories into the product’s design and development.
Ensure that the UX evaluation team provides inputs to and receives outputs from the organization’s risk management process. Risk management plays an important role in understanding the probability and frequency of potential risks, which guides how the UX effort should be prioritized to inform the design. High-frequency tasks, high-risk tasks, and tasks defined as “critical” should be at the front of the testing priorities in order to address any problems early in the development process. According to FDA guidance, a critical task is any user task which, if performed incorrectly or not performed at all, would or could cause serious harm to the patient or user, where harm is defined to include compromised medical care. Even during early, formative research studies, we can quantify successes and use errors in these tasks, then use root cause analysis to understand how the design and development teams can improve the product.
The UX evaluation team as a whole makes use of software safety classifications, use-related risk analysis, and software segregation to determine the level of human factors analysis needed across the product. Accurate assessments of these areas will inform mitigations that must be made before a full release. Frequent releases and testing allow mitigation of risk associated with critical task use errors to be implemented and tested throughout development. Involvement of the entire UX team in deciding the scope of human factors analysis needed will ensure that changes are only made where needed – saving time and cost on unnecessary adjustments – and that all necessary changes are completed efficiently.
In addition to development sprints, we hold design sprints with UX and/or human factors researchers and the project’s designers to acquire and implement feedback throughout the design and development processes. Neither development nor design happen in a silo; once a design sprint finishes, the learnings are passed on to the development team, who then passes the new or updated product back to the design team for the next round of sprints. This process ensures that the research and design team can stay ahead of development (but not too far ahead) to always have designs ready for prioritization and coding. In so-doing, both teams have constant visibility into the product’s status, user experiences, and potential risks – again, avoiding surprises. Design sprints also allow us to measure design velocity, so we can make sure the design and UX/human factors team is sufficiently staffed to keep ahead of development.
These five strategies encourage and require product teams to collaborate and communicate across the product release process. Involving non-traditional stakeholders in the UX process and working strategically to use research as a means of informing design and development helps ensure a smooth frequent release process.
In our next blog, we’ll delve into two of our teams’ most recommended “best practice” UX techniques for CMMD and SaMD. In discussing their values, we’ll offer suggestions on how to begin implementing these techniques in your team’s operation.
About The Authors
Bob Moll is the Principal UX Architect at Orthogonal. You can email him at [email protected]
Beth Lester is a UX Researcher at Bold Insight. You can email her at [email protected]
About This Blog Series
Given the multidisciplinary nature of MedTech and connected health, we have the opportunity to work with a wide variety of professionals, including engineers of many stripes, scientists, researchers, designers, experts in regulatory, and quality management. Our collaborations with the talented UX and human factors researchers at Bold Insight have been especially synergistic because Bold Insight’s specialization in user research for regulated medical devices is an excellent complement to Orthogonal’s specialization in the design and development of connected mobile medical devices (CMMD) and Software as a Medical Device (SaMD). But more than working on a common niche, Bold Insight and Orthogonal are fellow travelers on the road to slay the same dragon: we both believe that there is a huge opportunity to move the needle on healthcare costs and outcomes through the effective use of digital health solutions.
In recent years, both of our organizations (and clients!) have recognized how research and development teams can work together in a much more seamless and effective manner when they are aligned with a common focus on user-centered design. This is even more true when the R and the D in R&D jointly leverage methods based on fast feedback loops that generate rapid, iterative learning and progress such as Lean UX and Agile software development.
Given our mutual passion for getting safe, engaging, clinically effective, and comparatively effective medical devices to market faster, we thought we’d use this new series of blogs to share from our experience what that process has looked like in this new series of blogs.
Let us know what you think!
About Orthogonal
Orthogonal is a software developer for connected mobile medical devices (CMMD) and software as a medical device (SaMD). We work with change agents who are responsible for digital transformation at medical device and diagnostics manufacturers. These leaders and pioneers need to accelerate their pipeline of product innovation to modernize patient care and gain competitive advantage.
Orthogonal applies deep experience in CMMD/SaMD and the power of fast feedback loops to rapidly develop, successfully launch, and continuously improve connected, compliant products—and we collaborate with our clients to build their own rapid CMMD/SAMD development engines. Over the last eight years, we’ve helped a wide variety of firms develop and bring their regulated/connected devices to market.
About Bold Insight
Bold Insight is a user experience and human factors research agency. Designing, managing, and executing projects that span the product development life cycle, we conduct user research informing early product design to global human factors validation. Working with digital, next-generation technology—medical devices to mobile apps, in-car systems to websites, back office systems to end-to-end customer journeys – we specialize in large-scale and global research. https://boldinsight.com
Related Posts
Article
Help Us Build an Authoritative List of SaMD Cleared by the FDA
Article
Essential SaMD Regulatory Documents: Curated List
Article
SaMD Cleared by the FDA: The Ultimate Running List
White Paper
Software as a Medical Device (SaMD): What It Is & Why It Matters