Software prototypes can transform thousands of words of specifications into pictures, and working code can offer another dimension to simulate the end user experience.

February 6, 2015

11 Min Read
Medical Device Prototyping—Don’t Neglect the Software!

Andrew Dallas

If your organization makes medical devices, you are necessarily familiar with designing prototype units for new products or revisions. These early models help you to work out critical details, from microelectronic functioning to material fabrication. However, while it’s unthinkable and infeasible to get to the production stage without mock-ups, many companies that provide medical device software do just that, resulting in unnecessary delays, increased costs, and user interface designs that are less than optimal when it comes to ease of use and mitigating risk.

Software Prototyping—A Sound Investment, Not a Luxury

Photo by renjith krishnan, courtesy of FreeDigitalPhotos.net

A picture is truly worth a thousand words. The physical device prototypes used by manufacturers offer more than the benefits of 2-D sketches with 3-D implementations such as custom-fabricated housings and operational breadboards. Before production, many people at an organization work with the sample units, identify and resolve issues, and improve products because of the prototyping process.

Similarly, software prototypes can transform many thousands of words of specifications into pictures, and by adding working code, they can offer another dimension to simulate the end user experience. Prototyping medical device software can lead to higher quality and greater ease of use than can be achieved by any other means.

For example, in the process of developing the software for a Class II medical device manufacturer, we used prototypes to improve the user interface (UI). To that end, we

  • Replaced a long and potentially confusing calibration process with a wizard.

  • Determined that some graphs displayed on a single screen and rendered too small to be useful were unnecessary, allowing us to remove them.

  • Improved many minor aspects of the user interface, including toggles, button placement, wording, and the type of graph.

  • Made the patient name more prominent than the patient number to help avoid misidentifications.

  • Altered the original color scheme, which was not visible in the dark room in which the device was to be installed.

By using a series of quick and inexpensive prototypes, increased development time and higher costs associated with making changes in the production software were avoided. The prototyping was performed in conjunction with usability testing, a human factors assessment, and risk analysis and management. Based on feedback from the prototyping, several software requirements were added, and the product ultimately sailed through the FDA approval process in record time.

A key advantage of using a software model is improved communication between team members and stakeholders, especially when they have widely disparate skillsets. When trial users, program managers, engineers, testers, marketing personnel, and executives all interact with a prototype, a common understanding arises. Greater understanding, in turn, leads to fewer misinterpretations and less rework, thus resulting in commensurate time and cost savings.

Why, then, doesn’t every medical software project incorporate prototypes? The most likely reasons are that companies don’t understand software prototyping methods and have misaligned expectations of benefits. Because a variety of tools and methodologies exist for a variety of different purposes, it’s not easy to choose the right ones. Moreover, if a company has had a bad prototyping experience in the past, resistance to repeating the failure is strong. Given the constant demand for quick progress at minimal cost, a manufacturer may also perceive prototyping as something that it can do without. Despite these responses, providers of medical device software would do better to view prototyping as an investment capable of yielding favorable results.

When Software Prototyping Provides the Most Value

Software can be prototyped at various stages in the development process. The work often begins when a manufacturer produces a proof of concept, such as that created using MATLAB. However, this proof of concept cannot simply be turned into production code because it often has features that will not appear in the production version, may be hard to understand by nonresearchers, or may have problems that were not considered by the original team. While researchers and scientists may be thrilled with their proof of concept in the lab setting, the intended end users may find it awkward and impractical. We often hear marketing personnel refer to their products as having a user interface that is “designed by two scientists, implemented by two scientists, and used by two scientists.” Mockups of new layouts should therefore be generated to convey the system’s benefits to all of its intended end users.

For good reason, a proof of concept—not a prototype—typically leaves out features that are not needed for demonstrating the software’s feasibility but are essential for productization. The tendency then is to just tack on those features. But typically, such additions will impact the workflow, thereby requiring the UI to undergo a redesign. Software prototyping helps to cohesively incorporate the added functionality.

In one case, a manufacturer delivered highly polished screens created by a third-party design firm in which every detail of the UI had been agonized over, tweaked, and ‘finalized.’ However, this work was performed before workflow prototyping had been done and without consideration for the end user’s environment. Subsequent workflow prototyping resulted in many beneficial UI changes, but these changes rendered much of the initial high-fidelity design a waste of time and money because it was conducted at the wrong point in the cycle.

The benefits of prototyping can also be realized in updates to existing products. A challenge associated with legacy products is that veteran users may not be able to envision a better way of performing the same tasks. For example, a laboratory system client wanted to add new features to an existing system, but the additions made the workflow confusing. We proposed an alternative UI and workflow to address the issues. But because the client was very familiar with the existing layout and structure, it did not see how the originally planned changes might be problematic and could not conceptualize how our alternative would be an improvement. A simple UI and workflow prototype was created to demonstrate our proposed layouts, making it easy to show the advantages in side-by-side comparisons. The result was a streamlined product that significantly reduced the number of steps required to perform a similar set of tasks and helped prevent human error.

Static and Functional Prototypes

Software prototypes range from more-static types that address the visual look, feel, or design of the software to interactive, functional types that allow for more-extensive workflow modeling. Prototypes can vary widely from low-tech, hand-drawn sketches of windows and sticky notes showing pop-up dialogs to crisp, final-quality screens that drive working code and mimic the real product.

A popular type of static prototype is the wireframe, which consists of screens containing the expected user interface elements. Wireframes can easily be built using any of several different prototyping tools by selecting from palettes of UI elements and dragging them into position. Showing the wireframes to a sampling of end users helps ensure that elements are situated in intuitive locations and are easy to understand. Paging through a series of wireframes can also be used to emulate simple workflows.

