Placing the Target User First in Clinical Trial Technology
By Bill Cooney
October 25, 2010 | Expert Commentary | In the past decade, clinical trial technology has undergone a series of evolutions in its design, capability and deployment. From the early days of remote data capture to full-suite clinical trial management solutions, this evolution is redefining clinical research. Yet despite its dominance, clinical research technology has suffered from significant resistance at the study site level, which can be traced to a deficit in one basic element: user-centered design.
Early systems focused on making the best use of emerging digital technology to accomplish study tasks, usually mirroring the paper-based equivalent. For example, early EDC systems attempted to replicate the paper case report form in an on-screen version. But digital media is inherently different from paper media, so that mere replication of paper is seldom an effective approach. In making the conversion from paper to on-screen forms, developers used common tools such as drill-down menus, drop-down boxes and mandatory pathways. As they attempted to create the online equivalent of the paper process, developers invariably added user complexity. Most developers have failed to focus on making the online CRF easy to use for the study site, and unfortunately, few systems have moved beyond this approach in their attempt to automate study processes.
It’s not hard to understand why end-users receive little consideration in the design of clinical trial software. The widely-accepted practice of clinical software development follows the waterfall approach to development, used to ensure software can be validated. User requirements are created, systems are built and tested by those creating them, and a stamp of approval is given indicating that the system does what the user requirements say it should. Upon closer inspection, we see that user requirements are drafted by clinical trial business analysts, and functional requirements are created by the IT department. Neither group tends to focus on instructional design and the needs of end-users at study sites.
The result is a system that’s functionally clean and tidy, and that provides study managers with the data and reports they want. But end-users at study sites are confronted with a system that’s counter-intuitive, requires a slew of training, is difficult to access, and creates more, not less, work than the paper equivalent. It’s little wonder that such systems have encountered significant resistance, even rejection, when they’ve been deployed at study sites.
A Better Way
It’s quite possible to develop study systems that address the needs of all parties, including those persons inputting data at study sites. Consider, for instance, how Apple differs from Microsoft by emphasizing intuitive use and value for the customer, whereas Microsoft prioritizes IT system functionality. Apple’s strategy of placing end-users over IT has been very successful and set a new standard that others are scrambling to replicate.
The lesson we can all learn from Apple is along the lines of “give the people what they want.” When developing its technologies and products, Apple places complete primacy on delivering an intuitive user experience and clear value to the customer. Its computer systems place secondary priority on the specifications of IT technicians, and the control and reporting desired by management. The Apple approach is becoming predominant because their products are more valuable and productive for end users, which leads to systems that work in the real world, driving success for all other system stakeholders.
In our consumer marketing-driven economy, the primacy of the customer, or end-user, is a familiar concept. But it’s also a concept that is easily forgotten when developing study systems. The people controlling development of study systems are IT and study management professionals, who all too often focus on their own parochial needs and lose sight of the importance of the end user in system design.
To build intuitive systems in clinical research, developers can learn from the field of training, which has defined Instructional Design (ID) as the process of systematically analyzing, designing and delivering systems for target users. Most ID models use some form of the ADDIE process: Analyze, Design, Develop, Implement, and Evaluate. This model is not far from the traditional waterfall approach to software development, but starts with an emphasis on target user requirements, and ends with an Evaluate step that ensures utility for target users.
Using the ID model, a sample population of the intended audience is used to provide feedback on the system content and design. Initial reviews are focused on providing general feedback, and intermediate reviews are conducted by designers observing target users completing activities on the system. Observations are made to determine if intended pathways on the screen are followed by target users, if mouse clicks are made as anticipated, and if users understand how to compete assigned tasks. Feedback is collected and the system is revised based on this user input. The focus on the user in the ID model may seem somewhat obvious, but if the software development process is not grounded in user needs, user requirements can be quickly obscured by IT issues and the desires of study managers to get the data and reports they want.
The ID model and the primacy of the end-user will not fix every challenge in the design and deployment of clinical trial technology. There are also major challenges in converging and simplifying technologies, and in lowering costs so that drug development leads to affordable health care products. But the ID approach is among the most accessible and obvious options to improve clinical trial technology.
The clinical research industry has and continues to invest vast funds in developing clinical trial technologies. To improve clinical trial software, IT developers can readily borrow from the valuable work of the training industry, and deliver more practical and effective solutions. Involving end users in IT development is not optional; it is essential.
Bill Cooney founded MedPoint Communications in 1990 in Evanston, Illinois.
