MDLIVE / REMOTE PATIENT MONITORING / DEVICE CONNECTIVITY
Taking the work out of chronic care
I led the design of MDLIVE’s device connectivity experience, replacing manual vitals logging and increasing RPM program utilization by more than 30%.
HERO VISUAL / ADD IMAGE
Device pairing on mobile
ROLE
Lead Product Designer
SCOPE
iOS, Android, responsive web
TEAM
Product, Engineering, Clinical, <device vendor>
TIMELINE
<# months> · Launched <confirm date>
THE OUTCOME / LESS EFFORT, MORE ENGAGEMENT
Care that tracks itself.
Connected devices removed the burden of routine data entry, giving patients a simpler way to participate and providers more consistent readings to work with.
30%+
increase in RPM program utilization
<#%>
of patients tracking through connected devices
<#%>
pairing success rate <if available>
METRIC TO CONFIRM / Define utilization, baseline, and measurement window; replace remaining placeholders with verified data.
THE STORY IN 30 SECONDS
Remote monitoring only works when the data arrives.
MDLIVE’s first remote patient monitoring (RPM) programs asked patients with chronic conditions to log in and enter their readings by hand—up to four times a day. Participation fell short, leaving providers with too little data to act on.
I led design for a device connectivity experience that let patients connect their own blood pressure monitors, glucose meters, and smart scales across iOS, Android, and web. Delivered on a contract-driven timeline, it became a key feature in the expansion of MDLIVE’s virtual primary care service. Program utilization increased by more than 30%.
01 / THE PROBLEM
Four times a day. By keyboard.
At the end of 2021, MDLIVE launched its first RPM programs for blood glucose, blood pressure, and weight. The promise was ongoing chronic care between visits. The experience depended on patients repeatedly logging in and typing in their numbers.
That put data entry on top of managing a condition. When patients stopped logging, providers lost the information they needed to assess progress and recommend changes.
For the business, engagement was falling short just as RPM was becoming central to a new virtual primary care offering. The design opportunity was not to make the form easier—it was to remove the recurring work.
ADD V1 INTERFACE / The original experience: four times a day, by keyboard.
What if patients didn’t have to remember to track their health at all?
THE QUESTION I PUT TO THE TEAM
The goals
Patients: reduce the effort of everyday tracking. Providers: receive consistent readings that support care decisions. Business: improve RPM participation as virtual primary care expands.
02 / FRAMING THE BET
Remove the work, not just the keystrokes.
Affordable smart health devices made automatic readings possible. The team vetted vendors and selected one supporting cloud-based and Bluetooth connections across iOS, Android, and web. <Add the criteria you advocated for, trade-offs you raised, and how your input shaped the selection.>
Two constraints shaped the work. Patients brought their own devices—including iHealth, Qardio, Omron, A&D, and Welch Allyn—so setup had to respect the investment they had already made. A contractual deadline compressed the timeline, making it essential to prioritize the moments most likely to determine successful adoption.
ADD SYSTEM MAP / Supported devices, cloud and Bluetooth connections, and platform constraints
The product bet: reducing the repeated effort of tracking would make participation more sustainable. The experience had to carry patients through setup—and help them recover when the connection failed.
03 / THREE DECISIONS THAT MADE IT WORK · 01
Support the hardest moment, not just the happy path
Pairing a Bluetooth device can confuse even tech-savvy users. Patients managing hypertension or diabetes did not need another puzzle. A connection feature would only create value if people could get through setup and receive their first reading.
I designed a guided onboarding flow rather than leaving setup in a settings page. It walked patients from opening the box to seeing their first reading. I used Chronic Carl, a patient persona with hypertension, to keep the intended user’s context visible throughout design. <Add the research or testing that shaped the sequence.>
ADD ANNOTATED ONBOARDING / From device setup to first reading
WHY IT MATTERED
The highest-friction moment received the most support. <Add setup completion rate or time to first reading, including the baseline.>
DESIGN DECISION · 02
Design recovery as part of the core experience
A pairing failure is visible. A device that appears connected but never syncs is easier to miss—and just as damaging to a monitoring program. Either can quietly interrupt participation and leave providers without data.
I mapped the full journey to identify error points and designed recovery paths that explained what happened and what patients could do next. <Add the actual error messages, retry behavior, sync-status feedback, and support handoff you designed.>
ADD ANNOTATED STATES / Pairing errors, missing readings, and recovery paths
WHY IT MATTERED
A failed connection did not have to end the patient’s participation. <Add recovery rate or change in device-related support contacts.>
DESIGN DECISION · 03
Keep the care journey coherent across technical differences
iOS, Android, and web had different connection constraints. Blood pressure monitors, glucose meters, and scales added another layer of variation, while requirements continued to shift late in the project.
I worked closely with Engineering throughout design so emerging constraints could be addressed before handoff. <Add what stayed consistent, what differed by platform or device, and one example of how you managed a late requirement change.>
ADD FLOW VARIATIONS / Shared patterns and platform- or device-specific behavior
WHY IT MATTERED
The goal was one understandable care journey without pretending every platform worked the same way. The team delivered against a compressed, contract-driven timeline. <Add the confirmed delivery window.>
04 / SEEING IT WORK
From opening the box to a connected reading.
ADD RECORDING / End-to-end device connection on iOS. Use de-identified patient data.
05 / THE RESULTS
Less manual work. More participation.
RESULTS / Define the utilization metric, baseline, and measurement window before publishing.
30%+
increase in RPM program utilization
<#%>
of patients tracking through connected devices
<#>
devices paired since launch
Additional evidence to add: <setup completion rate> and <change in data points per patient per week>. Connecting devices also changed what providers had to work with: <add Clinical or provider feedback on data quality and care decisions>.
06 / A GOOD PROBLEM TO HAVE
When tracking gets easier, the next problem is making data useful.
Once connecting a device became easier, patients generated more data than the original program screens were designed to show. I began designing a trends and progress experience to help patients understand whether their efforts were working. <Confirm whether it shipped and add outcomes—or explain why it remained on the roadmap.>
ADD UPDATED INTERFACE / Trends and progress: helping patients understand their readings
07 / WHAT I’D TELL THE NEXT TEAM
Solve the “why” alongside the “how.”
Design reduced the friction, but it did not resolve every patient’s understanding of what the programs were for. Awareness lagged behind usability. Closing that gap requires a partnership with Marketing, Clinical, and patient education—not just a better interface. <Add 1–2 sentences on how you would approach awareness differently now.>
Made with care. And a little mischief.