Episode Transcript

Karen:

Hi, this is a responsive web design podcast where we interview the people who make responsive designs happen. I’m your host Karen McGrane.

Ethan:

And I’m your other host Ethan Marcotte.

Karen:

And this week we are delighted, we could not possibly be more thrilled than to have Bill Scott and Mausami Dave-Shah here from PayPal. Hi everybody.

Bill:

Hey, how’s it going?

Mausami:

Hey guys.

Ethan:

But before we dive in, I’d like to take a minute to mention our wonderful sponsor, Campaign Monitor. If you need an email newsletter you should absolutely check them out. Campaign Monitor features Canvas, which is their easy to use builder for creating wonderful email newsletters that look great everywhere, even on mobile devices. We’ve actually found here on the podcast that it’s very easy to create an email newsletter in just minutes. They have a great editor with some really decent drag and drop functionality, as well as some flexible, customizable starter designs that allow you to create these lovely looking emails that match your brand and your content. And the nice thing is, you don’t actually need a Campaign Monitor account to check out Canvas or their other offerings. You can actually just go to their website, campaignmonitor.com and start experimenting today. So thanks again, guys.

Karen:

So why don’t we start this off by having you both introduce yourselves and tell us a little bit about what you’ve been working on at PayPal. Bill, why don’t you start.

Bill:

I came to PayPal about three years ago to lead up user interface engineering. I came over from Netflix where I was doing the same. Then in the course of re-doing the technology stack and working with the UI engineering team, I have moved to a new role recently where I head up what’s called business engineering. So that’s all the retail, merchant, and online payments for PayPal.

Mausami:

And this is Mausami. So, I came to PayPal around three and a half years, just about six or seven months before you, Bill. At that time I started off as a prototyper working with the design teams on creating very quick prototypes for usability studies and stuff. And very quickly from there went on to working with the core account overview sites and applications. I was also leading the effort on account overview redesigns, it went through at least two redesigns. The latest one is the responsive design that you see. Also leading the efforts on on-boarding, and now I am working on the marketing PayPal.com.

The way the company was organized really contributed to this problem. Mobile was a separate organization. And so if you thought about or talked about mobile it was like, that’s another team’s responsibility.

Karen:

I’m sure you realize that we’ve invited you on because we’re interested in talking with you about the fantastic new responsive redesign that you just launched. Can you talk a little bit about how you made the decision to go responsive? Was it hard to convince people? Did you have issues with explaining how responsive would fit in with your overall digital strategy or as part of the combination of apps that you offer?

Bill:

I would say yes. When I got here in 2011, and Mausami was just preceding me by a few months as she mentioned, the way the company was organized really contributed to this problem. Mobile was a separate organization. And so if you thought about or talked about mobile it was like, that’s another team’s responsibility. So you didn’t really think about how to make experiences that just naturally span across.

In order to create one brand and one entity, it needs to be the same on both the mobile site as well as the desktop site. In fact, on any device that you access it through.

There was the concept of m-web. You know, a separate URL for mobile web, which is a very inferior experience. It’s kind of like what you would do five or seven or ten years ago. There wasn’t really much thinking. It was a very divided world between native and web, and web was just thought of as desktop. So that was the environment, so it definitely was a challenging environment to begin with to explain this. Mausami, you had a lot of challenges yourself.

Mausami:

Yeah, so the initial redesign was mostly only desktop focused. We quickly realized that that’s not really the way to go, because you could have… In order to create one brand and one entity, which is PayPal—so saying that this is the PayPal app, or this is a PayPal web app—it needs to be the same on both the mobile site as well as the desktop site. In fact, on any device that you access it through. That is something that the engineers quickly realized. And we were like okay, this makes sense and we really should be thinking about responsive. But the design side and the product side were still trying to figure out how to best use the capabilities that each device or each channel gives us.

Developing a really rich native experience makes perfect sense, but then there’s a whole lot of long tail. There are thousands and thousands of permutations. 203 countries, multiple currencies around the world, all those other situations that you don’t want to have to redevelop across every channel.

Bill:

Yeah, it’s kind of this thing, being torn between… Obviously developing a really rich native experience makes perfect sense, but then there’s a whole lot of long tail. When you look at the challenge, what really is the challenge around PayPal UI, it’s not just the UI itself. Having on-boarding flows to sign up, flows to log in, flows to handle your account, or doing checkout, which is one of our primary use cases. There are others but those are some of the primary ones.

Those are not rocket science UIs. But what becomes rocket science really quickly is there are thousands and thousands of permutations, when you get into all the contingencies and compliance issues and legal. 203 countries, multiple currencies around the world, all those other situations that you don’t want to have to redevelop across every channel.

That’s the stuff that teams sort of know is there, but they end up operating like it’s not there. So they created an app just for on-boarding business merchants in Australia. Here’s one just for doing it in the UK. That kind of problem, PayPal had stepped into multiple times. Each one of those created their own very vertical stack that was specific to that. Trying to have a simple, responsive framework across all those required a lot more than just the responsive technology. We can talk about that in a minute. Those were some of the big challenges.

Ethan:

I’d love to hear a little bit more about that unification process. Because as you’re making this grand push into that responsive framework, how did those discussions about mobile versus desktop manifest themselves? Were you thinking about them as different use cases? Was there some tricky design challenges that came up out of trying to treat these as more unified than they were historically?

When the first designs were being put together, we just built them responsively. We said, this is what responsive means and this is what you you can do with it. As you are thinking about designing you have to think about responsive in your design.

Bill:

There are actually, depending on which. There are a number of products being rethought of at the same time, as well as technology stack, about the same time. I can talk about one of those and Mausami can talk about the other.

The one was, as we started reinventing checkout. The majority of our revenue is through our checkout products. David Marcus became our president in 2012, he’d been acquired through a startup, had a very startup mindset. We wanted to rethink checkout and we got together with the design team, just three or four of us engineers, two or three designers, and a couple product folks locked ourselves in a room and rethink checkout.

From my perspective, from me being a design person as well as engineering person, thinking of responsive was just table stakes. It’s just a default thing that should always happen. You may decide to create a custom experience to optimize around mobile for checkout, for example. But you don’t have to go there first. You can start with responsive.

It was actually an engineering team that pushed it. When the first designs were being put together, we just built them responsively. We said, this is what responsive means and this is what you you can do with it. As you are thinking about designing you have to think about responsive in your design. We did some education there. The checkout design team was really quick, as well as product, to see the benefit of it and get on board with us. We just led it by building that technology out. It was a little longer and more tortuous road as we rethought the log-in experience for consumers, the account pages, and change your funding source and wallet and all that stuff. And Mausami traveled down that long road.

There was also the mindset that we wanted to be able to have something for the mobile devices, have something different for the tablet channels, and completely different designs for the desktops. That took a little bit of education from the engineering side, talking about what responsive is.

Mausami:

With the account overview, we were not only changing the design, so we were not just doing the redesign, we were actually changing the framework behind it. The tech stack, everything was changing. The main reason for that was so that we could actually… We used to have a really 1999 kind of a look before, and along with that, we had a tech stack which was equally old.

Bill:

I think it was 1889.

Mausami:

Pretty much. We wanted to be able to release things faster, be able to get things to the customers faster, so that we can test things out with them. Rather than think about it within PayPal for six or seven months and then by that time, the designs are getting old and we don’t really have any connection with the customers.

With that in mind, we were about four or five engineers and a couple of designers. The design team was actually bigger than the engineers. About nine end designers. They were kind of in the design team. Even though the engineers kept on thinking that, “hey, we need to build something fast so that we can actually and quickly create something and show it to the end users.” There was also the mindset that we wanted to be able to have something for the mobile devices, have something different for the tablet channels, and completely different designs for the desktops. That took a little bit of education from the engineering side, talking about what responsive is.

While we were redesigning, what we thought about was, how can we really simplify? What are the main objectives of people once you log in? Work on those as opposed to just bringing everything that we had on the old stack onto the new stack and redesign that.

And around that same time, Bill had been championing lean cycles. We got to know more about checkout and we got to see checkout as a simple flow, which was responsive. And it was working. And also we had Luke. Luke Wroblewski.

Bill:

Luke Wroblewski. Yeah, yeah, Luke W.

Mausami:

He came over and he worked with us. He gave a lot of talks around Mobile First. And that is actually something that we leveraged a lot because we used those talks, we, the design team, the entire team in fact.

Bill:

And product, yeah.

I remember there were folks on both sides, mostly design, but some on the product side, that were actively resisting us doing responsive. I said, “Just pay no attention to them and do it anyway because they can’t stop you from building things correctly.”

Mausami:

Yes, design and product and engineers would actually go for those sessions, and understand what mobile first was all about. That actually helped us a lot to take this into making it a responsive site, and not just a responsive site, based on Mobile First, simplifying things. While we were redesigning, what we thought about was, how can we really simplify? What are the main objectives of people once you log in? Work on those as opposed to just bringing everything that we had on the old stack onto the new stack and redesign that.

Bill:

Yeah, yeah. It was a forcing function.

It was interesting because at one point, I remember there were folks on both sides, mostly design, but some on the product side, that were actively resisting us doing responsive. And, you know, I was adamant in that I still have a team because I had all the front end engineering teams. I said, “Just pay no attention to them and do it anyway because they can’t stop you from building things correctly.”

Mausami:

Yeah.

When we created responsive prototypes, it was so much easier to be able to test that on different devices with the users in the usability labs. You could see the difference.

Bill:

Show it on mobile and show it on tablet, and then we can use your design sensibility to do the right thing. So we just continued. Where we didn’t… Some places we had total strong design and product support. And in some places we didn’t have it. But we just felt like, the person with the actual code wins. So if we do it the right way with the code, then we’ll win for the customer.

Mausami:

Going with responsive designs, when we created responsive prototypes, it was so much easier to be able to test that on different devices with the users in the usability labs. You could see the difference. We could make a little bit of change, and we could test that right away with the users. So the designers and the product people also saw that, and they slowly started understanding that going responsive, at least as a base, is a much better option.

So the designers and the product people also saw that, and they slowly started understanding that going responsive, at least as a base, is a much better option.

Bill:

Some of those principles that—we don’t quite talk about mobile first the same way anymore—but some of the ideas of thinking about constraints in your design is so important. One of the problems that we get into here because we have all those permutations, is that you can spend all your time around the edge cases instead of around the happy path and doing the happy path right, and then figuring out more elegant ways to handle the other.

Part of the whole story too on this was we did change up the whole technology stack. So we went to Node.JS. We brought Bootstrap in right away. Bootstrap was still a little bit, not quite ready for everything we had to do. So we had done some modifications to support the responsive that we wanted to do. With Bootstrap 3 now, it’s really where we like it, and we migrated things to be fully on Bootstrap 3. So Bootstrap was a big, a big help for us, a big contribution.

We spun for a long time because the team got into the trap of trying to create a perfect experience. Some of the people on the design had a real strong mobile native background. The strength of what they could do in native became their weakness with what they were working on on the desktop.

Karen:

Let me follow up quickly on your process for going mobile first. So, a lot of times we’ll talk to people, and I think one of the struggles that every organization has in going responsive is asking themselves, “how do we take this big mess of stuff that we put on our desktop site and make it work on smaller screen sizes?” I’m particularly interested in how you prioritized your very transactional, use-case driven design process around figuring out what were the most important things to show? How did you do that, and how did you convince other people that was right?

Bill:

We’ll start with the checkout side. Cody Evol was my lead designer on that, and he’s now actually leaving. Great guy! Cody and I, we’re thinking through everything from the Lean UX perspective, and we also we’re working through what is the actual mental framework for checkout. Because one of the big challenges of checkout is, how do you want to pay? Abstracting a way, the concept of being able to select funding instruments and having just a simple wallet, and keeping all that in the flow, and make it work in mobile seamlessly. Thinking across all that will force you to really think, what’s the simplest way to be able to select another funding instrument, what’s the simplest way to pick different addresses and do that on mobile?

Also because checkout, we’re doing it in context. We’re trying not to take over a whole page, we’re taking a smaller amount of real estate. Kind of forces you to think that way anyway because we’re going to be away from taking over whole pages and being more in context, which fits the mobile mindset. Developing that framework for how we would select whether it’s a private label credit card or whether it’s another credit card, debit card, or whether it’s like in Germany, it’s EFT or electronic fund transfer or pay upon invoicing or credit or installments or anything like that. We wanted to be able to make it just as easy to pick one of those styles of payment versus picking a credit card or picking PayPal itself. It was a lot about thinking about the mental framework around these and coming up with three or four basic patterns that we would use and then making sure those patterns would work well on both a desktop context and a mobile context. That was checkout, how we thought about it.

On the account stuff, Mausami, you can jump in here, but I’ll just frame it just for a second. One of the problems was, there we spun for a long time because the team got into the trap of trying to create a perfect experience. Some of the people on the design, whether they were working on the design for the web, had a real strong mobile native background. So they were really really good at mobile native. But going to web and thinking about things like responsive and thinking about getting stuff out quickly and iterating on it and making it better and better over time and avoiding pixel perfection was the stumbling block that the team fell into. The strength of what they could do in native became their weakness with what they were working on on the desktop.

We would get stuck with certain designs because they wanted to iterate so long on it, when in reality we should have been trying lots of different things. Those designs weren’t thought about from a mobile perspective. As we continued to build that way and showed it, it eventually broke their model and they had to rethink it.

Mausami:

Like you said, we were stuck for a long time on the actual designs and making things pixel perfect. But we kind of knew from all the analytics that we had done—the custom analytics and the usability studies on four different areas—that we wanted to highlight our focus on for the account overview, which was wallets, sending someone money, receiving money, seeing your transactions and shopping. That basically became our main areas that we wanted to focus on.

The point is that responsive is not a thing in itself. It is table stakes and it’s a necessary tool and a way to frame your thinking. It’s all those things which is really what’s powerful about it.

Bill:

That came out of a lot of data analytics as well as qualitative research too. And so to answer your question, tie it up here. By saying you order those key things, then each of those became something to think about. How do I think about this in multiple contexts and what’s the most essential thing I want to do? If I’m going to send money, what’s the simplest way to send money? We kind of had our own mantra on the teams, to break away from the old PayPal that was overly complicated and a very complex UI, everybody got to see how simple we could make the happy path and then worry about the contingencies and do those as elegant as possible and create a framework for that.

The point is that responsive is not a thing in itself. You can say, “ok, well I’m just going to do responsive design and responsive design engineering and that’s going to solve all my problems, right?” And I know you guys know that. Some people get kind of caught up in that. Especially when you get into application development. It is table stakes and it’s a necessary tool and a way to frame your thinking. It’s all those things which is really what’s powerful about it.

In all of our products, but checkout especially, because so many milliseconds is worth so many millions of dollars. We’ve got an equation, I don’t know exactly what it is top of my head, but if you lose a second, you lose a good bit of potential revenue because people bail out.

Ethan:

One of the things you said that was really interesting to me, is how this started as sort of an engineering-led initiative and then bubbled up to the rest of the organization. The reason that’s really interesting to me is because I know one of the things a lot of organizations struggle with when they start embracing responsive design is really placing a priority on performance. That’s historically always been sort of like a technical problem, and we speak to so many organizations that just realize, now it needs to be a priority across the business. Is performance a consideration for you guys as you’re thinking about building this responsive framework? How has that shaped the design process, if at all?

Mausami:

Oh yes, performance is a huge one.

Bill:

Yeah, it is definitely. It’s that way in all of our products, definitely, but checkout especially, because so many milliseconds is worth so many millions of dollars. We’ve got an equation, I don’t know exactly what it is top of my head, but if you lose a second, you lose a good bit of potential revenue because people bail out. Because usually if you’re seeing a second in a medium, you’ve got probably ten seconds beyond right? But what’s curious here—you know I was at Yahoo, and worked with Steve Souders on performance and stuff, and I went to Netflix and I did our round trip tracing and our performance work there.

The thing that was interesting there and at Yahoo, it was all about the client side performance. But here it’s much more about back end. There’s a lot of risk assessment, there’s a lot of planning that has to happen. All those things, if you don’t do those correctly, if you don’t do your risk planning correctly, you can have a lot more loss by lots of bad people out there who try to do bad things to people and their money. It becomes this tradeoff. It’s really not so much on the client side, it’s kind of fairly noise compared to that. So since some performance is so important, as long as we wrote our front end code well, it really didn’t become a huge issue.

Mausami:

Yup.

Any time we got in the same room just whiteboarding together, they actually got excited because they’re not used to being part of that. Once they had part of the ownership model, we came up with some nice, elegant solutions in almost every case.

Karen:

Can you talk a little bit about how the review and approval process might have changed now that you are looking at responsive designs? Like for example, one thing that I love asking about, is how did your legal review change? Did legal and compliance get involved and have to provide feedback in a different way?

Bill:

That’s an interesting one. Overall, the way Paypal worked was everything was in a chain. A serial chain where things got passed along to another group, and every group was basically… I like to joke and say they succeeded by saying no.

What we did, was we collapsed that and started bringing teams in early. Like we showed the legal team both our desktop and web versions, and in fact, some of the conversations with legal were that they wanted to put a lot of verbosity into the experience. We showed them what it would look like on mobile and said “Look, we have the shared go with you to make sure that we do things ethically and legally and everything else. At the same time, share the go with us to create the best user experience.”

Because we went responsive and we were following lean cycles, we started involving the legal teams early on, to show them exactly what it looks like. So we would show them the prototypes as we were building them, so that they get an idea of how it would look.

Any time we got legal or anybody else involved on that level and got in the same room just whiteboarding together, they actually got excited because they’re not used to being part of that, they’re used to being on the very tail end doing something they don’t have any input into. Once they had part of the ownership model, we came up with some nice, elegant solutions in almost every case. There’s very few cases, I don’t know of anything right now that’s really onerous. There was a bunch of onerous stuff though at the beginning. It’s just taken time to get them on board. But showing them the experience and those constraints really helps because you don’t have a lot of room to put all that verbosity.

Mausami:

On a content review, especially around send money, we have so many different rules, and a lot of legal content that used to live on the page before. But because we went responsive and we were following lean cycles, we started involving the legal teams early on, to show them exactly what it looks like. So we would show them the prototypes as we were building them, so that they get an idea of how it would look. If we very much have to add all the legal content we basically brainstorm with them to figure out what would be the right way to do this.

Bill:

It didn’t always work out where we were totally happy, but we were much happier than we would have been in the old system of throw it over the wall to them at the end, and them saying no.

Every one of these products we’ve rolled out have performed better than the previous products, so we’re actually very happy with it.

Ethan:

So you guys have this wonderful looking new responsive site for PayPal. How do you know if it’s successful? How are you measuring how well it’s doing and at the end of the day? Are you guys currently happy with it?

Bill:

I don’t know which one you’re referring to, but the outside page is the one that if you’re logged out, you go to PayPal.com, they’re responsive. The logged in pages are responsive too for consumer, and the new checkout experience that is in the process of continually rolling out is responsive as well. Our on-boarding products are responsive too. Each one of those has a different set of KPIs, Key Performance Indicators.

For example in checkout, if you’re a guest going through checkout, it’s all about whether you not just complete the payment, but acquisition and signing up for PayPal, right? But for a member, it’s actually completing, checking out and paying, right? Successfully doing that. On-boarding is getting to the point of not just on-boarding, but also activation, becoming taking your first revenue as a business and transactions through PayPal and then what kind of volume you get. Every one of them has a different set of indicators.

Every one of these products we’ve rolled out have performed better than the previous products, so we’re actually very happy with it. And now we’re set up because of both the node technology framework we put in place for the application layer, as well as all the work we’ve done around Bootstrap and around the other areas and components and such for the UI, it’s now really, really quick to change stuff.

I’ve talked about this before in other scenarios and other venues, but generally when I got here, to change a word on the site, it could take as much as four weeks to change a word. And now we push very complex experiences and we can do it multiple times a day. In fact, the other day we built a new on-boarding flow for Italy. We made the change within a few minutes and pushed it live within an hour. So it’s a totally different situation than we were before. Then we have all the metrics to test and see if that’s successful or not. And we monitor that on all the channels too, whether it’s mobile or desktop or tablet.

The UI layer is the experimentation layer and we have to build a lean engineering organization that actually enables learning. Responsive is just a big part of it because you can learn across all the channels really quickly.

Mausami:

And we do a lot of testing as well, so A/B testing, at least on the marketing side, and I know a little bit on the account overview side as well. We basically, whenever we release something, we’re releasing two or three different designs and we test which one works better and then just go with that.

Bill:

We always had some of that happening in checkout, but my goal when I got here, I like to say, coming from Netflix, my mantra coming in was the UI layer is the experimentation layer and we have to build a lean engineering organization that actually enables learning. Responsive is just a big part of it because you can learn across all the channels really quickly. You can decide to say well, “hey, in this mobile channel for check out, I’m going to do some additional optimizations the way I collect credit card, the way I do the funding instruments or whatever. That’s different than my desktop experience and I would do that on purpose because the conversion is actually better.” You make those deviations and it’s okay to make those deviations, especially in an application. For the marketing pages, you know the content, generally speaking it’s responsive, it’s a total, complete marriage there because it’s very content driven.

Mausami:

True.

Karen:

Thank you both so much. This has been a fascinating look at some of these huge and wonderful things you’ve been doing at PayPal. So Mausami, Bill, thanks a lot for taking the time to talk to us today.

Bill:

Thank you.

Mausami:

Thank you.

Ethan:

Thanks to everyone for listening to this episode of a responsive web design podcast.

We’re really excited to announce that we’re offering public workshops on responsive design, taking place on March 06 in Boston, and on April 2-3 in New York City. If you’re interested in attending, visit responsivewebdesign.com and register for a ticket today!

And if your company wants to go responsive but you need help getting started, we offer a two-day onsite workshop to help you make it happen. If you’re interested in bringing us to your company, please go to responsivewebdesign.com and let us know that you’re interested.

If you want even more from us, you can sign up for our newsletter, subscribe to this podcast, and read full transcripts of every podcast episode at responsivewebdesign.com.

Thanks again to our sponsor, Campaign Monitor. Be sure to visit campaignmonitor.com and check out their email editor, Canvas. Thanks for listening, and we’ll be back next week.