Clickable PDFs extend the wireframe concept by turning UI pictures into PDF files with clickable regions that allow navigating from picture to picture. This functionality provides the sense of automating simple UI workflows in order to better review and improve user interactions.

System flow diagrams and website maps provide a static but useful view of several screens, helping to ensure comprehensive coverage. While their ability to emulate user experience is limited, such diagrams and maps provide good documentation of the steps and interactions undertaken during the prototyping process, which is useful for implementation and for effective change management. They can also help to identify missing information in the workflow or steps that are out of order.

A good way to start workflow prototyping is to use storyboards. They help in creating high-level designs for use cases or in identifying the steps in a process. Storyboards can be refined as the project progresses or to validate workflow changes.

Functional prototypes are based on working software, but they often use canned data representing the most common scenarios or typical cases within the range of what’s supported. Such highly simplified but working software minimizes development costs while facilitating convincing demonstrations.

Some functional prototypes use simulators in place of the product’s hardware and firmware. Simulators allow the development and usability testing of software before the actual hardware or firmware is completed, shortening product design times and ultimately accelerating the project schedule. The simulators used in prototyping can often be used throughout the development lifecycle until hardware and firmware become available.

Working UI prototypes are most beneficial for developing products in which human factors and usability are especially important. Such prototypes are employed when the products are expected to have many end users with varying skillsets, when process complexities must be overcome, or to facilitate the avoidance of critical end-user errors to ensure patient safety in the case of regulated products.

Tools and Costs

While producing functional prototypes can require commercial software development tools and software engineering expertise, some prototyping tools are free and can be employed in minutes by nonprogrammers. A basic, open-source tool for static screen design prototyping is Pencil, which provides templates for common platforms, including iOS and Android.

Another tool for prototyping screen designs is Balsamiq’s Mockups, which includes a sketch mode that imparts a work-in-progress look, inviting users to provide feedback. This application also includes stylized widgets for a more formal presentation. Using Mockups, users can create clickable PDFs for simple workflow review.

Indigo Studio is a tool offering a storyboarding framework and platform-specific controls for popular desktop and mobile interfaces. It allows for extensive animations and can be hosted on a website, providing remote users with easy access.

Scripting tools for creating functional prototypes include Microsoft’s Sketch Flow, which can be used with Visual Studio and WPF Designer. While more expensive than other programs, Sketch Flow is also more extensive, allowing developers to stylize designs for production, emulate application behavior, and create custom controls. Sketch Flow can also be used to create a style dictionary to easily move from an initial hand-drawn look to the final aesthetic. Moreover, at least some of the output can often be used in the production software.

While packages such as MATLAB and LabView can be used for prototyping, they have their limitations. MATLAB is an excellent platform for algorithm prototyping, but its user interface development functionality is not on par with such specialty tools as WPF Designer, making it challenging to achieve a professional UI prototype. LabView is an excellent product when it is used in conjunction with National Instruments hardware because it accelerates the logical interfaces between hardware components. However, it is also difficult to create a useful visual prototype using these tools. While powerful in other respects, neither of them is suitable for prototyping UI aesthetics.

Software Prototyping Caveats and Payoffs

As with any investment, software prototyping entails ramp-up costs as well as ongoing time and expenses associated with implementation and changes. To make the best use of your investment:

  • Don’t prototype all aspects of your application. Limit the initial prototyping to the product’s main use cases. Create key screen layouts as clickable PDFs to emulate simple workflows, where needed. Advance to functioning code only when simple emulation is insufficient.

  • Be prepared to throw away your prototype coding. The prototyping software you create should not be designed to achieve the robustness and quality required of the production application. Focus instead on rapid, disposable prototypes. You will have worked out important concepts using a simple code base, saving you time and money by reducing rework in the production of the final product.

  • Assess the time and cost needed to create, use, and iterate your prototypes, determining how your estimate corresponds to your project budget and schedule. Then, identify prototypes that fall within your constraints.

Use prototypes to help address a range of common concerns, including:

  • Complex or extensive workflows. Functional prototypes consisting of rough screen mock-ups and working code allow you to streamline designs to minimize confusion and avoid redundancy. Such prototypes can help you identify the information that a user needs at given points in the process.

  • Critical safety steps or those prone to user error. Storyboarding, then modeling the layout with detailed prompts and error messages throughout the possible paths a user can take, will help to mitigate risks. Functioning code and stylized windows aren’t needed for this.

  • A consistent and impressive look and feel. High-fidelity samples of various user interface elements—from windows to wizards to dialog boxes—allow you to select the best color and style combinations for high impact as well as effectiveness.

  • The display of critical information that is extremely important for your product. If you are developing a patient monitor, the healthcare provider must always be able to see certain information during procedures. Presentation of that information in terms of screen position, color, and size are important considerations. High-quality prototype screen designs that are reviewed in the end user’s environment allow you to ensure their effectiveness.

Ultimately, software prototypes provide medical device developers with an opportunity to design systems that meet their intended use and generate a high degree of customer satisfaction.


Andrew Dallas is president and CTO of Southborough, MA–based Full Spectrum Software. An authority on best practices in FDA- and ISO 13485–controlled software projects, Dallas serves on the Editorial Advisory Board of Medical Device and Diagnostic Industry magazine and has published extensively in major trade and peer-reviewed technical publications. Reach him at [email protected].
 

Sign up for the QMED & MD+DI Daily newsletter.

You May Also Like