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.

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.

IMAGE

1.1Unfaithful sentiment.

IMAGE

THE PROBLEM

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.

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:

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.

IMAGE

UPDATE FLOW

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.

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

IMAGE

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.

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.

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.

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, 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

INTERACTIVE

LAYOUT PATTERNS

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.

IMAGE

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

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.

Disabling instinctive progression 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, 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.

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.

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.

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

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 couple extra seconds 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 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 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.

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

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.