Embedded Files
About settings for the Google Home app: So...what's tricky about settings for the connected home?
About settings for the Google Home app: So...what's tricky about settings for the connected home?
I'd say imagine the settings you'd typically need for a user account, add the settings for a smart device, the settings for a home (a collection of those devices), then throw on an app for managing and staying connected to your device. Examples of these settings types are:
I'd say imagine the settings you'd typically need for a user account, add the settings for a smart device, the settings for a home (a collection of those devices), then throw on an app for managing and staying connected to your device. Examples of these settings types are:
Device: What language does my thermostat use?
Account: What voice does the Assistant use when it recognizes me?
Home: What's the home address? What household automations are in this home (that members can add/edit/delete)?
App: What Wi-Fi credentials are saved with this app instance (used to make device setup faster)?
Now consider the combinations of settings you also need:
Now consider the combinations of settings you also need:
Account + device: Do my phone calls ring on this speaker?
Account + home: Who are members of the home?
Account + Account: What music accounts do I have?
Home + device: Is this speaker used for presence sensing (detecting occupancy)?
Home + account + device: Is my phone used for presence sensing for this home?
Now multiply all that by dozens of devices,ย in 1 to 2 homes, each home shared with up to 6 people who have their own settings...using multiple phones, tablets, and wearables that are sometimes personal, sometime communal. Sometimes setting A in this screen conflicts with setting B in another screen...
The Google Home settings framework aims to make it possible for users to use ever-more powerful features and devices, whether they're new to tech, or an early adopter.
The Google Home settings framework aims to make it possible for users to use ever-more powerful features and devices, whether they're new to tech, or an early adopter.
The problem
The problem
Settings were complicatedโฆand growing
Settings were complicatedโฆand growing
Device settings in particular had grown organically over the years (see Assistant speaker settings here to the right).
In a long, scrolling list, users couldn't easily find, or re-find settings
Many devices had non-intuitive settings groupings
There wasn't enough visual hierarchy
The single-screen approach would not scale to more complex devices like thermostats, cameras, and doorbells
The Home settings screen had also grown organically into a long, scrolling list
The Home settings screen had also grown organically into a long, scrolling list
Not enough visual hierarchy (the delete-home action looks like another setting)
A cryptic "More settings" item
Inconsistent hierarchy that prioritized more rarely used home information & room settings above more-used service settings (Music, Video, etc.)
Lack of coverage of key settings: Nest Aware subscription features, Works with Google services/devices, and Communications settings
Lack of visibility of the Nest Wifi settings in the main screen of the app
My contributions
My contributions
UX strategy
UX/UI design
UX settings framework guidelines
UX Co-writer
The team
The team
1 lead UXD (myself)
1 UX researcher
25% time UX writer
1 product manager
3โ6 engineers
Partners
Partners
9 device verticals (PM, UX, Eng)
Impact
Impact
I scaled long, organically-growing settings screens to a modular information architecture.
This allowed the Google Home app to also support thermostats, cameras, and any variety of connected device.
The tech press took note, despite a quiet launch with no promotion
Launch dates
Launch dates
2020 through 2021
The process
The process
๐คฟ Immersion
๐คฟ Immersion
My PM partner & I immersed ourselves in all device settings, and got familiar with each item in home settings
We then formulated an overall framework with consistent information architecture
๐ค Roadshow & discussion
๐ค Roadshow & discussion
My PM partner and I met in multiple small groups with all device verticals
This was necessary to learn partners' needs
We discussed when the framework needed to accommodate partners' needs or when partners should use the framework's components and patterns
๐ฌ Research & iteration
๐ฌ Research & iteration
We didn't have data to settle a difference of opinion on grouped settings, so a cafe study clarified which approach to take
Vertical teams also conducted their own research on their settings as part of their normal research sessions
๐ Specs & guidelines
๐ Specs & guidelines
Once general alignment was in place, UX designers finalized settings specs
I also found a need for a settings framework UX guidelines and established a guidelines document
Navigating challenges:
Alignment on grouped device settings
Navigating challenges:
Alignment on grouped device settings
While some partner teams desperately needed grouped device settings, some leads and partners had concerns about usability
While some partner teams desperately needed grouped device settings, some leads and partners had concerns about usability
The camera team felt users would have an easier time finding settings if they were exposed in a single list:
The camera team felt users would have an easier time finding settings if they were exposed in a single list:
Research clarified that grouped settings was the right approach
Research clarified that grouped settings was the right approach
A UX research study showed that grouped settings were more approachable, more learnable, more preferred by participants:
A UX research study showed that grouped settings were more approachable, more learnable, more preferred by participants:
- 85% (17 out of 20) preferred grouped settings
- 100% (8 out of 8) of camera owners did as well
With this data, all parties agreed that we should continue with the grouped approach for device settings.
Navigating challenges:
Aligning multiple cross-functional partner teams
Navigating challenges:
Aligning multiple cross-functional partner teams
How did we get alignment with UX, product management, and engineering from six product verticals? A roadshow with small meetings with partner teams.
How did we get alignment with UX, product management, and engineering from six product verticals? A roadshow with small meetings with partner teams.
Smaller meetings with every single team communicated the needs and the timelines, and allowed everyone to collaborate on the framework.
Smaller meetings with every single team communicated the needs and the timelines, and allowed everyone to collaborate on the framework.
A slide from the roadshow presentation:
A slide from the roadshow presentation:
Shared resources like an information architecture spreadsheet helped teams stay aligned while accommodating their specific needs.
Shared resources like an information architecture spreadsheet helped teams stay aligned while accommodating their specific needs.
One of many information architecture spreadsheets:
One of many information architecture spreadsheets:
Outcomes & learnings
Outcomes & learnings
Outcomes
Outcomes
Normally, we would have had pre- and post-launch metrics, or pre- and post-launch UXR.
But we were without a product manager / without a full-time product manager for portions of the project so this legwork slipped by us.
We also did not have research resources to run comparison usability testing.
Alternative outcomes :)
Alternative outcomes :)
The tech press took note (see the quotes distributed throughout), despite a quiet launch with no promotion.
While not an entirely measurable metric, it's noteworthy when unannounced features are noticed and received positively.
Learnings
Learnings
Make sure to include pre-and post-metrics in all PRDs.
Make sure to request pre- and post-launch research resources as well.
To create awareness and perhaps avoid resource shortfalls in the future, escalate and inform UX leads when we're short on research resources.
Outcomes for device settings
Outcomes for device settings
The device settings information architecture launched in November 2020
The device settings information architecture launched in November 2020
We addressed the original problems:
We addressed the original problems:
We grouped settings, so users could find and re-find settings
We established more intuitive groupings
We created a visual hierarchy between settings items vs. actions
We applied a consistent information architecture to all device types, including thermostats, cameras, and doorbells
Outcomes for structure settings
Outcomes for structure settings
The structure settings information architecture update launched in May 2020
The structure settings information architecture update launched in May 2020
We addressed the original problems:
We addressed the original problems:
We created a visual hierarchy so the delete-home action no longer looked like another setting
We removed the cryptic "More settings" item
We created a secondary page for Home information (Home nickname, Home address) as well as another secondary page for Rooms & groups. This allowed us to move more-used service settings (Music, Video, etc.) much higher in the list.
We added entrypoints to Nest Aware subscription features, Works with Google linking, and Communications settings
We added an entrypoint for Nest Wifi settings
Challenges & how we addressed them
Challenges & how we addressed them
Conflicting needs between usability (good to show fewer items) and partner contracts (which called for adding more items)
We added the items with a future commitment to consolidate items once short-term needs expired
All communication and service settings are in the separate Assistant app
We decided it was more simple to avoid highlighting what settings are in Home app and what settings are in Assistant app. Users just want to get to settings that affect the given home; they don't care which app they're handled in.
Page updated
Google Sites
Report abuse