Published on September 10, 2020
After writing the first three blogs in our series on frequent releases for connected medical devices, we were curious about what our colleagues in the medical device industry had experienced – what difficulties have they encountered when trying to implement a frequent-release cycle? How have they worked to overcome these difficulties?
We reached out to two industry experts who weighed in with their experiences integrating human factors research into their product development roadmap. Both noted that they had positive experiences using a hybrid model that included a more aggressive schedule of releases, but that a truly cyclical approach prior to release was still difficult to achieve.
After reading this blog, please take our survey to let us know what you think! We will incorporate your feedback into an upcoming blog.
Research conducted early in the product development process was most effective
One of the experts with whom we consulted is a product manager at a major pharmaceutical company. She noted that the time it takes to conduct research, especially when not initially planned, has become a barrier to implementing some of the processes we have described in our prior blogs in this series. She believes that the “right way” to build a product is to have research drive on what changes need to be made, but notes that effectively implementing research requires balancing real constraints, including organizational timelines and milestones, budgets, and organizational objectives (any of which may at times make it difficult to implement research).
Because of the time it takes to do the research, it can be hard to integrate product development into an agile approach. This means that executing research at the beginning of a product’s life cycle is often still the most effective because such early research has the greatest chance of impacting the product’s design.
The second expert with whom we consulted is a human factors practitioner who has worked on product development for various pharmaceutical manufacturers. He has had a largely similar experience to our first expert. He similarly pointed out the need for early foundational research, with an emphasis on understanding user needs and defining product requirements. While the nuances of the designs will be refined over time, the most critical elements of the device should be and are defined early in most cases. This research is then used to understand and adjust the nuances.
While a regulatory framework can be seen as a barrier, it can also be an important driver for incorporating research
Both experts pointed to difficulties they have experienced or noticed within organizations that may serve as barriers to integrating research into the product development process, be it agile or a different approach. A primary barrier both noted was how different functional areas across an organization (and outside the organization in some cases) may have different objectives and needs for research. Various parts of an organization may have differing views of how research might impact the product and, even more fundamentally, of who “owns” the product. This can make it challenging to conduct research that speaks to everyone and meets the needs of a wide variety of functional areas (e.g., meeting both the needs of design and the needs of human factors). Some may also struggle to accept research results if they perceive them to cause the organization to move away from the original objectives or intent of the project.
On the other hand, both indicated that regulatory requirements help to drive research by emphasizing a need for tracing and substantiating design decisions. So, a regulatory framework, whether pre- or post-release, serves as an important driver for ensuring that research is integrated into the development process.
Tips to overcome challenges to frequent release implementation
Recognizing that many of our readers likely face similar experiences and challenges as our experts, we have compiled some small practical steps (many of which our experts have already adopted) that may help address some of the challenges described by our experts and may be able to help you integrate research into your development process.
- As our experts indicated, it is (almost) always valuable to plan some form of early testing. If you have budget or schedule constraints that limit what you’re able to do, there are ways to work within these constraints, such as testing with internal stakeholders. Early testing gives you a quick gut check on your design direction and key details, such as the clarity of any labeling.
- If you’re testing early (and creating a digital interface), remember that you can conduct fruitful research even if all you have is a simple click-through prototype. These prototypes can be constructed quickly in tools like proto.io and iterated on for future tests; this can help you identify whether you’re on the right path before building out a fully functional product.
- As our experts indicated, early tests can be honed so that they focus on addressing the key issues to be successful in the more formal formative and summative tests you may have planned later. These early tests set the stage for greater success in your formal testing and are well worth the time and money invested.
- Even if you are in the middle of your development effort, you can still benefit from informal tests that are not conducted on a regular cadence. These tests can be inexpensive to execute and can provide important feedback on the current state of your product design, while still allowing time for design changes. As an added benefit, once you have executed a first mid-stream informal test, you will be better equipped to repeat the process and ease into the practice of performing these tests on a more regular basis.
We hope despite the challenges, you will be able to iteratively evolve your testing strategies to include earlier and more informal testing that can help pave the way to mitigating risks and improving your product design.
How does your organization approach agile research and frequent (or infrequent) releases?
We’d love to hear about your experiences using an agile, iterative methodology in your product development process! What has worked, what hasn’t, and how have you worked to overcome obstacles? Fill out the survey below to share your experiences! We will incorporate your feedback into an upcoming blog.
Bob Moll is the principal UX Architect at Orthogonal. You can email him at firstname.lastname@example.org
Beth Lester is a UX Researcher at Bold Insight. You can email her at email@example.com
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.
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.