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.
Firmware Update
Background
For an app with a wearable, MotionSense needed a way to push firmware updates to the user. We agreed in an early decomposition meeting, that we must not have multiple users using multiple firmware versions. A new available update would need to block a user from a sensor dependent app feature until that update has been installed.
Problem
New firmware (FW) versions were released every three months for installation via the app. We aimed to avoid a scenario where multiple users were operating on different FW versions, as this could lead to inconsistencies and potential issues with performance or support.
Brief
Design a workflow which notifies a user of an available FW update and provides onward navigation to the core FW update flow.
Analysis of the Problem
I identified several in-app flows that would be impacted—specific points where the app would need to check for available firmware updates and provide navigation to the core FW update flow.
These in-app flows were:
-
App Installed First Time
-
After Login
-
New Wear Cycle
-
Connect Sensors
-
New Install
.png)
Final Design
AFTER LOGIN
The app checks for an available firmware update at login. If an update is available, both an in-app banner and notification are displayed, both of which can be dismissed.
If the user attempts to start a sensor-dependent task (e.g., an Exercise Session), the app presents a blocking modal informing them that a firmware update is required before they can proceed.
On the Sensors Screen, a contextual message is shown if a firmware update is available. This message includes a direct link to the anchor screen, which provides key information:
-
The benefits of the firmware update
-
Reassurance that sensors should remain attached during the update (assuming they are already in place)
-
The estimated update time
The flow was intentionally designed to only block sensor-dependent tasks. Users could still complete non-sensor tasks, such as Rate Your Pain, without needing to update the firmware.
.png)
APP INSTALLED FIRST TIME
The key difference during first install was that the app could check for a firmware update immediately upon connecting the sensors. If an update was available, the user would be directed to the anchor screen, where messaging explained that a firmware update was required to complete the sensor connection process, along with how long the update would take.
In this scenario, it made sense to enforce the update, as users had likely already set aside time to complete onboarding, making it a natural point to introduce the update without disrupting their experience later on.
.png)
SENSOR FW CORE WORKFLOW
The update flow needed a progress indicator, since the process took a few minutes. I designed a sensor-inspired visual, nesting the progress bar and key instructions in a single message card to keep everything clear and focused for the user.
