Protocol Creator is an online collaborative authoring tool to help pharmaceutical companies produce protocols and other clinical trial documents in less time and with lower rates of errors.
Before a drug or vaccine can go into a clinical trial, a protocol must be written detailing everything about that trial: the inclusion and exclusion criteria for the participants, how to administer the product, what
information the administrators need to log, and what to do when something goes wrong. This document, which can easily be over a hundred pages long, is often written and reviewed by dozens of people, typically all within
Microsoft Word with documents shared across email and Sharepoint-like services. There is very little real-time collaborative editing, and consolidation of everyone’s edits and comments often falls to one person throughout
the lifespan of a single document, which may take several months to years to produce. The creation of a protocol is an incredibly time-consuming and resource-intensive part of the clinical trial process and the authoring and
regulatory approval of this document is one of the reasons an important drug or vaccine can take so long to get to market.
Looking at the big picture
When I joined the project, developers were working within the standard two-week agile sprint schedule. Most features were driven by development capabilities and design was often working one sprint ahead of development. This
left little room for user research and testing or thinking through features and flows holistically. While ensuring development had the assets they needed, I began thinking beyond the current scope of each feature I was asked
to design. This allowed me to begin to get ahead of development without becoming a blocker towards current work. Eventually, I was able to present better, holistic solutions that would have a chance to be validated by users
and could be scoped for future releases.
The best example of this was our commenting feature. We received beta user feedback around the usability of the comments within our system. When I joined the team, I was asked to address this feedback in ways that had
already been scoped by development. The end result, while it addressed the feedback directly, lacked consideration of the other ways users could interact with a document, including viewing example text and instructions,
which all appeared as popups that would sometimes overlap the comments entirely. Once we shifted to thinking more holistically, we realized we could consolidate all of the document actions that weren’t directly related to
authoring in a side panel. Users would now have one place to go to view all comments, example text, and instructions. By working on this a full release ahead of development, we were able to conduct user testing sessions in
order to refine and iterate on this new direction. And it set us up for future improvements, such as implementing track changes and personal notes.
Aligning with reality
When Protocol Creator was first created, we had three main user roles: Document Manager, Author, and Reviewer. The Document Manager was in charge of creating the document and managing the Authors and Reviewers. Authors and
Reviewers were assigned to any number of sections within a document and their roles were strictly defined: Authors could only edit sections they were assigned to, Reviewers could only comment on sections they were assigned
to. We assumed this would give focus to the individual contributors on what they were expected to do while also making it easier for Document Managers to manage the workload.
Once we were able to conduct user research interviews, we discovered these strict role permissions were more of a barrier to the work people were used to doing. When we asked users about Authors and Reviewers, they would
often only talk about Reviewers. In reality, there was only one contributor role, often called Reviewer, and that role covered authoring and reviewing of any number of sections within a document. This meant reducing our
roles to Document Manager and Reviewer and relying on permissions to define the functions a contributor is able to perform. We also learned more about the process of review cycles and how the nature of an individual
contributor’s work changed throughout the life cycle of a document. We were able to define three distinct phases that review cycles fell into, as well as map individual permissions to those phases. This aligned us much more
with the reality of the document authoring process and gives structure where it is needed without being unnecessarily restricting.
Going beyond Microsoft Word
Protocol Creator has always had a very concentrated focus on bettering the document authoring process. Rather than boiling the ocean, we started small, ensuring users could successfully author documents together online in
the same way they could within Word. Over time, we began to think about what a real-time collaborative tool could do to both reduce the amount of time it takes to author a single document as well as decrease the chance of
inconsistencies within a single document and throughout all documents within a given clinical trial.
To accomplish this, we first introduced studies as a way to group documents within a clinical trial. At the study level, users can provide responses to variables such as the age range for a given participant group, or the
sex of the participants. These responses can then be used in a variety of ways. They can be used to generate text directly within a document. This text would be linked, so if the response to a variable was updated at any
point throughout the document authoring process, the text within the affected documents would be updated. Responses can also be used to conditionally show or hide content within a document. For instance, if you are running a
study that involves women of child-bearing potential, the system would display text that you would not otherwise include with a male-only study. Currently, authors have to read through instructions and flow charts to find
the appropriate text to copy and paste into a given document. This functionality not only means the appropriate text is placed into the document automatically, it also provides consistency across documents within a given
study.
Reflecting
This is an ongoing project. Our focus is constantly changing as we receive feedback from both clients and users and some of the features mentioned here are still being developed. On this team, I have had the advantage of
defining the process that works best for me and the trust to pursue a more holistic approach, even if it takes a few releases to fully develop these new directions. We will be further exploring ways to automate the authoring
process and reduce the amount of time it takes for clinical trial documents to be written and approved. The faster a protocol can be written, the sooner a potentially life-saving treatment can go to trial and make it out
into the world.