Loading...

Research Approach

I used a mixed-methods research approach to understand the gap between Diplora's capable ECG hardware and the experience of using it at home. The research had to answer two connected questions: what do older adults need in order to feel confident using a monitoring device, and what can the patient-facing app communicate without crossing into diagnosis?

I combined literature review, competitor analysis, stakeholder interviews, patient interviews, survey analysis, and internal design feedback. Using these methods together helped me compare formal accessibility requirements with real user behavior, then turn both into concrete priorities for onboarding, status feedback, pairing, help, and symptom logging.

Key Findings

Research Overview

The project focused on an accessible ECG companion app for elderly cardiovascular patients. The app was not intended to interpret ECG results for patients. Its role was to make the monitoring process understandable by showing device status, connection, battery, recording state, and clear next steps when something needed attention.

Main research question: How can an elderly-accessible ECG interface address barriers such as font size, contrast, touch targets, and cognitive load while meeting medical-device requirements?

Literature Review

I reviewed WCAG 2.1 AA guidance, research into older adult interfaces, and medical-device requirements before making design decisions. The review focused on the barriers most likely to affect cardiovascular patients at home: presbyopia, reduced contrast sensitivity, slower touch interactions, and varying levels of digital confidence.

These findings became practical design rules rather than background theory. They supported larger text, strong contrast, simple language, and touch targets of at least 44 by 44 pixels. The review also clarified the product boundary: the app should communicate device status, battery, and connection, while diagnostic interpretation remains with healthcare professionals.

Stakeholder Interviews

I spoke with cardiologists, GPs, and company stakeholders about the clinical and technical requirements behind the interface. We discussed the value of longer monitoring periods, leads detaching, movement affecting signal quality, and the importance of accurate sensor placement.

The interviews defined what the patient-facing app should and should not do. It needed to confirm whether the device was connected, recording, and working, while reports and diagnostic interpretation remained with specialists. That boundary shaped the status bar, onboarding language, placement guidance, and alerts.

Patient Interviews

I conducted in-depth interviews with elderly Holter monitor users aged 70 and above to understand what monitoring felt like at home. Participants described physical discomfort, anxiety about whether the device had stopped working, and confusion caused by technical information.

Their needs were more direct than the existing interface suggested. They were less interested in graphs than in simple answers: is it working, are readings being recorded, and what should I do if something goes wrong? This shifted the design toward reassurance, large text, simple navigation, visual guidance, and clear next steps.

Survey Analysis

I ran a quantitative survey with 50 respondents aged 18 to 75 and above to test whether the interview themes appeared at a broader scale. The survey measured perceived complexity, readability, confidence in device status, and preferred ways of learning how to use a monitoring device.

The strongest findings were that 54% found health apps too complicated, 14% of respondents aged 46 and above struggled with small text, and 70% wanted clear confirmation that their device was working. Video demonstrations were preferred by 66% of respondents, followed by step-by-step pictures at 56%. These results turned reassurance, visual guidance, and simplified navigation into evidence-based priorities.

Internal Feedback

I reviewed the existing Figma designs with Diplora stakeholders before moving into prototyping. This exposed small default text, inconsistent visual language, unclear status communication, and an onboarding flow that asked users to process too much information.

I used that feedback to refine the visual direction and simplify the highest-risk flows. It also helped define the MVP around accessible onboarding, a persistent status bar, device pairing, help, emergency contact access, and focused symptom logging.

Brand Identity

I helped shape Diplora's visual identity around medical credibility, reassurance, and ease of use. The design needed to feel trustworthy and calm without making the interface feel clinical or intimidating, especially for older adults using the app at home.

Diplora brand identity

Accessible Design Standards

I translated the research into practical standards: minimum 18pt body text, at least 4.5:1 contrast, 44x44px touch targets, clear hierarchy, readable language, and icons supported by text labels.

Scalable Components

I established reusable patterns for buttons, cards, navigation, status feedback, spacing, and form controls. These components created a consistent foundation for the Flutter implementation and future development.

Design System Takeaway

The design system turned research findings into rules that could be reused and checked throughout the product. With the visual and accessibility foundation in place, the next step was to decide which user needs were essential for the MVP and how those needs should shape the product flow.

User Requirements & Features

