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
Enabling Bluetooth on the Stadia controllers was the biggest 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.1Negative sentiment.
This wasn't going to be your typical firmware update.
A pile-up of constraints.
Firmware updates were usually delivered automatically. However in our case, this was not possible because the size of this update was too large and that the platform was shutting down.

The decision was made to build a first-party website as the update tool — which came with its own set of unique constraints and challenges:
A two month deadline, because we had to launch before the sunset date.
Hardware access nuances. The controller had to be put into a rare "boot menu" mode.
Clunky by design. Hardware security access wasn't intended 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:
Concise Clarity
Clear, informative, and straight-forward instructions.
Proactive Feedback
Anticipate and communicate progress and errors.
Product Excellence
Overdeliver with design.
2.0 Project process within timeline.
The backbone of the project.
You gotta start somewhere.
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 helped mitigate the cognitive load of seeing all the instructions at once.

Additionally, overly-technical terms were revised to better cater to a general audience.
3.1 First prototype flow, categorized.
Pinpointing the issues.
Having structure also helped surface some heuristic issues; which mainly involved confusing hardware interactions and lack of edge case considerations.
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.
Most of the issues could be addressed directly with improved instruction and feedback. (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 (Figure 3.5).

By requiring verification prior to starting the update, we're able to both surface hardware issues right away and familiarize users with the Chrome dialog interaction earlier.

Now, the update process becomes closed, allowing users to jump back to where they left off if the ever get disconnected — rendering it impossible to brick their controllers.
New changes only
3.5Final update flow
No fluff, consistent, and scannable.
Keepin' it old school — responsive layout grids.
A standard set of layout grids and breakpoints (Figure 4.0), was critical in ensuring we could design and build quickly and consistently.
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 — placing high emphasis on textual instructions supported by natural reading behaviour.

However, early internal feedback noted that it was too distracting while the current task was not emphasized enough. This led to a second iteration (Figure 4.2) — which placed 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 when it was required.

Disabling instinctive progression actions also 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, through 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.
I opted for an illustration-led card layout to make the experience feel more tactile and interactive rather than exhaustively reading text from a list. (Figure 5.2).
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 on whether the download was successful.

I worked with our engineering team to implement a deliberate loading delay (Figure 5.4) to convey a more explicit change affordance.
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 bit of extra time 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 elements and 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 documenting design spec to foster smooth design-engineering collaboration.

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 really 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
Google's design resources were near 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: