Patient Support Platform (PSP)

Project Overview

For this project, I was tasked with the challenge: How do we create a digital experience to support patients prescribed commercial products for chronic illness?

Business Justification:

Our business partners asked my team of experienced mobile UX designers to rethink motivation and participation for patients in a program where sponsors support patients that need extra support with their overall health and wellbeing. The PSP market is influenced by several main factors, including the increasing frequency of chronic diseases worldwide, the shift toward patient-centered care and value-based healthcare models, and the need for more thorough patient care. Integrating digital health technologies and data analytics enables more tailored and efficient care delivery. Pharmaceutical businesses use PSPs to differentiate their brands, create patient loyalty, and comply with regulations. The drivers for the PSP market are the demand for improved patient care, technological improvements, regulatory requirements, and pharmaceutical company initiatives.

Program Challenges:

Patient Support Programs (PSP) face several challenges, including maintaining patient engagement over time, ensuring seamless connection with electronic health data, and demonstrating cost-effectiveness. Access gaps pose challenges, particularly among impoverished communities. Standardized metrics to assess the success of PSPs are needed. Overcoming healthcare professionals’ reluctance to accept new technology offers additional challenges. The PSP market is influenced by several main factors, including the increasing frequency of chronic diseases worldwide, the shift toward patient-centered care and value-based healthcare models, and the need for more thorough patient care. Integrating digital health technologies and data analytics enables more tailored and efficient care delivery. Pharmaceutical businesses use PSPs to differentiate their brands, create patient loyalty, and comply with regulations. The drivers for the PSP market are the demand for improved patient care, technological improvements, regulatory requirements, and pharmaceutical company initiatives.

Defining Our User:

Given the massive scope of the platform experience, I advocated for making our process more user-centered whenever possible. While I think the persona could still be more specific, I am proud of the progress we made in getting our business partners to think about our users first – a shift in thought from our traditional client-first mentality. We used our persona, Nick, to narrate with our audience more about how users with chronic illnesses might have intermittent motivations for their program participation, and that their illnesses maybe be 'periodic' with flare-ups.

I used this annotated persona to communicate with my stakeholders, so they could better understand the purpose of our persona.

Delivered November 2023

MVP Feature Scope

After extensive stakeholder conversations and scope alignment conversations, we aligned on the following features:

• Onboarding / Sign-in

• ePROs & surveys

• Device Integration

• Notifications

• Passive Data

• Profile

• Rewards & Gamification

• Televisits

• Travel Support

• Educational Resources & Materials

Our Design Process

Once our business partners had an app scope in mind, I lead a workshop to discuss our design process for the product lifecycle, as well as the basic requirements for each feature. This was an important first step, so that the design team could iterate on an application architecture before designing the nuances of each feature. As the design lead, I lead the grooming and estimation of each feature, managed the work assignment, and was responsible for delivery.

Once I was assigned a feature, I begin by conducting thorough research to understand the problem or challenge at hand. This includes gathering information, analyzing data, doing a technical feasibility review of the platform, and hosting a design thinking workshop for product strategy stakeholders. Once I had clear understanding of the problem, I then moved on to brainstorming and ideation. I explored various concepts and possibilities with my team, sketching out ideas and hosting a series of workshops with our business partners. Collaboration is an essential part of my design process, as I seek feedback and input from colleagues and stakeholders to ensure a well-rounded perspective. More specifically, I hosted co-design workshops, where I encouraged my business partners to work in Figma alongside me. Finally, we brought our ideas to life through detailed design and implementation, paying close attention to aesthetics, functionality, and user experience.

Note: I used this document throughout the project to denote my feature status, and hold engineering accountable to design quality.

Defining Visual Style & Core Assets

Managing a Custom Asset Library

Our team began with iOS17 components and customized only when necessary, with the knowing the client brands would 'reskin' our application later. While iOS17 was my base, I also built and tokenized a custom library for unique assets unavailable in iOS – like televisits, badges, notifications, and custom gestures for ePROs.

Working alongside Human Interface Guidelines

One of things that make this project very unique, is that it is fundamentally brand agnostic. Our business partners made the ultimate platform decision to use stock iOS elements where possible, with customization based on client's need (i.e., a completely white labeled application).

Here is an example of how color tokenization allows us to easily replace the theme of base components on the system level.

Here is an example of some custom components that I built in alignment with HIG for our custom asset library.

Feature Highlight

Onboarding

First, I led the process of building out our onboarding workflows. This begin with stakeholder workshop, and worked through ideation and user story generation. I on accelerating onboarding and getting users into the experience as quickly as possible.

Feature Objective

When I asked my business partners what the goals of onboarding are, they unanimously agreed that sign up / sign in experiences should inform users about the program (first priority) and make users feel "welcomed" (second priority). From our business goals, I facilitated a workshop to build out user flows for onboarding.

Artifacts:

In the workshops, I built out four primary workflows:

Flow #1: New User

Flow #2: Forgotten Password

Flow 3: Welcome Mat

Flow #4: Existing User

