Child Lock feature on App and device
Discovery, and delivery - UI/UX
As one of the most requested features by our community, we decided to evaluate the introduction of any kind of Child lock for the devices mounted on the radiator.
​
I, as a hardware UX designer, worked together with the Core App team, to find the best solution for all touch points of the service we offer. We followed a lean path that pointed us in the easiest but most effective lean direction.
Main problem
Pictures tell more than a thousand words, and the below pictures are what we got from our users, how they have to secure the device to avoid children changing temperature is for sure a critical problem we needed to attack.
Problem Framing
We framed all problems coming from our users, different complaints, and some extra competitors' research. We added our assumptions and the technical constraints and created a matrix where we were able to see all the topics at once and group them.
User Stories
-
As a user, I want to be able to lock/unlock the SRT (mainly via the app), so that, children cannot modify temperature settings while playing with it.
-
As a user, I want to be able to unlock the SRT device when the connection is lost, so that, I’m able to manually control my heating, in case my app is not working.
-
As a user, I want to check (on the app or device) when another member of my household locks/unlocks an SRT, so that, I know which SRT is manually working/not working.
Proposals
1
App
After some user interviews, our proposal includes a way to turn on/off the child lock from each of your devices.
Also, evaluate visualizing the status per device in without too many click/efforts on the app.
2
Device
After watching users confused about the device not working (locked), we saw the need to visualize the device lock status.
Evaluate later, adding a way to (un)lock the device. This is challenging because of hardware limitations on the devices.
3
Tracking
We suggested also keeping track of the behavior of users, to check satisfaction and ease of use. The plan is to track tickets, online comments, and general complaints for about 3 months after the feature launch.
Implementation
User Testing
We showed the app and the device with Child Lock and guided them for our purposes.
All the participants were interested in this feature being launched. Here are some observations:
→ Where do users expect to find and act on child lock (App vs Hardware)
No significant preference in looking for a lock feature on the app rather than hardware.
App slightly favorite, more users are more app-users in general.
→ What users initially expect to lock (Room vs Device)
No significant preference between the first touch point.
The expectation of locking single devices is stronger than the whole room.
There is a strong connection between device and room, besides the actual number of devices in a room.
Users say "room" meaning "device".
→ Where the user expects to find child lock in-app ( Home screen vs Settings )
The home screen is the baseline for all needs, Settings is used mostly by “power users”.
Settings need some scrolling in between skills before actually getting to Rooms & Devices, users mentioned it often.
→ How SRT status is communicated between same household users
There is no awareness of SRT status from one user to another in the same household. Both support hardware and app.
Secondary users or no-app users cannot easily understand if an SRT is locked by the other user/s.
→ Child Lock is often a long-term action
Users said the lock on the device would have been “forever”. This means most users don’t expect to lock or unlock that often their devices.
​
​
After the user feedback, we improved the status visualization on a previous screen of the app, to check easier, without digging too much into settings. We also added a caption explaining the feature.
Learnings
Synchronizing apps and devices requires more planning than a single touch point, it also requires perfect communication between teams and aligned focuses.
​
User testing with live interviews is the best tool if you are testing qualitative features and synchronizing changes between app and device.
​
Listen to your users. The project was not for our typical techy users, but for children, they are always right!