While working at Medable as a senior product designer on the Sponsor product team, we identified an opportunity to improve the external client's experience and reduce the burden of service tickets submitted to internal customer service. This resulted in a new product launch that improved efficiencies by 60%
Background
Medable produces web-based software for decentralized clinical trials (DCTs). Clinical trials "are research studies that test a medical, surgical, or behavioral intervention in people" (National Institute on Aging), such as how effective and safe a new medication might be. A "decentralized" clinical trial is one in which the study may be conducted remotely, using web-based software. In reality, truly remote studies are rare because they usually require physical locations—offices called "sites"—where clinical staff conduct work and meet with people in person.
Pharmaceutical companies—called "sponsors"—hire Medable to implement a study design using Medable's web-based software. A study design is essentially an elaborate survey used for data collection. The sponsor then hires a clinical research organization (CRO) to run the study using Medable's software. CROs recruit participants, such as patients, and provide the clinical staff, such as nurses, to perform the research study. However, Medable's business model focused on providing full-service development solutions. Every activity related to implementing, updating, or changing the clinical trial was handled in-house by Medable on behalf of the sponsor or the CRO.
Research
Working with the user-research team, we conducted many interviews with sponsors, CROs, and internal stakeholders to determine where we could improve efficiency. The full-service model was costly and resource intensive for Medable. The user-research team discovered that an overwhelming number of customer service tickets submitted by sponsors or CROs related to software user management. Counter-intuitively, CROs could add participants to a study but could not add clinical software users, such as nurses, study monitors, and site coordinators. A user-management request could take Medable days or weeks to fulfill, which sometimes conflicted with a CRO's on-demand needs to provide a nurse with immediate access to the study's software.
Problem
We wondered: how might we reduce the burden on customer service? We discovered that user management was very inefficient for the following reasons:
1. An admin could only add users one at a time, to a study.
2. Many users had to be added twice, first to a study and then again to a site.
3. An email address was the only required detail for a user account but sponsors often provided many more user details.
4. Sponsors often submitted batches of users, sometimes dozens or hundreds at once.
5. Sponsors used elaborate Excel spreadsheets to collect and share user details.
MVP: Paste a Batch
If an email was all that was needed to create an account and the work flow required creating many accounts at once, we concluded that a pasting a group of emails in a batch would speed up the process to add users. We also decided that we needed to eliminate the two-step process for site users. Furthermore, we hypothesized that a self-service workflow for sponsors, designed for the internal customer service team, would reduce cost and increase efficiency.
In sprint 1, our engineers were able to produce an MVP that added multiple users in a batch. User testing and feedback on this simple consolidation of actions and reduction in redundancy was overwhelmingly positive. This encouraged us to iterate on the MVP despite two key limitations. One limitation was our inability to include all user details requested by the sponsors (such as full names and phone numbers). The other limitation was the inability to assign a mix of user roles in one batch. This meant that all users processed in a batch had to share the same user role and site assignment.
Additionally, we faced competition from another development team. They had simultaneously released a script-based tool that could process batches of users, including all of the additional details required by sponsors, with a mix of roles and site assignments. The only advantage we offered was a no-code user interface.
Iterations: Sprints 2 & 3
The concept of consolidating actions and reducing redundancy was an incomplete MVP. The reality of a full-functional user-management product needed to include essential features such as seeing information in a user-friendly way. Sprints 2 & 3 were dedicated to exposing a complete list of users and sites associated with a study. Though this information was available elsewhere in the study-specific software, we wanted to consolidate all user management actions into a "hub" where sponsors could access information across studies. The hub concept was share by multiple teams working towards the same goal.
Sprint 4
As the product expanded in capability and complexity, fast design and development was easy given the availability of a design system and reusable components. This allowed us to enable actions, create data entry forms, and display tables of information quickly and easily. Sprint 4 was dedicated to enabling users to add sites to a study, with location and contact information. We also implemented detail pages for single users and sites.
Sprint 5
After implementing a form enabling users to add a single site with details to a study, we were able to replicate that quickly into a single-user form. After sprint 5, the user-management product was able to accommodate all the additional user details required by sponsors.
Sprint 6
After creating a product that allowed an admin to add users and see lists, we could finally enable user- and site-specific actions such as edit details. Sprint 6 focused on editability with additional functionality such as reset password.
Sprint 7
After sprint 6, we had a fully-functional and robust product. However, our design team concluded that an interaction we implemented did not meet accessibility standards. In sprint 7, we had to replace a multi-select dropdown menu with an expanded search and selection modal for sites. This became necessary because we discovered that very large clinical trials could have hundreds of associated sites. We needed a way to make finding sites by name or number easy.
Launch!
After 7 sprints, we had a user-friendly product with a no-code interface that could compete with another team's script-based tool. Though the competing tool was more efficient, it required more training to use. Our product still improved efficiency dramatically. Using a little widget called Mouse Miles, we were able to measure user interactions and calculate how much time we saved users and how much more efficient the process was. We cut time on task to 10% of what it was and improved efficiency up to 60% when processing a user management request.
By enabling batch processing and self-service user management, rather than relying on shared spreadsheets, we provided a much more valuable tool for the customer service team and our clients.