Successful medical device OEMs recognize the importance of an early and extensive partnership with potential end-users.
As the potential of the technology that goes into medical pro ducts grows, so does the need for product design features that make them accessible to users.
The consumer devices mentioned h e re have been designed for a broad user base—from ages 8 to 80 is a common goal. But medical products are usually designed with a specific group or groups of users in mind. How can product development teams design UIs that really resonate with their particular customers? A truly great UI allows a user to more effectively exploit all the sophisticated features the design team slaved over to give the product a competitive advantage. An intuitive UI matches a user’s mental model of what they need to do to operate the device with how the device actually works.
Manufacturers can use design res e a rch to create better UIs. This article addresses how to conduct the early research and create concept UIs. The second part will explain the process of taking these concepts back out to users. It will also address how development teams can lay the foundation to meet FDA requirements for usability and good human factors design and the validation process.
What is Design Research?
Design re s e a rch is a kind of market re s e a rch that leads to the specification of the product design, and it is performed by a design team. Rather than passive data collection, design research entails an iterative process of criticism and refinement. An initial discovery period searches for design issues out in the field. Next, potential solutions are brainstormed, and finally the design team re t u rns to the field.
It is important that the design team partners with users. More- traditional forms of market research, such as large-scale quantitative methods, may help a manufacturer choose areas that a re ripe for new product development. But design research will help OEMs create a market-winning UI.
Not Your Usual FocusGroup Research
The early discovery phase must bedone carefully, with a focus on gathering qualitative data. It’s important not to become a slave to the numbers, nor to fall into the trap that is set by many a focus group session. Potential customers are notoriously good at commenting on what has been and are poor at seeing what could be. A major challenge facing any device firm aiming for a better product is how to listen for what customers really want in a nextgeneration product.
Rhall Pope, vice president of R&D at Smiths Medical (St. Paul, MN) faced this dilemma when Smiths decided to enter the insulin pump market as a newcomer in 2002. “Because users of existing products are familiar with the way those products work, it is very hard for them to tell you what they want, unless you change the whole framework of how you ask the questions,” he explains. “In most cases, they have a hard time thinking the product can even be different. So what early design research does is help the team to think outside an existing product model or market perception of what a product should do.” Rather, he says, it uncovers the value of the product to the end-user.
When Pope’s team was developing Smiths’ new insulin pump, design research uncovered several alternative user interface approaches. Each of these approaches could have essentially become the personality of the product and shaped the way it served the user. The design research performed by Smiths helped to categorize which features and functions users considered valuable. “We brainstormed the product concepts and took them back out to potential customers. We showed them things that they would not even have thought about had they not been able to see them. Therein lay the value of this approach.”
Getting Into Users’Future Mind-Set
This first part of the design research process is often just about listening, observing, and trying to become one with the way customers think. This phase can be as sophisticated as ethnographic research. But it can also be as simple as sending the design team out to visit working environments, walk trade shows, and attend conferences of potential users. Observation, structured interviews, group discussions, and casual chats may all play a part in helping the design team think like a user.
Consider a surgical product that has a UI on the control console. The product’s development team is probably already in contact with the clinical trial participants. But they may also want to tour several regions of the country to observe similar procedures done by surgeons at different skill and experience levels. Doing so will be very revealing about broader market acceptance. It is often helpful to have prepared some simple story boards to explain what the company is trying to do with a new product and its UI. But at this early stage, it is best to keep the ideas conceptual to keep feedback broad. Listen to opinions and influence them as little as possible. Try to chat with users in their workplace, which offers important contextual information.
It is wise to spread the net wide to gather feedback on future trends. It is also important to understand how a p roduct fits into the overall therapy or diagnostic framework of hospital, office, or home environments. For instance, consider a product that delivers a drug therapy in the hospital ward. Nurses may actually program it, but it fits into a system that involves pharmacists, doctors, biomedical engineers who service it, and the broader policies of the hospital administration and IT departments.
All these stakeholders may be willing to discuss new product ideas and Smiths’ insulin pump was created by talking with diabetics and their families and clinicians about what it is like to live with diabetes. This re s e a rch revealed that the best insulin pump UI was likely to have features and use terms specifically tailored to what was uppermost in the mind of a diabetic when considering blood sugar therapy. However, it must also have features that make managing the disease fit into a diabetic lifestyle. To that end, the pump has a menu that includes items like pizza as a part of the programming routine (along with other programmable features such as swimming, walking, sleeping in late, etc.). grecount their woes in using existing products. They will be even more inclined to talk if the team makes it clear that they are listening, not selling. Meet with each group separately to avoid internal politics from obscuring the tru t h. If the team suspects that required practices are not always followed, followup any obfuscation with gentle, nonjudgmental queries to find out what is really done.
Patients who might use a device everyday are also often willing to talk. If thorough ethnographic work is not possible, consider employing simple techniques such as sending out diaries and disposable cameras a month ahead of an interview. When collected, such information provides a window into how a device fits into patients’ lives.
Team members should not be lulled into thinking that because their company has been designing products in a particular medical area for 20 years that they understand their customers. Push customer contact all the way down into the design team. Send younger or new team members out with some of the old hands. Mix it up, and the results will be surprising and edifying.
Concept generation begins with digesting the results of earlier field observations and brainstorming ideas for the new UI. The team may meet to discuss user requirements and attempt to reach a consensus on ranking them, since trade-offs are often inevitable in design.1 It may be helpful to find UI examples on existing products that epitomize what the team either strongly wants or does not want in the final product. Ask team members to bring their favorite UI examples to a brainstorming session. These need not be medical, or even have a screen and buttons. If possible, borrow or buy examples, as it is best for the team to actually experience the UI. If this is not possible, use images from the Internet or sales literature to explain the ideas. From these samples, a good debate usually flows: one person’s simple is another’s confusing.
UI designer Brad Rhodes, principal of EudesCo (San Francisco), a visual communications firm, explains that users’ understanding of an interface is driven by five elements of involvement that all act in concert. According to Rhodes, the elements include the physical shape of the product and the feel of the controls (feedback, texture , etc.). Also included are the on-screen visual design and the interaction as they step through the process onscreen. Finally, any other nonscreen driven feedback, like force response, sounds, or other indicator lights or legends, are included.
Given the interrelation between features, it is best to brief the team well on the UI’s objectives. However, consider having a number of people work outside the actual brainstorming session to create loose concepts for the group to consider. UI concepts are generally hard to sum up in the simple one-page sketches or snappy one-line descriptions typically generated in brainstorm sessions. A UI has to work on many levels and must have a coherent architecture. A UI is not just a screen-and-button layout. Rather, there must be a cognitive underpinning to the user interaction.
Create Concepts for Review
The goal of this phase is to create increasingly mature UI simulations. It should culminate with two or three different UI examples that end-users can test by actually playing with the simulations with as little intervention from a facilitator as possible. A number of tools can help teams convey the essence of the UI and highlight the most important aspects of the interaction experience.
Microsoft’s PowerPoint or other slide show software provides a way to create story b o a rds with apparent interactivity for internal review before committing to fully interactive demos. Adobe Flash is a fast prototyping tool well suited to bringing concepts to life with button presses and changing graphics. Existing consumer handheld products (PDAs, iPods, etc.) can display screens via JPG or TIF graphics formats. This allows users to see the interface at its actual size. The images on the handheld should not be interactive; it does not usually produce a usable simulation. Instead, aim to show an interactive demonstration on a larg e - s c reen laptop with simulated buttons shown graphically around the display in the manner intended on the real product. Choose a screen size that allows users to focus on understanding the interaction between the elements without having to strain their vision or imagination. Even technophobic elderly patients usually manage to navigate their way around these kinds of demos using a mouse instead of pressing actual keys. It is also much easier to create the simulation this way.
It is important to understand the difference between the roles of two apparently similar graphical elements of UI design: interaction and visual design.
In the context of medical UIs, the interaction design governs how a user is able to move through the interface. If steps must be performed—for example, to deliver a therapy by setting up parameters or to carry out a diagnostic test at the correct time—then the way a product’s UI moves a user through these steps is the interaction design. An interface should leave users feeling in charge of the product and should enable them to move efficiently through the steps. Successful UIs usually can do so because their interaction design requires the least amount of thinking, learning, and remembering to use. This is referred to as cognitive processing.
Interaction design may include metaphors to assist understanding (e.g., syringe or battery icons) or use pictures, animations, sounds, or speech to guide users to the goal. Many of these interaction elements are graphical. It is possible to treat them with different visual design approaches yet still have the same underlying interaction design. Given that ultimately the interaction and visual design merge in the users’ minds to create the user experience, it is hard to separate them. In fact, the metaphors in some interaction designs re q u i re strong visual design to make them work effectively. For early concept testing, the interactive demonstrations should focus on several diff e rent approaches to interaction design, with minimal visual design to convey the intention. These relatively sparse UIs are sometimes referred to as wireframes.
To present the visual design, a few sample screens should be worked up from each of the interaction concepts as finished-looking screens. These screens can then be shown on the most appropriate platform at full size. If the product will be handheld, show the screens on a PDA screen. Allow users to move the PDA around to examine how the screens look, just as they would on the real product. If the screens are significantly larger, use a laptop or liquid-crystal display. If resources allow, explore several different approaches to the visual design of the various interface examples and see how users react. Only a few screens need to be visually designed to see how users react. If these were combined on the interactive demo, many screens would have to be visually refined.
Limitations and Opportunities of Software Development Tools
Research Subjects and Field Trip Preparations
While the team is preparing the props to take to users, someone needs to organize and recruit subjects for a field trip in which the concepts will be tested. If the U.S. market is the target, make sure that at least three geographically and culturally different regions are chosen. Obviously, if other regions of the world are important, include them. The good news is that relatively few users from each subgroup are needed to see how well the UI is working; a group of six people is usually sufficient. If any more people are involved, the returns diminish.
It is critical to think carefully about what constitutes a subgroup. If the product is surgical, the group should consist of more than just surgeons. The subgroups might be high throughout practitioners, lower volume thought leaders, and occasional users. With consumers, categories might be based on age or familiarity with similar technology or treatments, such as regular versus infrequent computer users, or potential versus experienced treatment users. These illustrations show examples of screen shots of wireframes and visual designs of the same hypothetical medical diagnostic product. Test, data history, and adjustment functions are shown. The input device is shown at the top right of the figure is a commonly used five-way direction pad (typically known as a d-pad). This is a tool the design team might use internally to explain the idea. It is not intended to be shown to users. It allows users to navigate through the functions. Generally, wireframes are made to be interactive and have intentionally simplified graphics. They are often shown to users at sizes larger than intended on the product. A large size enables users to focus on interaction rather than legibility. The visual designs show an example of how the UI can be given a specific visual design. This can be shown to users with static screens, preferably at the intended final size on the product. It is shown after the users have tried to navigate through the wireframe version. Only a few visual design sample screens are needed to get the point across about how the UI could look on the final product. Usually, two or three different visual designs are shown for each wireframe concept. This helps the design researchers understand which UI looks best and is understood best by users.
This article lays out the beginnings of the structured process for better understanding users and creating compelling UIs. The second part of the article will look at how to take these ideas back out to the field and turn the lessons from the feedback into the final UI specification. It is also about how to work the research and documentation into the FDA requirements for good human factors design.
The success of design research often comes from the significant involvement of many different team members in the field research that leads to some serendipitous realizations and breakthroughs. Getting out into the field as a small group can inspire vigorous debates based on new insights that day. This often leads to completely new ways of thinking about the problem.
For consumer UIs, improved usability has led to successful products. This result is likely to be re p roduced in the medical arena in the next decade. The specialized nature of the products designed for the medical market means that OEMs have an opportunity to design their UIs to very specifically match the expectations of their users, even the first time they use a product. This will lead to some exciting opportunities for companies that take the time to understand their users. For users, it will mean spending more time focusing on the patients’ needs instead of puzzling over prosaic programming.
1. Bill Evans and Jonathan Wyler, “Beyond Brainstorming” (Parts 1 and 2), Medical Device & Diagnostic Industry 26, nos. 9 and 10 (2004). ■