A Story

Creating a strategy and executing

One of the largest clinical trial organizations in the world was looking to productize their processes to shift from an internal service tool to an external SaaS product offering.

I was part of the consulting team brought in to help. They chose the Salesforce platform to leverage as the base of their product. We were brought into help them define their vision, set realistic goals, set up a center of excellence team to use Salesforce, and help set up the execution plan.

The Vision

Create a simple and unified clinical trial execution system for clinical research coordinators, principal investigators, and project monitors.

Goals

Goal

Desired Outcome

User: Reduce duplication of effort and increase trust in clinical trial support and management.

Business: Create a universal system of record for clinical trial data to live in.

Satisfaction: Clinical research coordinators decrease time spent documenting visits by 50% or more.

Cost saving: Reduce the need for risk monitoring resources by 25%.

Satisfaction and usage: Principal investigators can monitor trial efficacy remotely and reduce time spent reviewing manually by 50% or more.

Goal

Desired Outcome

User: Improve clinical trial productivity and efficacy.

Business: Reduce and eliminate clinical trial errors or rework.

Satisfaction and cost savings: Clinical research coordinator has a 50% or more reduction in trial flags.

Usage: 50% adoption of clinical research associate application

Satisfaction: Clinical monitoring data is referenced and adopted by 80% of customers.

Plan

Due to the size of the vision, we came to the understanding that we were going to need to build 3 products that would be a suite.

Product Suite

A graphic we used to help communicated the layers of this project.

Clinical Trial Management System
Create one system of record that can support clinical trial operators.

Clinical Research Associate App
Help clinical research associates to easily document their trial visits to seamlessly sync to the clinical trial management system.

Risk Based Management App
Allow risk based monitors to easily view documented trial data to identify key trial markers. Data pulled from the Clinical Trial Management System.

How we will get there

Create a repository of users willing to be interviewed and contacted throughout the lifecycle of the project
Document key workflows to build and how they interact with each product of the suite
Technical deep dive into capabilities of Salesforce and architect a possible solution
Document how Salesforce can be used from an experience perspective - what is considered out of the box versus what might be custom
Create data dictionary to correctly begin to map data from system to system
Understand the business’s product branding and vision
Recommend what resources are needed to staff successful build teams

Technical Deep Dives

One might think, what does design have to do with the technical architecture? Well, quite a bit. As the product designer, I worked alongside the technical architect to understand their proposed architecture and nomenclature. A designer must have a confident understanding of the architecture to propose experience solutions that are balanced for the both user and the business. For this project, we were leveraging a pre-built platform so we must have a clear understanding of what is possible and what might not be at the moment.

Design must also understand the nomenclature and the data. Data is information. How we label that data is the nomenclature. That information is what our users will be consuming or inputing. We must understand what it means but also that it makes sense and how it all connects together. A technical architect is a designer's best friend.

Research and Workflows

We took a large amount of time interviewing and researching all of the users one might encounter during a clinical trial. During this research we created general list of roles, understanding every organization might not have all of these but what key behaviors are these roles responsible for and how might we provide solutions for those behaviors - or even maybe eliminate some for better outcomes. We organized key workflows we wanted to focus on going into product builds.

This research and workflow documentation started in discovery but was recommended to continue well after discovery and become a part of the build process for each team.

Design Documentation

Since we were using Salesforce as the platform to build upon, it comes with some strict guard rails from an experience perspective.

As we began to uncover what the technical architecture was going to look like, we could begin to document what Salesforce could offer ‘out of the box’ versus what might be custom.

This is a large learning curve because Salesforce comes with it’s own design system and look and feel. Organization have very strict parameters where they can change high level logos and colors. If you stray way from what Salesforce has, you not only increase development time (creating the code and maintaining that code) but you might miss out on future functionality that is released from Salesforce.

I will be honest, this is the hardest part of the project. Getting an organization to understand what they have essentially bought in to. We spent a lot of time documenting what their brand could look like on Salesforce and helping them to understand what that experience will look like for their users.

Team Structures

The final step in the discovery was to staff teams to build solutions. Our recommendation came down to:

[insert graphic]

Foundations Team

Consisting of leads/principals across business, product, architecture, development, and design.

These individuals were responsible for ensuring continuity across disciplines. For example, a team proposes a new component or new piece of data to enter, it runs up through the Foundations team to talk through and either let it go through to production or recommend leveraging something else for the team to use.

CTMS (Central trial management system), RBM (Risk based monitoring), CRA (Clinical research associate app)

Consisted of Project manager, product owner, technical architect, business analyst, product designer (1), developers (2-3), QA (2)

These teams specialized in their product. They could drill into their specific user base and their needs. Teams would reach out to one another for needs when it came to data, component patterns, or any other shared concepts.