Just a moment.
Stadia Bluetooth
Google, Stadia — January 2023
My Role
UX Lead — Interaction Design, Visual Design, User Flows, Rapid Prototyping
Austin Fisher, UXW
Dean Whillier, UXE
Bryan Coutch, SWE
Ben Whittaker, SWE
Christina Lee, PM
Timeline & Status
2 Months, Launched in January 2023
Following the announcement of Stadia’s shutdown, questions remained on what would happen with the platform’s Wi-Fi proprietary controller — whether they could still be used wirelessly, or become e-waste.

I led the end-to-end design direction of the web experience for enabling Bluetooth on the controllers and played a pivotal role in defining the update process.

The website's launch was met with outstanding public sentiment from the community and publications, alongside 1 million+ successfully updated controllers.
An end-to-end update experience for enabling Bluetooth on Stadia Controllers to preserve their wireless functionality post-sunset.
0.1 Homepage motion concept.
0.2 Sample UI components.
0.3 Mobile homepage.
0.4Core component catalogue.
0.5 Illustrations showcase.
An opportunity to go out with a bang.
The message was loud and clear.
Shown in Figures 1.0 and 1.1, enabling Bluetooth was hands down the largest request from the community. Above all else, it was the right thing to do, and an opportunity to overdeliver.
1.0 Press & community requests.
1.1Unfaithful sentiment.
This wasn't going to be your typical firmware update.
A pile-up of constraints.
Controller firmware updates were usually delivered quietly over-the-air when users connected to Stadia. However, because the platform was shutting down, that approach was infeasible.

The decision was made to launch a first-party website to deliver the update — which itself was met with a myriad of confounding constraints:
A two month deadline, because we had to launch before the sunset date.
Hardware access nuances. The controller had to be put into a "boot menu" mode.
Clunky by design. Hardware and security access were never meant to be user-facing.
Limited to a static website. No way to dynamically verify controller input during update process.
Take an otherwise highly unorthodox update process and package it into a website to be as intuitive, error-free, and desirable as possible.
North Star design principles:
Optimize for Clarity
Clear, informative, and concise instructions.
Proactive Feedback
Anticipate and communicate progress and errors.
Product Excellence
Overdeliver on user expectations with design.
2.0 Project process within timeline.
The backbone of the project.
Well... it's a start...
The hardware team provided me with a list of mandatory update instructions on a static website which included an unorthodox Chrome dialog interaction (Figure 3.0).
3.0 Representation of first prototype & Chrome dialog.
Finding structure amidst the chaos.
To make sense of an otherwise unconventional set of instructions, I started by exploring ways to foster a perceived sense of progress.

Shown in Figure 3.1, categorizing instructions into four stages was done to better align with what was actually happening to the controller, and to reduce the cognitive load of presenting the instructions all at once.

To better cater to a general audience, overly-technical terms were revised.
3.1 First prototype flow, categorized.
Pinpointing the issues.
Structuring the process also aided with identifying issues between micro-actions. These issues mainly included hardware considerations and potential moments of confusion.
3.2 First prototype flow, categorized.
Controller had to be off, no “visible” hardware feedback from the status light
Chrome dialog interaction needed to be performed twice
A controller out of battery — or is it off?
A cable that doesn't support data transfer
No validation if action was performed successfully nor indication for progression
"Download" and "Install" phases were identical
Getting the quick fixes in.
Pinpointing the location of these issues enabled me to tackle them head on with fairly fundamental amendments (Figure 3.3) — with the objective of further fostering a greater perception of progression.
3.3 First prototype flow, categorized.
Pair text instructions with clear product illustrations and indicate LEDs should be off
Present success message and allow user to proceed to next step — fostering awareness of progression
Partnered with UXW to draft overt copy
Is there a way to surface hardware errors before unlocking — with a static solution?
Is there a way to verify if step was done correctly — with a static solution?
The Chrome dialog — once a constraint, now a breakthrough.
As I was dry-running the update process, I had noticed that the controller would appear as a different name every time the dialog was opened.
By matching up the controller name with its "hardware mode" and validating that pair with the update stages, we created a fail-safe.
3.4Chrome dialog fail-safe logic
More is less — verify.
I doubled down on the fail-safe functionality and worked with our engineering team to introduce a preliminary verification phase, cleverly dubbed "Verify" (Figure 3.5).

