Perry Wang — Stadia Bluetooth

My Role

UX Lead — Interaction Design, Visual Design, User Flows, Rapid Prototyping

Team

Austin Fisher, UXW
Dean Whillier, UXE
Bryan Coutch, SWE
Ben Whittaker, SWE
Christina Lee, PM

Timeline & Status

2 Months, Launched in January 2023

Overview

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.

CONTEXT

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.

IMAGE

1.1Negative sentiment.

IMAGE

THE PROBLEM

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.

THE CHALLENGE

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.

IMAGE

UPDATE FLOW

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.

IMAGE

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.

IMAGE

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.

IMAGE

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.

IMAGE

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.

KEY DISCOVERY

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

IMAGE

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

INTERACTIVE

LAYOUT PATTERNS

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.

IMAGE

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

INTERACTIVE

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

INTERACTIVE

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.

IMAGE

INTERACTIONS

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.

VIDEO LOOP

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.

VIDEO LOOP

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.

IMAGE

"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.

VIDEO LOOP

No time wasted, true to what's happening

Potential of user doubt and distrust

5.4With artificial loading.

VIDEO LOOP

Feedback to manage expectation and build anticipation — it just feels like it worked

A bit of extra time to wait

VISUAL DESIGN DIRECTION

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.

IMAGE

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.

INTERACTIVE

6.2 Instruction card variant.

IMAGE

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

VIDEO LOOP

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.

VIDEO LOOP & IMAGE

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

INTERACTIVE

6.6User manual.

IMAGE

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.

INTERACTIVE

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.

IMAGE

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.

VIDEO LOOP

FINAL DESIGNS

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.

VIDEO LOOP

7.1Homepage FAQ section.

IMAGE

7.2Actions selection, responsivity.

IMAGE

7.3Edge case status screens.

IMAGE

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.

IMAGE

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.

IMAGE

RETROSPECTIVE

A bittersweet ending.

A HUGE SUCCESS

Over a million Stadia Controllers were updated to support Bluetooth mode, and that made a lot of people happy!

8.0Announcement and reactions.

IMAGE

8.1A really special comment.

IMAGE

8.2Notable press articles.

IMAGE

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.