The past and present of Venmo on Android
With some thoughts about the future
A few months ago I became the lead designer for Venmo’s Android platform, after spending a year and a half designing new features and user onboarding flows for our Commerce vertical. Going into this role was a little bit like finding a neglected (borderline abandoned) house, deciding to live in it, and starting to renovate and redecorate it. In short, there hadn’t been much design love on this platform in the entire history of Venmo. My job was to shake the dust off of everything and get to work.
A history of Venmo on Android
The first time Venmo existed on Android was July 2010. According to Venmo’s archives, Ted Power was the designer at Venmo back then. The Android app was released a whole eight months after the iOS app, already setting a precedent early in the development of Venmo for the Android app to be behind the development of the iOS app.
That was it for a while. After 2013, when we adopted the flat aesthetic and got featured by Google, there weren’t any new updates to Android design, until two years later when we adopted the Material Design system.
During those two years, a lot of new features were introduced on iOS, including the ability to pay multiple people, the ability to tag other users, Touch ID authentication, Emoji autocomplete, and in-app notifications. iOS even got a shiny new app icon while Android was just left in the dust.
In 2015, a number of features went became native — that is, they no longer exist on webviews (and traditionally our webviews would always mimic the style of iOS, so they always looked extremely out of place).
In late 2016, when I started to venture into this abandoned house of designing Venmo for the Android platform, I discovered that engineers and PMs were those who were often making design calls for android-specific decisions. Android engineers told me they often would not receive designs for Android, and they would simply use their best judgement and build a flow based on iOS designs. To be honest, I was guilty of designing only for iOS when I was designing features as well.
What makes designing for Android different?
There is always a back button. It’s almost a little like designing on web, because there is always a hardware back button on Android phones, and users are used to accessing that back button to get out of every situation.
Every Android is different, meaning that designs have to be extremely flexible. Designing for iOS means that you know your design will be seen at just a handful of screen sizes, but Android devices come in all different shapes and resolutions.
Android users are different, because someone who uses Android tend to expect their phone to be more customizable, or at least are used to customizability.
The Android experience is not contained within closed-walled apps. You can initiate parts of another app within an app, and you can take parts of apps out into widgets on the dashboard screens.
Some gestures are reserved. For example, in Material Design, swiping from the edge of a screen will always switch tabs if they exist. Swiping from the left edge, if a menu exists, will always bring up the hamburger menu.
The focus on Android
Part of the reason that we’re focusing more on our Android app is that the design team is growing, and we have bandwidth to dedicate someone to thinking about the overall Android experience.
Other reasons are business-related. There is a significant portion of our transactions that currently come from Android users and we don’t want them to be neglected. And while iOS has a greater market share in the United States, Android takes the lead globally.
The starter kit
One thing I’ve done has been to build out and maintain this starter kit sketch file, containing every single screen in the Android app.
This serves several functions. For the design team, this acts as a starting point for creating or updating any feature. Previously, because there was no archive of screens in sketch, each designer would create their mockups from scratch, often consisting partially of screenshots. With the starter kit, not only can designers easily make small tweaks to existing designs, they are also more likely to reuse existing components and styles, ensuring that there’s more consistency in the app throughout.
For engineers, there’s now a source of truth for what every screen should look like, and what the specs are. Sometimes a feature will touch one of these screens when being built (but not when designed) and this provides engineers with a place for reference.
With every screen in the app consolidated into one place, it’s also easier to evaluate the experience holistically. So far we’ve made updates to type styles and colors based on usage across the board. It has also made it easier to examine the impact of changes to a single part of the app, to see which places use similar components, and to update accordingly.
We are still at the beginning. Like I mentioned above, digging into designing for Android is like renovating and redecorating an abandoned house. And we’re just scratching the surface of all the work that needs to be done.
Fit and finish
Every week, I sit down with the Android engineers to tackle screens and flows that need a little tweaking. The list range from updating spacing and styles everywhere, to determining what to do with a one-off text field in a dialog box, to making an existing element more congruent with the pull-to-refresh feature. Eventually, when the easy surface tweaks are out of the way, we’ll start to focus on adding motion and other aspects that make the app feel more smooth and polished.
Consulting for feature designers
Historically at Venmo, we’ve all had a tendency to design in terms of iOS and hold discussions focused only on iOS. The designers who are focused on designing features and flows tend to design iOS-first. As an advocate of and a designer for Android I would spend time looking at others’ designs and bringing up ways to make a design more Android-friendly. Often it means following a slightly different flow as the result of the back button, using a different UI component than what is customarily used for iOS, or just applying a different style.
Components
A portion of my creative and exploratory design work revolves around exploring components and styles. One of the challenges that I’m exploring is errors. We have errors for network failures, for backend fetch failures, for loading a small part of the screen, for loading an entire screen. We also have errors for user input, errors that belong to one input or those that concern the entire screen. Some errors require simply a change to the users’ input or action on the same screen, while others suggest that action elsewhere need to be taken. Among those, some of them can direct a user to the fix, while others require the user to manually access it (for example, something outside the Venmo app). What do error states look like for each of these? How we we design elegant and extensible solutions?
Motion
I gave an entire talk about the importance of motion. On the practical side, motion has the ability to make a navigation model more clear to users. Beyond practical, motion can make an interface feel more alive and friendly. It can emphasize a design concept or a branding decision, and even unify multiple parts of the app.
Motion is something that I feel strongly needs to start being incorporated into our Android app, and definitely something that will start getting attention after cleaning up some of the current visuals.
Towards the future
I want eventually to make the Android app something that I’m proud of; something that other designers will refer to when they talk about good design on the Android platform — and that’s not something done in a day or a week. It’s a long and steady journey, but one that I’m excited to take and that I have a lot of hope for, because both our design team and our Android team are supportive of it. I’ve never worked with engineers who are so willing to do extra work to achieve the desired design, so more than ever, I see so much potential for the future of our Android app.
