<aside> 👉🏼 This is a 2 part article. Read the other part here: Rethinking Google Translate - Chap 2/2
</aside>
As a designer, I believe side projects are of utmost importance. You get to experiment with various scenarios working on a new topic and it dramatically enhances your skill. On the other hand, I also believe that designers are pretty protective about their work. We take immense shame in accepting if we fail at improving a product through design. But as they say, failing and failure are different things.
While trying to improve Google Translate’s functional design, Indhuja and I faced a lot of roadblocks. Naturally, these were expected. Firstly, this was a side project and we had no data about the usage of any particular feature. Secondly, our aim was also to keep the Information Architecture unchanged. But given the givens, we still think we are succeeding, through one learning at a time. We understood what a wonderful product Google Translate is, at its core. And this astonishing learning gave us immense respect for the product team at Google Translate who might be facing these issues on a daily basis.
The idea came into being when we were looking for a new product to work upon in January. We always try to improve the functional aspect of an app with our redesigns and not just the UI.
We moved to the wunderbar city of Berlin a few months ago and Translate has been a saviour. A tweet from Alex Münch caught Indhuja’s eye and it all fell into place. We thought Google translate would be an interesting project to be occupied with. There are googol (pun intended) number of “redesigns” on dribbble which don’t really serve any purpose, and we hate it. We started with trying to solve one problem this time - Reachability.
Nobody can deny that the technology behind Translate is unparallel but there are some UX issues which we intended to solve. We wanted to keep things at a quick reach. Whenever the user is at home or at a grocery shop they’d want the most used actions, Type and Camera, nearby. So naturally, we thought of putting them all near the thumb.
With the home screen, we aimed to keep things near the thumb without changing the Information Architecture of the page. On one hand, we dropped the icon labels for the Camera and Mic. On the other, we added more information to the Conversation and Handwriting actions. The assumption here was that the user would be familiar with buttons like Camera and Mic. And as the Conversation and Handwriting felt focussed more towards power users, they should have more information attached.
The user can now quickly access the Camera and Mic. The cards for Conversation and Handwriting provide more context.
Taking inspiration from Google Tasks and Assistant for the Material Design 2.0 UI, we went with an all white and blue approach. We wanted the main action of a state to be highlighted with the blue colour. As the primary need for the user while using the app was to view the translated text we tried to keep the translated text in-blue or on-blue.
Colours are used to guide the user’s attention at different stages of the product
In the home state, the language switcher was on-blue. While typing, the real-time translation is in-blue. And finally, in the result screen, the translation is on-blue. This not only brings vibrance in the UI but also directs the user’s eye to the highlighted part of the screen.
This notion was shattered when we read the article by Pendar Yousefi published while we were doing this project though.