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 Status
Problem
Sensor Status Screen is accessible via the primary navigation bar and serves as the central hub for all sensor-related information.
Unlike the Sensors Screen in MS 2.0, which emphasised dynamic battery levels due to the need for daily charging, MS 3.0 shifts the focus to the sensor wear cycle and various error states.
Brief
Create a range of Sensor Screen states, along with corresponding icons and banners, to represent each sensor status depicted in the state machine diagram below.
STATE MACHINE
The app performs a series of checks, whether it's open or running in the background, which determines the order in which error states appear on the Sensors Screen. It also checks whether the user is currently in a wear cycle or on a break. These states are displayed as banners when the user is not actively viewing the Sensors Screen.
.png)
Analysis of the Problem
SENSOR SCREEN
I designed a UI that included all the information I believed the user would need. Feedback from other designers was as follows:
-
Bottom message isn't prominent enough
-
Break states resemble a modal, which may cause confusion
.png)
The battery information displayed during an active wear cycle needed to be separated, as it was presenting two distinct pieces of information:
-
Sensor connection status
-
Battery level (e.g., Battery level = XX%)
Note: It was important to display both pieces of information, as studies from MS 2.0 showed that users often assumed the sensors weren’t connected or functioning unless the app explicitly stated otherwise.
SENSOR ICONS
The sensor icons are nested within the top global navigation bar and become visible when the user is not on the Sensor screen. Each state shown in the state machine requires an associated sensor icon.
The issue with the first round of designs was that the icon didn’t clearly resemble the sensor. Unlike MS 2.0, the sensor outline lacked enough distinctiveness. To address this, I put together a deck to explain the problem to the team and propose a solution.
I also learned after the first round of designs that the firmware would not support displaying a dynamic battery level, only a low battery state (10% or under).
%201.png)
BREAK STATE
Another issue I noticed during testing was that the sensor disappeared during a wear cycle break. This raised concerns that users might interpret it as the sensors not functioning properly or the battery being depleted.
The challenge was to design an icon that clearly represented a wear cycle break, without causing confusion that the sensors were either broken or out of battery.
Final Design
The conclusion was a set of icons that more closely resembled the sensor outlines and clearly communicated the various states.
A banner (shown on the right) was designed to be used only when the user needed to be alerted to a state change requiring immediate action. Selecting either the CTA or icon on the banner directs the user to the Sensor Screen.
UPDATES TO THE SENSOR SCREEN
-
The screen title and state description were enlarged and positioned closer to the contextual image
-
Messaging was clarified across all screens. For example, 'Make sure your sensors are in range before proceeding was revised to 'Make sure your sensors are near you'
-
The bottom message, including the CTA, was placed inside a container for better organisation
-
Break state content was moved to a lighter background, providing clearer contrast with the wear cycle and error states
