Since 2015 I've been managing the UX team for Google Translate, a product that touches 1 in 6 people's lives on the planet every month. My family and friends sometimes ask: what's there to design for Google Translate? Here's the answer. 

The beginning
Google Translate is a family of products that include mobile apps (iOS & Android), a web application, a crowdsourcing community, as well as multiple integrations in other Google properties like Search, Chrome, Gmail, Docs, etc. I joined the team in 2015 with a mandate to improve our products for our diverse global users, and to create a  vision for translation experiences of the future.

Compared to my previous teams at Google, the Translate team was a lot smaller and scrappier. In fact, I started as the sole UX designer on the team, and this startup-like culture was something I greatly valued. I also valued staying organized. Establishing simple things like a centralized file system, internal team website, weekly email updates, quarterly objectives and a project allocation process not only made UX contributions more visible and collaborative, but also created a strong foundation that scaled well as my UX team got bigger.
Focus on user research
More than a billion people around the world use Google Translate. From language learning to communication, they have a diverse set of needs. In addition to being an efficient utility app, we wanted to better understand our users' current workflows and pain points to provide better experiences for the most important use cases. For this, we needed to do user research, but in the beginning we didn't have a user researcher on the team. I had to come up with a user research program that scaled and allowed me to continue working on design in parallel.
After digging through past studies and organizing it in a research archive, I created a UX research program focused on international markets where Google Translate had a large and growing user base. The program offered on a variety of research methods; Google Surveys allowed us to ask anything from our users in a few clicks, in-house cafe studies helped us settle minor UI questions quickly, vendor-driven usability studies gave us deeper insights internationally, and annual immersive discovery trips gave us valuable first-hand knowledge of our users. Using this program we conducted more user research studies in my first year at Google Translate than in all the 5 previous years combined.
Creating a vision
We had a great process and we were doing good research. What was missing was a vision. I volunteered to plan and run our team's annual strategy off-site, and used Design Sprint methods to structure the day around vision-setting activities. After the sprint, I used all the ideas we generated to create a draft product vision and roadmap, focusing on 5 key areas, and presented it to our leadership. They were excited and supportive. That roadmap is still used as a basis for project planning and prioritization.

Intentionally blurred due to confidential material

Case study: Tap to Translate
One of our key research discoveries was this: eager to consume content in their local language, users in countries like Brazil and India were creating their own “hacks” by copy-pasting to and from Google Translate, to translate content shared within messaging or social apps. Given that more than 50% of content on the web is in English, and only 20% of the world’s population has knowledge of English, this makes a lot of sense.
Having to switch back and forth between Google Translate and other apps was a huge pain point. To solve this, we joined forces with Google's Creative Labs team and created Tap to Translate: a feature that allowed users to instantly translate any text from within any app on Android, simply by copying it. This video explains how it works:
This was not only a huge hit with our users, but also a successful model of cross-team collaboration within Google. As Translate's UX lead, I ran design sprints between our Mountain View and New York teams, led weekly UX reviews, planned and direction international usability testing, and iterated on final versions of the design.
People use the copy button for many reasons, and we didn't want to annoy them by popping up a translation every time they copied. So we decided to turn Tap to Translate off by default, and let people who need it the most turn it on themselves. But that introduces the problem of discoverability; what if people who really need this feature don't notice it? I suggested we prominently expose the feature when people need it the most; right after copying a piece of text inside the app. This clever contextual feature promotion completely outperformed our static promo card on the home screen and is how most Google Translate users discover Tap to Translate. 
Case study: offline translations
One of the most useful things about Google Translate is that it works offline and without an internet connection, if the language files are downloaded. The problem is many people didn't know they could download languages. I wanted to fix this.
I wanted to find the right way to tell people about our offline feature. An on-boarding tutorial was one of the ideas. We tested a 2-step on-boarding flow that asked users to select their languages, and choose additional options like offline or Tap to Translate. As expected, most people didn't read the options and didn't like going through on-boarding overall, but every single person did select their languages.
Observing every single participant actually select their language was an important insight. I used that information to create a simpler 1-step on-boarding flow that asked users to select their language pair. I also added the option for 'offline translations' on the same screen and enabled it by default, so even the users who wouldn't necessarily read would get the benefit of offline translations for the languages they use the most. Thanks to this, offline package downloads increased considerably.
Back to Top