Facebook

Product Design · Summer 2015

I spent the summer of 2015 as a product design intern at Facebook HQ in Menlo Park, California. Working on the Payments team, I helped unify mobile payments across multiple products and platforms, and delivered research, prototypes, visual and interaction designs.

Introduction

Payments at Facebook operates at an incredible scale. Every year, the company processes billions of dollars in transactions, in over 200 currencies, through over 30 different payment methods.

Users pay on Facebook through a variety of products: when placing advertisements, making donations, buying things in games, sending money to friends, and most recently, shopping on Facebook pages.

The stakeholders in this space include small and medium business owners, casual shoppers, Messenger users, young and old gamers, and many different kinds of people, across the world, from different kinds of backgrounds. Anything we designed had to work for everyone.

Problem

How do we enable a simple, secure, trustworthy, and consistent payments experience across Facebook?

As it stood, each product team had designed their own payment flows, often separately between web, iOS, and Android. And integrating unique payment flows into products took developers a very long time.

This led to an inconsistent user experience across Facebook, which in turn undermined any payments identity and led to diminished trust.

Some of the many different credit card forms used across Facebook.

Hypothesis

A modularized payments component that is easy to implement, and a pleasure to use.

We decided to design and engineer a single payments module that other products could easily use. In doing so, we set a few goals for ourselves:

Goals

  • Help users identify, trust, and feel secure about paying on Facebook.
  • Help product teams rapidly integrate payments into their flows, ideally in < 2 weeks.
  • Create one solid, consistent system that could be improved and optimized over time.

Features

  • Adding and managing payment methods
  • Selecting payment methods and end-to-end flow
  • Transaction history and settings
  • Customizable design, extensible API

Process

Audit, Research, Interviews

I started with an extensive audit of existing flows on web, mobile web, iOS and Android. I took screenshots of payment flows in Ads, Pages Commerce, Messenger, Games, Business Manager, as well as Settings.

How could we design something that worked for them?

Boleto Bancário, the primary payment method in Brazil, includes an online confirmation followed by an offline payment, adding to the complexity of the payment process.

In addition, my team and I set up meetings with various other product designers, from Donations to Ads Manager, and asked for their feedback. What did they want from payments in their product? How could we design something that worked for them?

Finally, I spent a lot of time reading about the payments space. I learned about the complex infrastructure at Facebook, the various payment networks (VISA, MasterCard, and so on), local payment methods such as Boleto Bancario in Brazil, and much more. I also analyzed mobile payments UX in other products like Uber, Stripe, Apple Pay, and so on.

This phase prepared me to understand the needs of my project better, and set me up well for the next stage: ideation.

Ideation

User Experience

The most important question we tackled was a high-level one. What do we want users to feel? What are some fundamental principles we should keep in mind as we designed?

What do we want users to feel?

After a long brainstorm with our team, we arrived at some key words:

Approachable, Transparent, Familiar Safe, In-Control, Pillars of Trust Simple, Fast, Intuitive

User Flows

Building on these principles, I designed many kinds of user flows. Some included full screen interfaces, other interstitial dialogs. Some used popups, others used dropdowns.

Many of these worked in the ideal case, but broke down when I stress-tested them in different scenarios. In Ads, for example, the interface had to communicate the complex nature of ads payments; the monthly billing, the maximum threshold, any past dues, and more. A small dialog just wasn’t enough real estate.

A small dialog just wasn’t enough real estate.

Along the way, I prototyped my wireframes using Origami, to make sure what worked in my mind also worked in my hand.

Prototype of end-to-end flow
Testing ideas early using Origami came to be an instrumental part of my workflow.

Iteration

In the end, I settled on two possible design directions: what I called Dynamic Card and Full Screen. Both were exciting, both worked, and had strengths in different applications.

Dynamic Card

This approach was beautiful and a seamless way to pay. It only took over part of the screen, retaining context of the primary payment flow.

The whole experience was extremely light-weight, and I imagined it would work well in simple transactional flows such as donations and shopping.

Full Screen

On the flipside, the full screen design allowed for maximum flexibility. It was easy to build, and would work everywhere, without exception. It also was a safe foundation to build on ideas for later.

In particular, we were sure it would work with the complex nature of ads and the unpredictability of future products.

Other Flows

Along the way, to make sure my designs worked in small but important scenarios, I tested them in all the ways possible.

Prototyping

Of course, at every stage of this process, prototyping was key. My goal in prototyping my designs wasn’t to create beautiful presentations, but to validate my ideas.

Prototypes I could hold in my hand and show to other people allowed me to get instant, actionable feedback.

Even if they were rough around the edges, prototypes I could hold in my hand and show to other people allowed me to get instant, actionable feedback.

Testing floating labels on iOS to see if they improve form usability.
Experimenting with a more seamless saving flow. The phone vibrates on sucess.
After mocking up the small and full-screen state of the card, I wanted to visualize the transition between them.
Prototyping for Android is fun yet challenging, since Material Design is so expressive. Here, an inline selection flow.

Solution

In the end, we decided to go with the full-screen design. I iterated intensely on visual style, and delivered mockups and specifications to our development team.

Here are the final screens for the credit card form and the payment selection flows.

iOS Credit Card Form

The final credit card form featured a clean and readable interface with a lot of carefully considered micro-interactions.
The form was designed to adapt well to different cultures; using Spanish in certain countries, for example, or using the alphanumeric keyboard for British postal codes.
One of the micro-interactions was for the expiry date. If a user types the first digit of the month, and there is only one such month, we automatically convert it to the two-digit representation.
The form also changed on detecting the type of the user's card. The number of characters and the hint image for the security code changes from VISA to AMEX.
The form worked on all devices, both old and new. On iPhone 4, we begin without the keyboard so the user sees the entire form before proceeding.
Finally, the inputs would be obfuscated in the app-switching view, being careful to avoid accidentally revealing sensitive info to friends or others using the phone.

Android Credit Card Form

The Android credit card form had the same careful consideration, and worked on all kinds of devices with varying screen sizes.

iOS Selection Flow

The final selection flow for iOS is contextual and changes depending on the number and types of payment methods.

Android Selection Flow

The Android selection flow sticks to platform standards, making sure the user feels in-control at all times.

Takeaways

Designing mobile payments at Facebook was a great learning experience. The situation presented a complex systems design challenge, and with the help of my amazing mentor and team, I was able to solve most of it.

In hindsight, my engineering background was instrumental in my success over the summer.

Also, in hindsight, my engineering background was instrumental in my success over the summer. From breaking down big problems into small ones, to understanding how things are actually implemented, computer science helped me every step of the way. And of course, communicating with engineers at an equal level where we could both geek out about implementation details was great fun.

I’m looking forward to seeing these interfaces and interactions in the wild. If you’d like to hear more about my experience, please drop me a line at athyuttamre@gmail.com.