HOPES

Scaled a clinical mental health platform 5x by reducing onboarding friction and consolidating a fragmented admin system

Role


Solo Product Designer

Duration

7 months

When

2025

Impact

  • Enabled 5x user growth (100 to 500+ patients)

  • Eliminated operational costs by migrating legacy admin platform into unified system

Your phone knows you're having a mental health relapse before you do

HOPES is a digital phenotyping platform developed with Singapore's Institute of Mental Health which tracks biomarkers like sleep patterns, movement, or heart rates. Running seamlessly in the background of patients' phones and wearables, these machine learning models can help clinicians predict their patients’ mental health changes—even predicting relapses with 90% accuracy.

Patient data is captured through the mobile app while clinicians monitor insights on their dashboard.

The challenge: reducing cost-per-user

While the technology's effectiveness had already been proven, the platform needed to reduce its cost-per-user to be sustainable. Currently serving about 100 patients as part of controlled clinical studies, we aimed to tackle the problem from both sides: increasing users and decreasing operational costs.

Working largely as the sole product designer over 7 months, I interviewed 10 patients and 10 clinicians, as well as the HOPES internal tech team.

Two bottlenecks preventing scale

The onboarding burden

Since the app was not designed for independent use, I discovered that clinicians had to spend precious consultation time explaining the app’s features to patients, slowing down the rate at which they could be onboarded.

Certain features—like a personalized early warning signs list—could only be set up through the separate clinician dashboard, and not by patients themselves via the app.

This also prevented the user base from being expanded to include low-risk patients who didn't have dedicated case managers..

"While we want to help, there is often no time to explain the app when we have so much else to cover with patients during our consultations.”

- Clinician

The ‘Early Warning Signs’ list is only editable by clinicians through the clinician dashboard.

Fragmented systems = bloated operational costs

A legacy admin system used by the internal tech team operated separately from the clinician dashboard, requiring the team to juggle multiple platforms for basic tasks like setting up studies or managing user access. This fragmentation drove up security and maintenance costs.

The legacy admin system with features accumulated over months without proper maintenance, resulting in unclear information architecture

A dual approach: increasing users, lowering costs

1. Removing clinician dependency

We introduced an onboarding flow that would allow patients to orient themselves with the app independently, removing dependency on clinicians for onboarding.

Upon surveying onboarding approaches, I identified a few dominant patterns: progressive disclosure through in-app tooltips, or upfront value communication through static screens.

We initially tested guided tooltips, but users found the screen-jumping disruptive and wanted to understand the app's value upfront.

Initial trails with guided tooltips tested poorly with users

We resolved this with an onboarding flow with clear, static screens introducing key features, making the platform's purpose and suite of features immediately clear to new users.

The onboarding flow with static screens resonated with users

For features that patients should be able to manage independently, such as the personalized ‘Early Warning Signs’ list, I redesigned them to allow for management directly in app, instead of solely through the clinician dashboard. To reduce setup friction, I also added suggested input chips that gave patients a jump-off point.

These changes allowed the app to expand from 100 clinician-managed patients to 500+ self-service users without proportional increases in clinical support time.

Patients can now manage their early warning signs directly in the app, with suggested options to get started

2. Reducing operational costs through system consolidation

The legacy admin system lacked proper maintenance—features had accumulated over months, resulting in a tangled mix of active functions, abandoned pages, and unclear information architecture.

I held multiple prioritization sessions with the dev team to segment the system into what needed to migrate, what would remain backend-only, and what could be retired entirely. We applied the the YAGNI principle (You Aren't Gonna Need It)prioritizing only functions actively used rather than building for hypothetical future needs. This was great in keeping kept the migration focused on solving the most urgent problems.

Scoping exercise that separated what to migrate (in scope) versus what to deprioritize (out of scope)

Redesigning the RBAC (Role-Based Access Control) system presented a particular challenge. The existing setup let users check multiple roles at once. The checkboxes overlapped heavily, functioning as permissions rather than true roles, creating confusion about the actual access rights which each role should have.

Original user roles system with multi-select checkboxes that functioned as permissions rather than true roles

I simplified to a single-role system, with radio buttons. While stakeholders were initially concerned about losing flexibility, interviews showed this flexibility was largely unused: many admin users did not even know what permissions each role had and tended to just pick what “seemed right”. Each role now had a clear, defined purpose that users could understand at a glance.

Redesigned single-role system using radio buttons, where each role has a clear, defined purpose

Beyond user roles, I restructured key workflows to improve organization, such as a ‘New Programme’ creation flow. Previously fragmented across multiple pages, I consolidated it into six-step flow with compulsory fields in each section—preventing engineers from accidentally skipping inputs that could potentially jeopardize data collection.

Consolidated study creation flow with required fields at each step, preventing accidental data collection errors

Upon its full implementation, this migration successfully eliminated ongoing security maintenance costs of the legacy platform, reducing operational costs for the app.