OneStudyTeam:
Central Recruitment

Understanding the Problem Space

👩‍💻 Went through recruiter new-hire onboarding
☎️ Shadowed one recruiter over a few days to sit in on her calls and observe her workflow
🔗 Visually documented current workflow as a flowchart

Patient recruiting workflows in clinical trials aren’t just a matter of picking up a phone and calling a prospective patient.

Key Problems to solve

Problem 1: Excel spreadsheet is not actionable or customizable

Recruiters work through a patient list that lives in Excel. This is a shared document across the entire recruitment team and not exactly easy to sort through to find patients assigned to you, as the recruiter.

The solution:
• Bringing in a network level patient list into our application (displayed as a table).
• Table includes functionality such as filtering by assignee, customizing table rows, interacting directly with table cells to update information.

Problem 2: Patient contact information lives outside Excel

In the current Excel spreadsheet, only the patient names are displayed. Recruiters take note of the name, go into our main StudyTeam application, and have to manually search for this patient to find their contact info to reach out.

The solution:
• Allow the patient name to be actionable
• When clicked, recruiters will see the patient’s profile to access their contact information and directly make their recruitment notes there.

Problem 3: For performance-related reasons, recruiters have to manually log their daily contact attempts and results with patients

Along with a count, recruiters also have to make notes of which trial this patient recruitment contact was related to, as they recruit across multiple trials.

The solution:
• Automate these counts. When a recruiter updates a patient profile and checks off that they’ve called, texted, and/or emailed this patient, these will be logged as counts in the backend.
• Display these counts in a Daily Report table for managers to be able to review.

Where does this feature stand today?

👉Engineers are building out the main patient table

👉Product and design have conducted usability tests with a lot of enthusiastic responses

👉Continuing talking to users to work through small details and account for edge cases

Lessons

• Full immersion with an SME is incredibly valuable and should be advocated for, if possible. Not every project gives designers the opportunity to fully immerse. Being trained as a patient recruiter and shadowing one for a week put me through the exact pain points they were experiencing. This experience gave me the ability to confidently design something I knew would make their lives easier.

• Collaborate early with developers. Designs were shown early to developers and there was incredibly helpful collaboration with them during the design iteration. There were discussions around what items might be a heavy development lift and can be prioritized later. It also gave me an understanding of potential limitations or challenges when it came to certain automation calculations that exist on the table. Some limitations, such as filtering, changed some elements of design. For example, a query filter would be a heavier lift to build, but a “My Patients” quick filter button wouldn’t be, which directly affected design decisions to create that quick filter button.

Room for Improvement

Move away from a table view. We chose to keep our initial product very similar to an Excel spreadsheet. A recruiter’s job already involves a lot of moving parts — much more than what was discussed in this case study. The last thing we wanted to do was introduce a high learning curve with a new product. In a future iteration, I would love to explore designs that might resemble a more intuitive recruitment management system