Health Research Space (HRS)

Our mission

We were on a mission to simplify the way patients participant in clinical trials. Rather than having patient consent, perform activities, message, and otherwise in different settings, we wanted to combine as many of our users' needs into one place.

Our vision

We want to begin building a world where people can contribute to clinical research without needed to call 1, 2, or even 10 practitioners to enroll. We want patients to participate freely in research, share with others, and trust that we have their best interest in mind.

Baseline Research

Understanding the market

At the beginning of the project, we knew we wanted to build an experience that met people where they are at – patients are busy people, with diverse lives, and we did not want to get in the way of that.

Once we had a mission and vision carved out with our stakeholders, we did some generative research to build user personas, and did additional market research to compare our competitors.

Competitive Analysis

To kick off the program, I lead the effort in building out a strategic comparative analysis between some of our competitor's offerings. We using this information to fuel discussions in a stakeholder workshop where we built out our value statement and positioning profile. For this analysis, we identified a collection of fourteen (14) primary and secondary competitors to understand: (1). there app store presence, (2). their public ratings, (3). there visual style [UI], and (4). major feature offerings. Here are some things that I learned:

Insight 1:

A majority of direct competitors include ePRO / surveying, visit information and consenting embedded into their trial experiences. Most often, this manifested as simple surveys.

Insight 2:

Brand customization was minimal – with UI customization and branding applying mainly to color, but not things like illustrations, characters, games, or badges.

Insight 3:

Insight 4:

Competitors experiences were decentralized and rarely were self-contained. For example, many trial experiences used Greenphire for external payments management. Many user reviews reflected frustration with disintegration in workflows. While this is expected for clinical trials (disintegration), I quickly realized how important smooth transitions are to our users.

The most common complaints from user reviews were related to latency and load time, or technical hiccups with login (E.X., biometrics not working as expected). This emphasized the importance of optimizing the experience for efficiency, while also using shortcuts (like password memory) to optimize the flow.

We put together a high level report that we shared out to major stakeholders in design, product, and the business. We used this to agree on how we wanted the system to look, and what features we would prioritize in the backlog. Once we established a feature backlog, designers were given work based on interest and skillset.

Persona Development

During our roadmap planning workshops, we adamantly pursued generative and investigational research with the primary audiences of our product. We aligned on interviewing patients, caregivers to patients, and doctors (with a focus on investigational studies). While we were not able to get enough access to build out a caregiver persona (3 interviews), we did learn some interesting insights from parents about how they think about care through another person. I took the lead on putting together a protocol to facilitate dialogue with our user base.

My research goals for the participant were as follows:

1. Understand what motives and engages patients during clinical research

2. Identify who patients communicate with during studies

3. Parse apart expectations for clinical trial technologies versus other healthcare tech (E.X., MyChart)

4. Examine the barriers / frictions to continuing research (leading to drop-out)

Persona #1 – patient (primary)

Patient persona process:

This artifact draws upon an extensive dataset consisting of twelve (12) in-depth, one-hour interviews conducted with a diverse cohort of patients grappling with a myriad of complex chronic conditions. It is noteworthy that a substantial proportion of these patients encountered the added challenge of managing multiple, often co-occurring chronic conditions, with six of the interviewees facing the complexity of managing two or more concurrent conditions.

Our research approach was a collaborative effort, with each team member leading distinct interviews following a unified discussion guide. Personally, I led seven (7) of these interviews. Subsequently, we embarked on a rigorous qualitative analysis rooted in grounded theory methodology. To ensure consistency in our findings, we centralized our qualitative (axial) codes, enabling a holistic view of the data. This consolidated dataset was then subjected to a team affinity mapping exercise to unveil overarching themes and patterns in the data. Leveraging these central themes extracted from the interviews, we crafted the essential components of our patient persona, thereby ensuring that our design and user experience efforts were firmly grounded in a comprehensive understanding of the user landscape.

Generally, you will see in this persona major themes of business colliding with sickness. For a majority (9/12) patients, they struggled to manage their condition and stay abreast of study activities. Many (11/12) patients were motivated primarily by the goal of achieving overall improved health

See more about details about the protocol I designed:

Persona #2 – Investigator (Support)

Investigator Persona:

Similarly, development of this persona is underpinned by a foundation comprising seven (7) extensive one-hour interviews conducted with physicians representing diverse clinical specialties, all of whom are actively engaged in clinical research. The analysis process employed for this persona mirrors the approach applied to the patient personas.

Personally, the insights of these interviews surprised me the most. Up to this point, I assumed that investigators in interventional products are more high-touch than they really are. For all of the investigators we spoke to (7/7) their primary concern was patient safety, with the next most common goal (5/7) being good documentation practices. I learned that other roles (support staff – CRAs, Call Center, CTAs, and others) are more invested in the personal relationships, and coaching patient to achieve their goals.

My research goals for the investigator were as follows:

1. Learn how physicians think about supporting patients throughout their journey

2. Separate expectations for clinical research investigators and general healthcare providers (outside of clinical research)

3. Examine workflows for tracking patients and study data

Style Guide, Asset Library

To ensure that our leaders were aligned with our vision, we developed a style guide that later transformed into a comprehensive design system used throughout our design process. This design system became essential as our application aims to be a white label solution, adaptable to various clients. Therefore, maintaining consistency right from the start was of utmost importance to guarantee a seamless user experience across different implementations. This also allowed engineers to get started on tokenizing elements of the system before we implemented major feature work.

Style guide

Design decisions

When we constructed our style guide, we collaborated with product leaders to make sure we were capturing the essence of the brand. We were tasked to create a brand vision that aligned with corporate's style, but created a brighter look and feel than that of our investigator experiences.

We aligned on a more blue-centered palette with brighter accent colors to carry throughout our design system components, and other custom assets.

To help engineering work with a strong foundation, we designed, validated, and built components for our design system. We had to ensure our designs are scalable, and that we lay a strong foundation for future product expansion. Functionally, we emulated a lot of the core experiences from both Material UI and our company's design system, but applied stylistic updates. Because our product is meant to be white-labeled and sold to other sponsors (brands), we needed to pursue custom development to ensure full customization for our clients (E.X., applying new branding skins)

As individual components were created, we were able to test with business partners, which helped us build trust (they saw us delivering!)

Building out a component library:

This is a small example of the library I built out. I lead the effort in creating custom assets for: navigation, buttons, inputs, surveys, among others. I began with atoms, and built molecules to extend to other products.

Feature #1

Home / Core

First, I led the design of the core navigation and 'home' experience for the application. We used this as scaffolding for later design decisions and allowed us to use a modal approach for additional features. We started with mobile experiences and then extended to tablet and desktop, with the knowledge that most patients would prefer mobile engagement for survey-based studies.

Design Highlights

Design challenges

This ask initially came from Product Management, and it was very challenging to start with such a core view of the experience. Although we pushed back on the request, and asked for latitude to design a more lightweight or isolated feature first, product really wanted core UI to show the client. In the end, we partnered with a legacy product in the same problem space to generate some ideas and co-create. We used the data elements from a previous study to inform our designs. For example, we learned that some studies require 'time limits' on activities – similar to exams.

1. Firm up navigation across devices: In this phase, we made sure that no matter how many items exist in the menu (we tested 3 to 20), that our system can accommodate.

2. Emphasize rewards: When applying the base design system, we got feedback that rewards / engagement elements were not very prominent. We created a divergent pattern / style for rewards that carried through the rest of the experience.

3. Separate activities based on occurrence: For some users, they want to see activities that are 'due immediately'. Because this was the most important 'filter' we applied a segmented controller on the home view to elevate this control to the top.

Design decisions

Feature #2

Activities

For the activities feature, we defined a core set of activities that we will support, including: validated instruments, external research opportunities, educational resources, videos, and blogs. For each, we kept the same fundamental 'core' [instructions, steps, points, etc.] and customized content throughout.

Design Objective

The business requirement here was quite simple – we need a way to support lots of content. This could be patient reported outcomes (ePROs), quizzes, surveys, videos (educational), blog posts, and more. As such, we designed the activities 'cards' to accommodate any type of media, while maintaining a consistent flow and appearance.

Design challenges

The biggest challenge with activities was having a good idea of what content types could be available, and influencing backend decisions for the backend. For example, what happens when a customer wants to include 20 high quality renders in an article? Do we all that? How do we deal with externally managed content? In the end, we worked closely with engineering to define an administrator portal (backend CMS) for managing content with ample flexibility.

1. Start with the templates (configuration): For every content type, we started with the technical side and then applied the design layer. For example, we did some basic calculations to see how quickly a site could load / lag with varying amounts of content and optimized rules to follow.

2. Embed rating into the activity: Our business partners pushed for including a 'rating system' on the activity's surface (re: the cards). We were able to compromise and include feedback elements at the end of the surveys, to ensure users have immediacy and context to their actions.

Design decisions

Final UI