Using the MOSCOW method, I prioritized features based on accessibility and clinical validation requirements. Must-have features address the core needs identified in research.

User Journey Mapping

I mapped the experience from unboxing and account setup through sensor placement, pairing, daily status checks, emergencies, and the end of the monitoring period. The map highlighted where users were most likely to feel lost or anxious, especially during setup and when checking whether the device was still working.

MoSCoW Prioritization

Must-haves were accessible onboarding, device pairing, persistent status feedback, emergency contact access, and a clear device-working confirmation. Video guidance, symptom logging, history, and haptic or audio feedback were prioritized as should-haves. Multi-language support, advanced filtering, 3D placement guidance, and family notifications were future enhancements. Diagnostic interpretation, AI recommendations, social features, and gamification were intentionally out of scope.

Accessibility Compliance

The MVP followed WCAG 2.1 AA principles through large text and controls, high contrast, clear hierarchy, and touch targets that support older adults using the app.

Simple Onboarding

The onboarding flow was reduced to four essential screens with visual guidance so patients could set up the device without processing unnecessary information.

Device Status and Bluetooth Pairing

The interface needed to confirm that the device was working, show battery and connection status, and guide users through BLE pairing with clear recovery when something went wrong.

Emergency Contact and Symptom Logging

Emergency contact access was kept quick and easy to configure, while symptom logging used simple categories and local storage for low-friction entry during monitoring.

Research Conclusion

The central takeaway was that patients needed reassurance, not more medical data. Across the research, the same needs kept appearing: the interface must be readable, users must be able to tell whether the sensor is working, setup must be guided, and diagnostic interpretation must stay out of the patient experience. These findings became the criteria for the next phase: a design system that makes accessibility measurable and a requirements set that turns anxiety and confusion into specific product decisions.

User Personas

Two primary user personas informed the design, representing the distinct needs of elderly patients and their healthcare providers.

Persona 1

Persona 1: Primary User

Represents elderly patients aged 65+ who prioritize device reassurance and simple operation over comprehensive medical data.

Persona 2

Persona 2: Secondary User

Healthcare professionals and caregivers who need diagnostic data access while ensuring elderly users have simplified, reassuring experiences.

Requirements Conclusion

The requirements phase converted broad concerns such as confusion and anxiety into testable product decisions. It gave the prototype a clear job: help a patient set up the sensor, confirm that it is working, and get help without exposing unnecessary medical complexity. The next phase tested whether those decisions worked when real users interacted with them.

Low-Fidelity Prototypes

I started with paper prototypes to test the structure before investing in high-fidelity screens. The onboarding flow was reduced from more than seven screens to four essential steps, accessibility options moved into setup, and the dashboard was stripped back to the information users needed most: device status, battery, connection, and reassurance.

User Testing on High-Fidelity Prototypes

I tested the main flows with older users using structured tasks, think-aloud feedback, observation, and short post-test interviews. The testing focused on onboarding, status checking, symptom logging, alerts, help, and sensor connection. This revealed where the accessibility decisions worked and where the language or hierarchy still created friction.

Design Iterations Based on Feedback

The design underwent six major iterations based on combined feedback from user testing, expert review, and internal stakeholder input. Each iteration was informed by real user behavior and expert guidance.

Iteration 1: Button Label Clarity

Iteration 1: Button Label Clarity

IssueTest users confused "Add Complaint" with complaining about the sensor itself.

ChangeRenamed it to "Log Symptom" and changed "Detected Activity" to "Activity History".

ImpactUsers immediately understood each button's purpose.

Why this mattered: Clear language is a WCAG 2.1 AA requirement for cognitive accessibility. Ambiguous labels create anxiety for elderly users who may already feel uncertain about technology.

Iteration 2: Icon Replacement

Iteration 2: Icon Replacement

IssuePlaceholder icons did not clearly communicate their functions.

ChangeReplaced unclear icons and added text labels to all navigation items.

ImpactFunctions became immediately recognizable.

Why this mattered: WCAG 2.1 AA requires icons to have text alternatives. Icons alone are ambiguous for users with cognitive impairments or low digital literacy.

Iteration 3: Help Button Addition

Iteration 3: Help Button Addition

IssueMildred could not find instructions when needed; Ben requested an easy Help button.

ChangeAdded a visible Help button to the main navigation.

