Google Over The Air
Design — UX research
Context
I joined the Android UX team as the only designer working on technical web applications, since everybody else was working on the OS itself.
I sat with the Software Engineer teams to follow the different projects and had brief 1:1s with my manager every other week to give her updates.
My first and main project was GOTA (Google Over The Air), the update system for Android that’s part of the Android Cloud Services for Partners
It’s used by over 150 Brands, for more than 600 Products and serves 7.5M+ Devices.
But it looked terrible.
I’ve been told it was made in 2008 by Software Engineers for Software Engineers (might I add, probably over a weekend?). One very long pager, raw HTML components thrown on it, a dubious choice of colors that were unreadable for labels…in short, this was the perfect gig to show what UI design is all about!
The main requirement was to make it adhere to Material Design specs.
UX research
To collect info about the users, both internal and external to Google, I conducted interviews, sent a survey and went data mining in the existing databases.
My main goal was to understand how people were using this tool and how they were feeling about using it because it was potentially a very critical but also stressful process.
The next step was to get familiar with the frameworks that the Software Engineers were using. As the only designer in a sea of Software Engineers, the most practical and strategic approach that I could find was to go with the flow and not try to impose too many design patterns outside of the component libraries offered by those frameworks.
First elements
I created a book of elements with examples and prototypes from those libraries for each design pattern, then refined some elements with the development team. Custom elements were created only when we couldn’t find the right fit.
The discussion was often helped with whiteboards or photocopies of a particular element where we could draw different scenarii to find the right one.
Another tool that I created for the team was a chart to understand what tasks were performed by what type of users, along their learning curve from absolute beginner to power users.
It was then time for the first wireframes.
After 7 iterations and going back and forth between stakeholders, the development team, and some selected power users…
The new GOTA portal was launched!
Interesting elements of this project
Tabs
One of the first decisions that I took was to move the different sections of the one pager into Tabs that were representative of the different tasks.
Expandable main info
There was a panel with the main info for each device that was always displayed on the top of the page. Due to the fact that it was taking up a lot of vertical space and not always needed, we made it expandable (and made sure to remember the preferred position in user preferences), a compromise to the more elegant feature I had in mind originally (proof of concept: hover and scroll down over the Content box).
In the end, it might be less elegant but more efficient because the user can customize how the tool looks.
Enhanced Data table
Since users spend a lot of time with the Data table (sometimes everyday), we built in a lot of features to help them manipulate their data, especially because some rows were subsections of others: Sorting — Collapse all — Expand all.
Also adding a Filter to the Data tables with categories was a big improvement: users could filter by Strings or Boolean depending on the type of data.
Row density
The Material specs are asking for very tall rows but user feedback was suggesting otherwise: most needed a denser Data table to display as many rows as possible on one screen. Our solution was to add the possibility to change the Density of the rows (and gracefully bending the Material specs) with 3 predefined settings — the tallest respecting the original height. This setting is also part of the user preferences.
Configuration creation
Creating a new configuration for an update can be long and confusing, so I clipped it like a checkout process with a Stepper.
We also display just one Hint Text Box at a time on the focus of a field to avoid confusion and reduce stress.
Some fields were also implemented with editable Chips and an Autocomplete panel to simplify and speed up the process.
Other fields benefited from an HTML preview panel to get some feedback and control the result of HTML tags.
Animations
The timing of animations was defined as design tokens with adverbs (i.e. “promptly” equals 0.4 seconds) and stored as constants of the application so the developers didn’t have to guess the timing as they were implementing animations. You can see a great example of this in the Salesforce Lightning Design System.
For some specific animations, I also created detailed storyboards.
Specific user flows
I created specific user flows in Sketch (with the very efficient plugin User Flows) for some specific tasks that needed a high level of detail.
Handoff
I also used a Sketch plugin, Measure, to ease the handoff process with the developers. What’s great about this plugin is that it frees the designer from creating redlines versions of the design and creates a mini-website where developers can inspect each element, and copy/paste any measures — from sizes to font family and colors. What a win-win situation!
Whether or not developers use this tool, I think it’s a great way for designers to show their willingness to collaborate and ease the handoff, with little effort from their part.
Because I also have experience with front-end development, I tend to be particularly careful with this aspect of the job.
In conclusion
In the end, I had a great relationship with all my collaborators at Google and learned a ton about their workflows and development tools while providing them with the UX expertise they were lacking.
We sent a survey a few weeks after the launch to measure user satisfaction. Users loved the new look and features, and reported that it improved their workflow. The team was also able to collect new ideas for future features — it’s always a good sign when users want to be involved in your product.
Finally, after working for a few months on the project and looking at the big picture, I realized that this portal was one tool among a dozen that were proposed to Android partners, but that they were each being considered individually (most are developed by different teams) rather than as a suite. I therefore evangelized the teams and project managers by pushing for consistent branding and UX across the tools. This idea has now gained hold and I’m confident that in a few months, the suite of tools will benefit from a much clearer product design as part of the Android Cloud Services for Partners.