We created a series of modular components that could be added or removed based on client needs, including:

1. Account creation

2. Language selection

3. FaceID enablement

4. Notifications enablement

5. Program consent

6. Phone number verification

7. Eligibility screener

8. Demographic survey

9. Heath baseline survey

Feature Highlights:

Design Decisions:

From the workshops, we made some major decisions to improve the user experience:

1. Modular Sign-up: We aligned on building sign up as a lightweight as possible with components or modules that could be easily added or removed by clients.

2. "Welcome Mat": I advocated for a post-sign up, pre-program welcome experience to help users learn about our platform. In essence, our design 'locks' future activities until onboarding is complete, but treats onboarding tasks like ePROs or surveys in the platform. This decision helps to habituate our user to the platform early.

3. Baseline Approach: Onboarding is critical to capture a patient's baselines. We thought about the goals of a program (end-to-end) and capturing all of the 'starting' values that we could use to compare a user's journey. For example, if the user is enrolling in a weight-loss program, we capture necessary baselines in onboarding, like weight, goal weight, resting heart rate, and other biomarkers.

Feature Highlight

Health Data

This feature took place after we had a strong framework for our architecture, ePROS, notifications, and onboarding. For this feature, I initiated with a similar workshop model, but also conducted stakeholder interviews with SMEs that have medical knowledge of obesity.

Feature Objective

I know you're probably reading this and asking yourself – "how are you going to white label data visualizations"? Great question! I had the same thought at the beginning of this feature. For this feature, we started with a very narrow business case (obesity) and then later extended our insights to a reporting framework with a library of data visualizations. Our design team acknowledged early in the process that once our product is adopted in a client context, heavy customization will be required here. Either way, we created a great framework for monthly reports, visualizing daily metrics, and how to integrate trackers into the experience.

Artifacts:

Based on stakeholder interviews, I created a basic flow of how to conceptualize our data streams across trackers (in-app), trackers (from HK / watch data), and providers.

Flow: Monthly Summary with Measures

We created a series of elements to allow users to record their symptoms and quality of life (QoL), view monthly reports, and view their most recent recordings from data streams.

1. ChatGPT reporting summary: As a part of the monthly report, we implemented an API call to ChatGPT using data from the user's profile. More specifically, every month, we push data from a user's changes in weight, activity, heart rate, and symptoms, and ChatGPT puts together a basic summary on how things have changed for the user over time.

2. Wear Goals: A big risk to data quality for this product is having users that provide accurate and consistent data. As a consequence, I designed 'goals' that help users remember to wear their Apple Watch daily.

3. Data Troubleshooting: For this program, devices are provisioned by a sponsor (ex. a pharmaceutical company), so having a an active data stream is very important to program adherence. I designed a series of alerts and help steps to help users remedy any data streaming issues from their devices. For example: What happens if the app hasn't received a weight reading from a smart scale in 7 days?

Feature Highlights:

Design Decisions:

Throughout the made some major decisions to improve the user experience:

1. Monthly Reports: I put a lot of energy into framing 'time' for patients so that they can see how they are progressing on a goal, but do not obsess over their daily recordings. For example, research shows that it's unhealthy for a patient in clinical studies to think about their weight daily, and that it can form an unhealthy relationship to food and weight. With this knowledge, I designed this feature with a 'monthly report' that helps a user contextualize their progress in the program across a more meaningful time range.

2. Multiple Time Frames: Week, Month, Program: For some patients, monthly reports aren't enough. As a consequences, we also thought about customization to time ranges, where users can specify certain metrics, and how often they want to be communicated major changes.

3. Enhance, don't recreate Apple's HealthKit: Wherever a feature already exists in iOS's native HealthKit, I avoided simply replicating functionality, with the knowledge that our users can already access those tools. Instead, I used that data to create more contextual and program focused goals.

Feature Highlight

Televisits

In this project, we completed a comparative analysis and user surveys, created mixed fidelity connecting, and went through multiple cycles of refinement incorporating feedback from team members as well as the Apple Enterprise Design Lab. Our aim was to make an immersive video chat experience specifically for clinical trial participants. The project delivered a modular capability that is reusable across native iOS applications. We concluded with the creation of fully tested POC allowing multiple video streams integrated into our demo application.

Feature Objective

This feature started slightly differently, given the technical limitations in the space. While we still deep user-centered design, we started with our technical teams to decide on an API for managing our call stream. Our engineering team advocated for the use of the Vanage Tokbox API because of the security protocol requirements for clinical applications. Once we were aligned on the tech stack, we asked ourselves:

• How Might participants engage with investigators in a digital visit experience?

• How Might multiple attendees (including site staff, caretakers, and other providers) join a call together?

• How Might virtual visits exist alongside other Volunteer application workflows?

Since there are so many existing televisit and video call experiences that exist on the market, we did a baseline assessment of some major competitors (including: Zoom, FaceTime, WebEx, and eClinical.)

Key Outputs:

• Support of 6+ callers in a televisit

• 12 standard video chat features

• 6 expanded features for clinical trials

Design Decisions:

Throughout the made some major decisions to improve the user experience:

1. Multi-role Carousel: We put a lot of energy into balancing how users are prioritized when they are talking. Some competitors – like Zoom – operate under the assumption that users want to see the person who is speaking as highlighted. While this is probably a good assumption in personal and social contexts, but in healthcare, the parties on a call might need more control. With that knowledge, we allow users to highlight whatever video feed they want based on which tile they tap on in the carousel.

2. Waiting Room: We decided to avoid 'waiting rooms' and instead use patient-based tenants for each appointment. This allows users to access their appointments without the friction of one time passwords, while ensuring that two patients can never be in the same call room.

3. Screen Sharing: For many of the patients enrolled in clinical studies, there will be relevant information on their device that site staff needs to see. For example, in studies with provisioned devices, users may have watch data from their Apple watch that needs to stream into our app. We designed a balanced sharing experience that allows users to share their device during meetings, as to get help from site staff when the study requires users to link their data.

Validation & testing

Because timelines were very short, there was only time for guerilla testing and stakeholder feedback for the initial definition of the features. Once I had more latitude (meaning, once the app had a baseline release), I was able to convince our business partners to invest in some user research. In the future, I hope to do this on a sprint-by-sprint basis.

Usability testing

After the first release of this experience, we put together a usability test with the following goals:

1. Ensure all of the features are findable for our users

2. Gauge initial impressions of the UI

3. Identify major usability issues that impede the user from creating study objectives

4. Understand the relationship between passive data (from a watch) and other measures (like surveys). More specifically, do users combine these ideas mentally, or do they have different mental models for each data source?

I put together a protocol including both task based factors, as well as some qualitative questions to open and close the usability test. Using UserTesting, we got feedback (n=30)from users. From the data, our team performed qualitative coding and affinity diagraming to find patterns among the users. Because the questions ranged from task-based to qualitative, we parsed apart each and created different datasets based on the question type.

Opportunities for Improvement:

1. Reward Redemption Clarity: Several users struggled with redeeming rewards. Improving instructions, simplifying steps, and providing clearer guidance during the redemption process could enhance user experience significantly.

2. Educational Resource Enhancement: While users appreciated the educational materials, suggestions for improvement included making the resources more personalized, introducing interactive elements, and simplifying navigation. Customizing content based on user interests and incorporating interactive elements could enhance engagement.

3. Watch Data Syncing Optimization: Users expressed issues with watch data syncing, mentioning delays or confusion. Optimizing the syncing process, providing troubleshooting guides, and enabling more real-time syncing could improve the accuracy and reliability of data for users utilizing wearable devices.

Positive Aspects of the App:

1. Task Completion Rates: Overall, users were able to complete tasks within the app at relatively high percentages, indicating that the app design allows users to navigate and accomplish various tasks effectively.

2. User Engagement with Rewards: Users generally found the rewards section enjoyable, indicating potential for user retention through gamification or diverse reward options. Some users specifically praised the rewards, indicating a strong potential for user engagement.

3. Ease of Use and Engagement: Despite areas for improvement, users highlighted the app's smooth navigation, engaging features, and clear educational resources, suggesting that the app has a solid foundation for usability and engagement.

Final UI

While I created both light and dark modes for all of the following UI, I am highlighting light mode below.

Final Reflection:

• Too much autonomy can be scary. Don't get me wrong, I loved having so much autonomy in this space. I felt trusted, and in every situation, I got to act as the "PM" for every feature throughout the product. This was fun (and a change of pace for me) but also very, very daunting.

• Product managers exist for good reason. There were a lot of moments where our strategy lead (the PO) wanted things that were visionary beyond belief. For example, our PO initially requested that we support financial reimbursement for patients that spend money on travel to receive infusions – including Ubers, flights, hotels, etc. I had to work very diligently as the lead to mitigate scope creep, and partner with product management to create a satisfactory roadmap.

Future Work:

I'll be the first to admit that this program still needs a lot of work. With that being said, I'm super proud of the speed and quality we were able to produce an MVP project in just 4 months. Going into the new year, we just signed our first implementation deal with a client, meaning we are going to customize the UI to brand, build out new features, and pursue the design and implementation of administrator portals. Here are the next things on my radar for PSP:

• New Features: I did some exploration with client services (people selling product) and I identified a few new features to add to the roadmap. I will be researching and iterating on: travel support, document management, financial tools / reimbursements, and device provisioning in the coming months.

• Validation: I did some basic usability tests and made design tweaks as a consequence, but I would love to design some longer longitudinal studies, like a diary study, to see how users use and adapt through the platform over time. I am particularly worried about long term motivation, so I'd like to see how users resonate with our point system, and explore other gamification elements (like community forums).

• Administrator Portal: Sponsors demand a lot of system customization that puts a lot of pressure on our technical teams. We will be pursuing the design and implementation of an administrator portal for customizing ePROs, content, and aesthetics (ex. icons and imagery) throughout the application without needing configuration requests.