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.
MotionSense 3.0 sensors and patches
Analysis of the Problem
LONGITUDINAL STUDY
We did 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 concepts below.
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
Some stakeholders proposed that users complete a wear cycle before surgery to collect comparative data for their final wear cycle.
In addition, I envisioned a distinct first post-surgery wear cycle, followed by subsequent cycles. This was because the app would need to make a greater effort to re-engage the user after knee surgery, compared to later post-surgery cycles. As a result, the messaging and timing of notifications would need to differ between the initial and subsequent post-surgery wear cycles.
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
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.
.png)
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
The final design and build, more closely aligned with Concept 1. However, it excluded certain features—such as the ability to log skin irritation (as clinicians were unlikely to review this) and the option for users to specify the length of their break.
It was agreed that this approach was both cost-effective in terms of technology and sufficient to encourage users to achieve 16 or more days of sensor wear per month.
.png)
SENSORS GOING UNALIGNED
During internal testing, the app was incorrectly detecting that sensors had been removed when they hadn't. This was due to sensors becoming unaligned from certain positions—like crossing legs or movements during sleep—stemming from a firmware issue.
This problem would likely be more pronounced for older users, particularly those in the MS demographic, who often have looser skin. From a UX standpoint, it was frustrating for users to be forced through the end-of-wear-cycle flow unnecessarily. Introducing the ability to realign sensors and resume an existing wear cycle would be a meaningful improvement.
SOLUTION
An additional push notification and in-app message were introduced to appear whenever the app detected that the sensors were not aligned with the leg. If the user selected 'Yes' on the in-app prompt, the app would ignore the unaligned flag and allow them to remain in their current wear cycle.
The messaging within this in-app notification was a critical element to get right. The question needed to clearly and concisely cover two possible scenarios:
- The sensors had fallen off the user’s leg
- The sensors had been intentionally removed by the user
