Business vs UX
The business wants a timer feature, but the users might say differently. What should I do?
Lutron app team is on a mission to raise the app rating on the App Store. One of the most requested on the App Store comment is a timer feature. Hence the business came to the UX team, seeking help for one.
However as the lead UX designer, I see the need to verify the need of timer and the challenge to build the timer feature on the app that still need some overhaul. After discussion, the business, development, and I aligned on following two goals.
Launch the timer feature and eliminate the user requests on the App Store.
Create a meaningful timer feature that can both improve users' everyday life and adapt to future Lutron app refresh.
From how users like the timer to
How users interact with smart home lighting
Two goals require different insights, hence I proposed to do a preliminary research with the following two directions. I collaborated with the data science team to narrow down the user set, and my UX researcher to conduct 6 1:1 interviews.
For Business Goal
Gain insights for timer. Understanding how users like their timer for home lighting will help me design a feature that can eliminate the requests on app store.
For UX Goal
Gain insights for home lighting. Understanding how users interact with smart lightings can how me situate the timer feature in the app. Further, the insight can shed light on some possible future app changes so I can design for scalability.
Insights for Timer
Timer is of perceived value. Users might not use it often, but believe it should be "easy and basic" to have.
Timer is primarily used for functional lighting. Users use timers in lighting like nightstands, doorway, basement, etc.
Flexibility to adjust the timer is preferred. How long the task takes changes frequently hence they want flexibility to timer.
Insights for Home Lighting
Users mentally separate lighting devices into ambient and functional based on their primary purpose.
Users decide whether to control lighting digitally or physically after calculating how much effort is required (location/current activity)
Users set up lighting automation and control single device to not "mess up" with the schedules.
Developing a timer feature is harder than it seems. What are some discussions the team had before doing it?
Not everyone on the team is aware of how much effort the development takes and how the user insights can hint the design of the feature. Hence I hosted a brainstorming session with the product owner, developing team, and visual design to empathize them with the users and discuss some questions that are critical to the feature:
How important is the timer feature for Lutron App?
The solution to this influences how prioritized the timer should be in the app. Contrary to its popularity (the most requested feature on the App Store), users don't need it as often but think it is basic.
The team aligned that the timer doesn't need to be highly prioritized but needs to be be easily found when users need it.
What is Lutron App’s place in users’ smart home lighting experience?
Users don't always control lighting with the app. Instead, users use the app to set up rules for home lighting.This triggered the discussion of "existential crisis" of the Lutron app.
The team started to talk about a future app revamp. I also started to create a more fleshed out product strategy and include more business stakeholders in the discussion.
The team has some alignments on the discussions. Doubled with the insights I gain from the preliminary research, I translated the alignments into the following actionable decisions.
Locate the timer feature at the second level of the information architecture, so its not prioritized but still discoverable.
Set to Device
Have the timer tie to individual device instead of the scheduling system, so it will not complicate the future app refresh.
Make sure the element requirements are well documented as timer feature has granular time-setting elements that are new to the design system.
Look at the timer feature from user POV.
Set Up the Timer for a Device
Users go to the edit of the device and tap on the timer list item. After turning on the timer, users can put in the time and will see a short description informing them what will happen with this feature setup.
Why the radio button?
There are two layers for the timer feature: set the timer up and then turn the tuner on. In current Lutron Design System toggle means "turning on/off." Hence I introduced a radio button for "setting it up".
Is one line of instruction enough?
After 6 rounds of user testing, most users can immediately understand a timer and no user read the text. For those who didnt understand, they mentioned a simple instruction is informative enough too.
Quick, Temporary On/Off
For devices that have timer set up, a toggle to quickly turn the timer on/off will be shown on the remote control pop-over of the device.
Why do users need a temporary on/off when they can just turn the timer off?
Users want to have flexibility in controlling their timer. That means they do not want to "mess up" with their setting. The temporary on/off allows users to control the timer without worries.
Why have the toggle on the remote control pop-over?
The pop-up remote works as a digital remote for the devices. It is also the first place users will get to when controlling their lighting. Having the toggle here can grant users intuitive and quick control over the timer.
Notify Me Toggle
The toggle allows users to choose if they want the app to notify them before turning off the light. In the notification, users can dismiss the notice or repeat the timer.
Users get confused when the lights turn off themselves as users might forget the timer is on. With the notification, users can be informed.
Why not making notification a default?
Notifications prevent the timer from confusing users' spatial experience. However, the last thing we want is another digital exhaustion. Having it optional allows users to keep their balance.
Why not allow users to put in how long before they want to be notified?
Allowing users to put in a specific time requires more mental capacity that might deter them from using this small delighter.
Evaluate if the final product solved the goals and fit users behaviors.
The business goal requires the feature to be discoverable and usable. The UX goal requires the design to be intuitive to users home lighting experience. To make sure both are fulfilled, I came up with the following 3 rationales to evaluate the design:
Users should be able to finish what they want quick and easy.
Users should feel confident about what are they doing.
Users don't experience unwanted and shocking effects in their spatial experience.
Screen Flow Evaluation
Easy to discover
Intuitively know where is the timer feature
Explain the effect of timer feature
Choose to be notified when timer is triggered
Turn the timer off without messing up with the setting
Timer icon shown on the toggle
Lights fade instead of suddenly turn off
Link to Physical Control
Trigger timer both through app and physical switch
Understand why the light is turned off
What are some other impacts the project posed to the product and the team?
Discussion of the app's mission
What's the next step for the Lutron app after raising the rating on the app store? From the research, we saw that current Lutron app structure focuses too much on daily lighting control, which isn't necessarily the users' priority. It led to a more extensive discussion of the app's mission and how it can blend with the business goals.
Improvement for Current Flow
I spotted some usability issues in the current flows from the research. The team will continue improving the Lutron app's flows, like tabbed design, add-device flow, multi-home system, etc.
Embedding UX in Product team
The project showed a successful collaboration between the developing, business, and UX teams. The management decided to experiment having a UX person embedded in one product team instead of what Lutron used to do, assigning project requirements to the UX team.