By asking users to verify prior to starting the update, we're able to one, surface hardware issues right away, and two, direct users back to where they left off if an interruption occured.

In this sense, the update process would always be closed, rendering it impossible to brick a controller.

There was also the added benefit of passively familiarizing users to the Chrome dialog interation earlier.
New changes only
3.5Final update flow
Straight to the point, consistent, and scannable.
Keepin' it old school — responsive layout grids.
A standard set of layout grids (Figure 4.0), defined by desktop-based breakpoints, was critical in ensuring the team could design and build with velocity and consistency.
4.0 Responsive layout grids.
Boilerplate layout — A question of readability vs. glanceability.
The first iteration (Figure 4.1) was an attempt at amplifying the perception of progression, further mitigating errors, and trying to foster motivation by structuring the layout as an overall picture — placing high emphasis on textual instructions supported by natural reading behaviour.

However, there was an initial impression of unnecessary distraction and low emphasis on the current task at hand that prompted a second iteration (Figure 4.2) — placing glanceable illustrations at the forefront.

One layout wasn't necessarily better than the other per se, but reducing the amount of content seen at any given moment helped reduce potential for error.

Ultimately the second iteration was chosen because of a reduced engineering overhead and layout simplicity.
User perception overlay
4.1Progress-driven approach
Focus is put on the process as a whole — motivates users to complete the update
Textual instructions first, illustrations become supplementary elements
Greater readibility — improved instruction retention, reduced confusion
User perception overlay
4.2Action-driven approach
Focus is put on the current action at hand — one thing at a time, less distraction
Illustrations become imperative to the experience and drives greater tactility
Greater scannability — just look and do, read if needed
The Chrome dialog layout — breaking the rhythm.
The primary CTA was relocated to help bring focus to initiating the Chrome dialog interaction.

Disabling instinctive progression further pushed the necessity of the interaction.
4.3 Chrome Dialog logic.
It didn't have to feel like a static website.
Process of unlocking — failure prevention vs. ease of use.
Unlocking the controller to access the “boot menu” had inherently clunky origins by design. My initial approach was focused on failure prevention, by walking users through each micro-action one after another.

Though it appeared intuitive in theory, it was actually unnecessarily cumbersome in physical practice with actual hardware (Figure 5.0).

I made the pivot to an approach more conscious of hardware interactions and ease of use (Figure 5.1).
5.0 Step-by-step with checkbox.
Ensured that users carefully read, follow, and verify completion of the instructions
One thing at a time — low cognitive load
A much longer process — perhaps unnecessary
Having to go back and forth between controller and mouse/touchpad
5.1Instruction cards.
A single page, no extra actions
Decent cognitive load — so long as instructions were formatted and structured well
Fully reliant on user-descretion to follow instructions carefully
Understanding the need for tactility.
The decision to display unlocking instructions with cards rather than a list was made to reduce the feeling of reading. (Figure 5.2).

Because this step was highly tactile, I wanted the interaction to be naturally propelled by high glanceability with illustrations rather than text.
5.2Unlocking instructions, list vs. cards.
"Wait, was something actually downloaded?"
In the back-end, downloading the update took a fraction of a second, which in theory was a good thing. However, seeing it on the screen (Figure 5.3) gave the impression of abruptness, and ultimately distrust that anything was actually downloaded.

I worked with our engineering team to implement a deliberate loading delay (Figure 5.4) to convey the perception that the website was working to download the update.
5.3Without artificial loading.
No time wasted, true to what's happening
Potential of user doubt and distrust
5.4With artificial loading.
Feedback to manage expectation and build anticipation — it just feels like it worked
A couple extra seconds to wait
Unmistakeably Stadia, undeniably Google.
Combining the old and new.
At Google’s scale of design, it would be redundant to create an entirely new design system for this project.