ImpactUsers can access instructions without navigating through settings.

Why this mattered: Elderly users often experience anxiety when they can't find help. Reducing navigation depth to access support is critical for confidence and task completion.

Iteration 4: Battery Display De-emphasis

Iteration 4: Battery Display De-emphasis

IssueThe large battery indicator took too much space and drew attention away from actions.

ChangeReduced the battery to a small status indicator in the persistent status bar.

ImpactRefocused the home screen on actionable items and reduced visual clutter.

Why this mattered: Visual hierarchy is essential for users with reduced attention spans. Battery is secondary information; actions like recording and logging symptoms are primary tasks.

Iteration 5: Logbook Simplification

Iteration 5: Logbook Simplification

IssueSeparate alert and history tabs with filters made the logbook feel overcomplicated.

ChangeCombined both views into one list and removed unnecessary filtering.

ImpactCreated a cleaner, less technical interface that is easier to navigate.

Why this mattered: Cognitive load increases with each navigation decision. Reducing tabs and filters aligns with the research finding that users wanted simple answers, not complex data management.

High-Fidelity Prototypes

Designed high-fidelity prototypes based on feedback from low-fidelity testing. These detailed, interactive prototypes incorporated refined design elements and enhanced functionality, providing an accurate representation of the final product ready for user validation.

Final Design

Diplora key screens

Prototyping Conclusion

Testing confirmed that accessibility was more than a visual specification. Large targets and clear status feedback worked, but vague labels, hidden help, oversized battery information, and excessive scrolling still created uncertainty. The validated prototype balanced reassurance with restraint and gave implementation a focused, testable direction.

Implementation & Development

I moved into Agile development once the core direction had been validated. I translated the approved interface into a Flutter MVP, building reusable components and testing the experience on real devices as the product evolved. The implementation focused on a maintainable foundation rather than presenting unfinished clinical functionality as complete.

Development Approach

Work was organized into short sprints with planning, daily progress tracking, reviews, and retrospectives. The first sprint established the Flutter structure, design-system components, onboarding, and accessibility foundations. The following sprint focused on the dashboard, persistent sensor status, device pairing, emergency contact access, and navigation. Later work addressed BLE testing, logbook integration, accessibility refinement, performance, and bug fixing.

Tech Stack

  • Framework: Flutter (iOS & Android)
  • Language: Dart
  • Bluetooth: FlutterBluePlus BLE
  • State: BLoC pattern
  • Storage: Local storage (Supabase ready)

Technical Architecture

The app flow moves from onboarding and accessibility settings into device pairing, then into a dashboard with persistent battery, connection, and recording status. Symptoms are stored locally through the logbook and the structure is ready for Supabase integration. BLoC separates business logic from the UI, keeping the Flutter codebase maintainable and easier to extend.

Technical Challenges

Bluetooth required careful handling of scanning, connection states, sensor communication, and recovery when a device was not found. The interface also had to stay consistent with the approved designs while remaining responsive on older devices. The logbook introduced a second integration challenge: storing, editing, and retrieving symptom entries in a way that could later connect to the Supabase backend.

Quality Assurance

I used manual testing on real iOS and Android devices, accessibility checks with screen readers, performance checks on older hardware, and stakeholder acceptance testing. The definition of done included mentor review, no critical bugs in the tested flows, accessibility validation, and updated documentation. This process also exposed implementation issues that were not visible in the prototype, such as contrast and touch-target inconsistencies.

Known Limitations

The alert system uses simulated movement rather than final sensor movement detection, and the backend integration still needs to connect logging and alerts to the wider platform. ECG data volume can create lag on-device, the movement matrix from a previous intern is not yet integrated, and broader testing across iOS and Android devices is still recommended. The emergency-contact frontend is designed, but sending alerts requires backend support.

Implementation Conclusion

The planned MVP was completed as a functional proof of concept. The Diplora style guide was implemented in Flutter through reusable components, the accessibility standards were carried into code, and the BLoC-based structure supports future development. The result connects the tested design direction to a working application while making the remaining product and platform work explicit for the next team.

Final Working Demo

Walkthrough of the completed Diplora application and its core functionality, including real BLE sensor connection and scanning, movement visualization, symptom logging, activity alerts, and the persistent battery, connection, and recording status bar.