Using Paper Prototypes as Interface Design Tools for Building Clinical Information Systems

Reference: Felciano, R. M.; Harris, M.; Rindfleisch, T.; Strain, J.; & Shortliffe, E. H. Using Paper Prototypes as Interface Design Tools for Building Clinical Information Systems. Knowledge Systems Laboratory, Medical Computer Science, February, 1995.

Abstract: The Stanford Section on Medical Informatics and Eli Lilly collaborated to design a portable prescription-writing and decision support tool for physicians. The purpose of the tool was to allow primary care physicians to prescribe medications, view pharmacological or insurance coverage information, and make explicit comparisons between different drugs (e.g., drug-drug interactions or cost-benefit ratios). The primary challenge in building such a tool was designing a system that would be accepted and used by physicians in a clinical setting. Interviews with clinicians and on-site observations in Stanford clinical settings during the first four weeks of the project gave valuable insights into the drug information needs of physicians, but it was important to start prototyping early to test the interface on real users. We decided to develop paper-based prototypes for usability testing in place of a software mockup because of resource constraints (lack of time and programmers), and to avoid adopting a particular computer platform so early in the design process. Paper-based prototypes typically use sketches of screen layouts to simulate a user-interface. Testing is done with two testers: one to instruct the user what task to accomplish with the interface, and the other to manipulate the interface elements to react to the user's actions. Whenever possible, the user interacts with these elements directly. For example, graphics of manipulatable interface objects were pasted onto Post-It(tm) notes, which the user could move around the page to simulate dragging with a mouse or stylus. We used desktop publishing tools to develop polished and professional screen designs and to ensure that test users perceived the paper-based prototypes as serious trials at system design. Because they were critiquing paper graphics rather than functional software systems representing many hours of work, users appeared more forthcoming in their comments. Rapid, iterative generation of prototypes. We built an initial prototype in a day. After showing it to expert users for feedback, we revised and updated the design in a second day and ran additional tests. This quick turn-around was the key benefit of paper-based prototyping, allowing us rapidly to try out new ideas for interaction and information presentation, and discard those user feedback indicated were problematic. "Designing to throw away". By trying ideas in a paper prototype, we minimize the time and effort spent on development and the intellectual cost of discarding ideas. We estimate that implementing and revising the same interface prototype with software tools (e.g., HyperCard or Visual Basic) would have taken three times as long. Ease of testing. Because the testing materials were pieces of paper, we could test them on-site in physicians' offices rather than in our lab, which minimized demands on test physician schedules. Even at this early stage it pays to test a clinical interface on-site to get feedback on how it will be used and integrated into work flow. Platform independent prototype. The paper prototype allowed us to defer hardware and software selections. It is most important to understand user information needs before deciding computing environment specifics (e.g., screen size). Focusing on the interactions physicians would perform, the end user determines what information is available to the decision support system, rather than the other way around. Potential drawbacks. Some users feel awkward using paper-based prototypes for the first time because it requires them to pretend they are using a real system. We tried to alleviate uneasiness by performing the tests in offices or work environments. Paper prototypes also tend to be more physically fragile, but we could easily print out new versions and discard the smudged or frayed ones. The initial five weeks of our project included only one week for prototype design and testing; the paper-based technique let us iterate through three designs during this week. Such rapid prototyping in the early stage of system design is a useful and efficient way to obtain user feedback on interfaces for clinical information systems.

Full paper available as ps.

Jump to... [KSL] [SMI] [Reports by Author] [Reports by KSL Number] [Reports by Year]
Send mail to: ksl-info@ksl.stanford.edu to send a message to the maintainer of the KSL Reports.