Instead, custom components were designed on a per-need basis, and maximized the use of atomic Material Design characteristics.

Though, there was room for some fun! In the spirit of being forward-looking while also paying homage to the past, I fused together aspects of Material Design with Stadia’s design system (Figure 6.0).
6.0Modified button component.
Cards — versatile and responsive.
The card component was highly-critical from a content-organization perspective. It was designed to prioritize readability while accounting for responsiveness, flexibility, and i18n.

I put a lot of emphasis on redlining every property (structure, internal padding, colour tokens, etc.) to ensure a smooth design-to-engineering handoff.

It was also an opportunity to leverage Figma’s new component properties functionalities to greatly speed up collaboration with UXW (Figure 6.1 & 6.2).
Hide specs
6.1Default card component.
6.2 Instruction card variant.
Dialogs — valuably interruptive.
In the rare instance that something goes wrong, it was of utmost priority to communicate it clearly and suggest direct solutions.

Center-aligned iconography and headings were used in tandem with subtle motion design to be more interruptive and draw greater attention (Figure 6.3).
6.3 Error dialog interactions
Stepper — a visual method for passive orientation.
Though small, it functioned to accurately represent the update flow and offer users with visual indication for progress and passive wayfinding.

As a component that neither existed within Material Design or Stadia’s design system, every atomic element and their combined states were intricately defined.
6.4Stepper component development.
Illustrations — recognizing but not overemphasizing the industrial design.
The design direction of the illustrations focused on prioritizing scannability and interpretation of relative button positioning.

This made the linework approach more favourable as actions could easily take priority over the controller itself (Figure 6.5).

It also aligned greater with artifacts within Stadia's existing visual design ecosystem, such as those found on the controller's user manual (Figure 6.6).
Show indicators
6.5Illustration style direction
6.6User manual.
Manually redrawing vector assets enabled greater control over colour, button sizing, and overall visual manipulation (Figures 6.7 and 6.8).
Hide annotations
6.7Status & state illustrations.
The website's backdrop was a nod to Stadia's last UI update — featuring the Stadia emblem as a clipping mask against a blurred ellipse (Figure 6.9).
6.9Website backdrop logic.
I collaborated closely with UXE to design and implement a concentric ring motion concept, representative of Bluetooth connectivity (Figure 6.10).

By only adjusting fundamental size and colour properties, the animation was lightweight and implementable purely with CSS transform.
6.10 Concentric ring motion concept.
An effortless experience
You kinda just click through it.
For the most part, the firmware update process from start to end should take a user no longer than a minute — two tops (Figure 7.0).
7.0Full update flow.
7.1Homepage FAQ section.
7.2Actions selection, responsivity.
7.3Edge case status screens.
Finishing touches from internal feedback.
There were no major usability issues that came from our round of internal testing. In fact, over 98% of our internal testers had successfully updated their controllers and found the update process to be easy.

This meant that I could direct my focus on addressing feedback for a couple of edge cases.

Figure 7.4 addresses actions being hidden below the fold on small viewports with high zoom. The solution was to append a sticky actions container to the bottom of the viewport if it reaches a target minimum height.
7.4High zoom viewport.
Figure 7.5 addresses feedback about the post-update experience being confusing — mainly regarding controller pairing. A "Get Started" dialog with pairing instructions was added.
7.5Get started dialog.
A bittersweet ending.
Over a million Stadia Controllers were updated to support Bluetooth mode, and that made a lot of people happy!
8.0Announcement and reactions.
8.1A special comment.
8.2Notable press articles.
Project Takeaways:
Finding opportunities within constraints
Viewing constraints from different perspectives helped brew new approaches to tackle other constraints.
Leveraging existing resources
Design resources at Google were unlimited — knowing where to find them and when to use them saved immense time and overhead.
Cross-functional partners should be involved from the start
It ensured that the project was progressing holistically — effectively accounting for content strategy and technical feasibility early.
Simplicity was about reducing complexity, not quantity
If an added extra step led to a more intuitive and error-free experience, it was worth the additional manual effort.
Next project: