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.
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.
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.
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:
- 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.
- Adding and managing payment methods
- Selecting payment methods and end-to-end flow
- Transaction history and settings
- Customizable design, extensible API
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?
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.
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
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.
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.
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.
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.
Along the way, to make sure my designs worked in small but important scenarios, I tested them in all the ways possible.
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.
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
Android Credit Card Form
iOS Selection Flow
Android Selection Flow
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 firstname.lastname@example.org.