Content uploaded by Antonella Pavese
Author content
All content in this area was uploaded by Antonella Pavese on Mar 12, 2015
Content may be subject to copyright.
User Experience at Google – Focus on
the user and all else will follow
Abstract
This paper presents an overview of the User Experience
(UX) team at Google. We focus on four aspects of
working within Google’s product development
organization: (1) a bottom-up 'ideas' culture, (2) a
data-driven engineering approach, (3) a fast, highly
iterative web development cycle, and (4) a global
product perspective of designing for multiple countries.
Each aspect leads to challenges and opportunities for
the UX team. We discuss these, and outline some of
the methodological approaches we employ to deal with
them, along with some examples of our work.
Keywords
Google, organizational overview, user experience,
design, research
ACM Classification Keywords
H5.2. User interfaces
Introduction
The first statement of Google’s Corporate Philosophy is
“Follow the user and all else will follow” [3]. This means
that the importance of user experience (UX) is encoded
into the culture. However, as in any other organization,
the Google UX team encounters challenges and
opportunities resulting from how this is interpreted. In
Copyright is held by the author/owner(s).
CHI 2008, April 5 – April 10, 2008, Florence, Italy
ACM 978-1-60558-012-8/08/04.
Irene Au
Google, Inc.
Mountain View, CA 94043 USA
ireneau@google.com
Richard Boardman
Google, Inc.
Mountain View, CA 94043 USA
rickb@google.com
Robin Jeffries
Google, Inc.
Mountain View, CA 94043 USA
jeffries@google.com
Patrick Larvie
Google, Inc.
Mountain View, CA 94043 USA
patrickl@google.com
Antonella Pavese
Google, Inc.
New York, NY 10011 USA
antonellap@google.com
Jens Riegelsberger
Google UK
London, SW1W 9TQ
jensr@google.com
Kerry Rodden
Google, Inc.
Mountain View, CA 94043 USA
krodden@google.com
Molly Stevens
Google, Inc.
New York, NY 10011 USA
mollystevens@google.com
CHI 2008 Proceedings · Research Landscapes April 5-10, 2008 · Florence, Italy
3681
this paper we discuss the work of the Google UX team,
focusing on four aspects of our culture: (1) a bottom-
up 'ideas' culture, (2) a data-driven engineering
approach, (3) fast and iterative web-development
product cycles, and (4) a global product perspective of
designing for multiple countries. Firstly we briefly
introduce our team structure and locations.
At Google the UX team is part of the global engineering
organization. The team is structured to align with our
core product areas - Search (including Mobile, Maps,
and desktop tools), Commerce (advertising products),
and Applications (our communication and collaboration
products such as Gmail and Calendar). The team
includes people with skills in interaction design, visual
design, user research, web development, technical
writing, participant recruiting and audio-visual
infrastructure.
The team is situated across multiple locations around
the world, including the UK, Switzerland, China,
Australia, India, and Korea, as well as California, New
York, Washington, Colorado, and Illinois in the USA
(see Figure 1).
How we work #1: Bottom-up Culture
Google is built around an 'ideas' culture based on the
goal of continuous innovation. There is a belief that
great ideas can come from anyone, and that this is the
place to help them grow. An example of this is '20%
time' [4,5] All engineers are encouraged to spend 20%
of their time working on something they have a passion
for that may or may not be related to their primary
work. Google News, Google Trends and Google Finance
are examples of products that were originally created in
20% time.
Figure 1: Google UX Team locations.
Because of this, Google can be likened to an ideas
factory with hundreds of active projects being
continuously created and worked on. This leads to
several challenges for the UX team:
1. Challenge 1: How can the UX team scale to meet
the demand for involvement across so many
projects? Many of these projects make significant
UI progress as a 1-2 person project, despite their
recognition that they need UX help; other projects
will never see the light of day. How can UX offer
support without becoming a bottleneck?
2. Challenge 2: Does anyone need this wonderful
technology? In many cases, 20% projects emerge
from a technically feasible or fascinating idea,
rather than a specific user need. How can UX help
steer project focus to an overlooked user need?
Some of the techniques, which the UX team employs to
meet these challenges, are outlined below.
Entering the corporate DNA
While the UX team would prefer to fully engage with
teams and do so on the projects that are most
important, we recognize that the best way to scale
CHI 2008 Proceedings · Research Landscapes April 5-10, 2008 · Florence, Italy
3682
effectively is to educate and train engineering and PM
about user experience. To enrich the fruits of the
bottom-up culture, UX aims to get user empathy, and
design principles into every Google engineer's head. We
want engineers to draw from the lives of our users
when they are making decisions.
A company cannot fully realize a vision of focusing on
the user without having relentless user focus as part of
the DNA. To that end we are running several programs
to build human-centeredness into the company’s
culture, for example the ‘Life of a User’ training
program and ‘Field Fridays’:
• All new Google employees (also known as
‘Nooglers’) complete ‘Life of a User’ training from
the UX team, which complements their technical
training. This covers user-centered design
principles and useful research methods, as well as
introducing the UX team and available resources
such as styleguides.
• In addition, the UX team runs a ‘Field Fridays’
program at various locations whereby any Googler
can attend field studies to connect them with the
everyday problems and “delighters” of our users.
These studies may be focused on a particular
project or on gathering more long-term data to
guide product teams. Our aim is to ensure that
there is always at least one non-UX observer in
every study.
Scaling to support hundreds of projects
At some stage in most projects involving UI, some
hands-on UX involvement is required. This is provided
in a scalable fashion via ‘Office hours’ sessions for each
of our product areas. Here, UX designers and
researchers are on hand at a regular time each week to
provide consultancy for anyone who wants it. This
means that new 20% projects without any official UX
commitment can still get assistance. In addition,
internal UX standards, style guides and pattern libraries
allow teams to leverage previous design work.
Rather than running distinct usability tests or
walkthroughs for all new features, the team tries to
bundle up testing into regular testing programs for any
single product area, e.g. Search or Commerce. As well
as streamlining the recruitment process, spare 5-10
minute “piggyback” slots can be made available for
smaller projects that might not otherwise have a
chance to get early user feedback.
Helping Focus Projects on User Needs
Sadly it is impossible to conduct early research for
every emergent project idea. A key aim for user
research is thus to focus on broad strategic work that
can be used by a lot of project sub teams, including
those that are just coming into existence.
The UX team also maintains a User research knowledge
base. Here our aim is to ensure salient information is
easily accessible by engineers and other team
members. Where possible general themes are
presented for a product or product area (e.g. “The Top
10 things you need to know about GMail users”). This
means that some grounding research is available to
engineers working in any area.
How we work #2: Data-driven approach
Google is a very data-driven organization. Everything
from server performance to hiring success is tracked
CHI 2008 Proceedings · Research Landscapes April 5-10, 2008 · Florence, Italy
3683
rigorously, via metrics and dashboards. Having the key
statistics at hand is central to the executive decision-
making process.
The majority of Google's products are web-based,
making web analytics a very important user research
method for our team. We have specialists who work
solely on analyzing aggregated usage data from a UX
perspective, helping to get a better understanding of
how our products are actually being used, and what is
working or not working for our users. We track
conventional metrics such as page views, and also
more user-centric ones. For example, a key indicator of
the success of a product is its growth in terms of the
number of users who are active, but there are many
possible ways to define “active”. A typical definition is
that the user visited the product’s web site at some
point during a fixed time window, such as the last 7
days. When studying Blogger [2], however, we
observed that individual bloggers have very different
patterns of posting (e.g. several times per day, versus
once per month or less), and proposed that it would be
more appropriate to use a variable-length time window,
based on what is typical for each blogger.
For many of its products, Google will test UI variations
on the site by exposing them to a randomly selected
set of users in a live experiment - a technique also
known as "A/B testing". For each variation, key metrics
are tracked, enabling us to see which variation
performs best. The results are often surprising and
may run counter to the predictions of even the most
experienced UX practitioners. We can gather lots of
data in a short period of time - but it is often necessary
to let experiments run for a while, to get both the initial
effect and the settled effect.
Of course, web analytics can show us what is
happening, but not why. We always supplement
quantitative analysis with qualitative study of the
contextual factors that drive user behavior (e.g. via
field research, diary studies, face-to-face interviews).
It can be particularly valuable to combine the two types
of methods in a single study, recruiting a set of
participants to use a specially instrumented version of a
product in a field study. This allows us to gather
detailed and highly accurate data on product usage
over time, while being able to interpret it with
contextual information gathered from e.g. diaries or
user interviews. An example of such an approach,
applied to Google Maps for Mobile, is reported in [6].
How we work #3: Rapid web development
cycles
Desktop software was traditionally updated on an
approximately annual basis. With the advent of the
web, updating web-based products is much easier,
allowing companies such as Google to roll out new
products and features much more rapidly.
In order to support tight turn-around, UX practices a
number of agile techniques such as guerilla usability
testing (e.g. limited numbers of users hijacked from the
Google cafeteria at short notice), prototyping on the fly,
and online experimentation.
One agile usability technique also employed at Google
is enabling a live instant messaging dialogue between
observers and moderator during lab-based testing [1].
This enables redesign even within the scope of a single
study session, and allows extensive product iteration
over the course of even a short user study.
CHI 2008 Proceedings · Research Landscapes April 5-10, 2008 · Florence, Italy
3684
How we work #4: Global audience
The term 'Google' has found its way into everyday
language in many parts of the world - this is testament
to the reach of the products we help design as the
Google UX team. Unlike in many other organizations,
every product at Google is built from the outset with a
view to being rolled out in dozens of countries and
languages. This truly global perspective, combined with
a wide product portfolio, has two consequences: (1) we
face the same challenges of localization as other
organizations, but on a much larger scale; (2) many of
our core products (e.g. search, maps) are dependent
on locally existing content and its structure as well as
on locally variable needs, hence we face global UX
scaling challenges that are more unique.
UI localization challenges
As the quality of local user interfaces has a tremendous
effect on the usability of our products internationally
the UX team works closely with localization (l10n) and
internationalization engineering (i18n) teams.
International user studies can help to highlight some of
the problems for some products in some regions.
However, the focus of our work is on more scalable
efforts, such as fixing problems in shared UI libraries,
and providing training and resources to in-country
teams to conduct their own ongoing research.
Global UX challenges
While poor UI localization can be a formidable barrier to
using a product, it's also the - relatively - easiest to fix.
A far bigger challenge is the variation in user needs and
expectations that stem from cultural, regulatory, and
structural differences. One area, where such variations
are evident is that of global payment systems, which
impacts both our advertising products and Google
Checkout. Differences in financial regulation impacts
what information must be collected and how tax is
calculated. In addition, typical payment systems differ
by market. While credit cards may be ubiquitous in the
US, German users may expect to pay via direct debit.
However, there are even wider-reaching more subtle
connotations: we found in Russia, that the very fact
that a website registered with Google AdWords formed
the basis of some form of user trust, as it allowed users
to conclude that they were engaging with a 'real
business'.
In addition to this general global diversity in user needs
and use cases, Google Search (web, local, map, etc.)
faces specific challenges that are related to the
question of what content we offer, how we trigger it
and how we rank it. As an example, if a Google Maps
user types 'Manchester Airport' does she want
Manchester UK, or Manchester US? Can we accurately
predict her intent from the location, language, or
interaction history? Or, while it may be evident to every
German that 'HH' is short for 'Hamburg' when talking
about cities (as car number plates are often used for
locations), this search term may have a different
meaning in another location or context.
To respond to these challenges we are growing the
Google UX team globally, so that we have members
with local expertise who live and work in all key
markets. In addition we are working increasingly with
local Googlers in the many sales and support offices,
who volunteer some of their time to give feedback on
early prototypes. In addition we conduct international
user research projects in which local Googlers and
members of the UX team go out into the field to learn
about local needs and thus increase sensitivity and
CHI 2008 Proceedings · Research Landscapes April 5-10, 2008 · Florence, Italy
3685
awareness. Finally, with Google's increasingly globally
distributed product development we are now also
working on products that are first created in and for an
'international' market, and then 'localized' for the US.
Supporting Other Diverse Users
As well as international users, another example of
diverse user needs is that of providing accessible UI for
people with disabilities. [7] discusses some of the
methodology adaptations made at Google to
accommodate blind participants. These include (1)
customizing test environments, (2) dealing with audio
interference between screen reader output and the
interview dialogue, and (3) educating observers
inexperienced in accessibility technology.
Closing Discussion
In this paper we’ve outlined a few aspects of UX work
within Google’s engineering and product development
culture. Many of these cultural aspects are common to
other companies, but the combination of all 4 described
in this paper - 20% projects, data-driven decisions,
tight web development cycles, and global outlook - is
unique to Google, and leads to a unique UX
organization.
Acknowledgements
Thanks to our colleagues at Google for their input on
the paper.
References
[1] Boardman, R., No IM please, We're Testing,
Richard Boardman, Extended Abstracts of CHI’06, ACM
Press (2006).
[2] Kramer, A., and Rodden, K., Applying a User-
Centered Metric to Identify Active Blogs, Extended
Abstracts of CHI’07, ACM Press (2007).
[3] Google website, Company Information: Our
Philosophy, http://www.google.com/corporate/
tenthings.html
[4] Google blog, Google’s 20% time in action,
http://googleblog.blogspot.com/2006/05/googles-20-
percent-time-in-action.html, 2006.
[5] New York Times website, The Google Way: Give
engineers room, http://www.nytimes.com/
2007/10/21/jobs/21pre.html, 21 October 2007.
[6] Riegelsberger, J., and Nakhimovsky, Y, Seeing the
bigger picture: A multi-method field trial of Google
Maps for Mobile, Extended Abstracts of CHI'08, ACM
Press (to appear).
[7] Strain, P., Shaikh, A, Boardman, R., Thinking but
not seeing: think-aloud for non-sighted users, Extended
Abstracts of CHI '07, ACM Press (2007).
CHI 2008 Proceedings · Research Landscapes April 5-10, 2008 · Florence, Italy
3686
