Recognition over recall. Recommended journey page
was designed to better visualise a journey.
Forms became multiple choice.
Progress bar was added to
show transparency of system
structure.
Sensor Wear Cycles
MotionSense app and wearable
MotionSense (MS) is a wearable monitoring device designed to assist users in their knee replacement recovery. It uses wearable sensors to track key data, which is then sent directly to the user’s care team for remote monitoring and support.
MS Tracks
-
Knee range of motion (RoM)
-
Daily steps
-
Activity time
-
Prescribed exercise completion
-
Pain scores
-
Survey responses
Patient wearing MotionSense 3.0 sensors and patches
Problem
Previous versions of MotionSense had single day patch replacement cycles, this was a key factor in low patient engagement.
Brief
Design in-app guidance to support patients using MotionSense 3.0's updated patch system.
Analysis of the Problem
Longitudinal Study
We ran a study to test the new attachment system. We instructed 14 days wearing of the patches. The study included 18 participants.
Participant wearing patches and sensor block modals
Participants normally removed them after about 12 days in first wear cycle, so we decided that 12 days was the optimal number of days to wear the patches. Not to go to 14 days, which was more intuitive but meant we would more likely lose sensors. If we wanted to go to down to 7 days, this might be intuitive but it would use more patches.
We also learnt that skin irritation effected 2 participants and could happen at any stage. But we were concerned people would want breaks, so I proposed breaks in some of the design concepts.
Understanding the Constraints
During the discovery and concept phase, it was crucial to consider and balance the following constraints:
-
16 days of wear per month: This was the qualification criteria for billing remote user monitoring reimbursement and a key component of the business model.
-
Tech feasibility (low developer effort): We had set a tight deadline for the MVP, so we needed to keep development effort manageable.
-
Good in-app guidance: The app needed to effectively guide users through the wear cycles while keeping them engaged.
-
Preserve patches: Patches were costly to replace, so we aimed to minimise wastage.
-
Avoid lost sensors: Sensors were even more expensive to replace, requiring us to ensure they were properly secured.
-
Maximise battery life: We wanted to optimise for the longest possible usage and data collection from the sensors.
.png)
Pre and Post Surgery
We (myself and stakeholders) agreed early on that the system should encourage users to onboard before surgery, as they are generally more compliant when experiencing less pain. However, it must also support post-surgery onboarding. Ideally, users would complete a wear cycle prior to surgery to establish baseline data for comparison with their final wear cycle.
Separately, I recommended that the app behave differently immediately after surgery compared to later recovery cycles. At this crucial stage, users often experience low energy due to poor sleep and significantly higher pain levels, which can reduce motivation. Therefore, both the messaging and timing of notifications should be tailored differently for the first post-surgery WC, distinct from subsequent cycles. However, implementing this approach would likely increase development costs.
Design Concepts
Early Proposal
I questioned whether the app should prompt users to take breaks at all, since that could discourage continued use of the system. From a UX design standpoint, if 90% of users aren’t likely to experience skin irritation, it might be better to let them decide on their own when to remove the patches, rather than having the app suggest stopping. This thinking influenced later concepts, where the app encouraged users to start a new wear cycle instead of taking a break.
Concept 1: 12 Day Counter
The green highlights indicate the happy paths associated with Concept 1. I proposed a timer that would begin as soon as a user starts a wear cycle, triggering a notification after 12 days to prompt a wear cycle break. I also proposed adding an option for users to choose the number of days (1–3) before the app reminds them to begin a new wear cycle.
In total, I mapped out around 10 happy and unhappy paths.
.png)
Happy Path 4: Post Surgery, User Takes Break
In this pathway a user decides not to start a new WC because of skin irritation. They are prompted by the app to capture a photo of the skin irritation (this concept could inform us of other reasons why users might be taking breaks).
Then, the user needs to input the number of days (1-3) before the app prompts them to start a new WC.
Unhappy Path 4.1: Break Overrunning
This unhappy pathway demonstrates where a user would dismisses the in-app notification to start a new WC. They are then blocked from starting an Exercise Session. A user can start a new WC directly from the modal that's displayed upon selecting an Exercise Session.
How it Measured
As part of the stakeholder management, I used a decision matrix throughout, to ensure transparency in trade-off decisions.
The full development effort for Concept 1 was outlined during the initial stakeholder meeting I conducted. This graph served as a useful tool to capture how we evaluated each concept against the constraints discussed above.
Concept 2: Fewer Guide Rails
I removed most of the high-effort features from Concept 1 to reduce developer workload. Concept 2 took a more minimal approach, allowing users to wear the sensors until they naturally fell off or became loose, meaning there was no timer tracking days worn. Instead, the app would detect when the sensors were removed or had detached from the leg. While this was a bare-bones solution, it was significantly easier to implement.
Concept 3: Least Mental Effort
I suggested minimising the need for users to interact with the sensors after surgery, for example, avoiding the need to manually turn them back on. This was based on concerns within the design team that users might not remember or know how to reactivate the sensors, even with instructions. I also proposed allowing multiple wear cycles before surgery to give users more flexibility. These ideas aimed to reduce the overall mental load on users.
However, this concept was eventually considered too risky, as it significantly impacted battery life. According to calculations from the firmware team, it reduced the total available battery life from approximately 90 days (Concept 1) to just 74 days (Concept 3).
Final Design
To keep development simple, optional features like customised breaks were dropped. Instead, the focus was on clear guidance and ensuring patients wore patches at least 16 days each month to meet care and billing requirements.
The implementation focused on designing a system that offers users choices for breaks and displays different language and workflows based on the phase of their journey.
