Downloaded 44 times
Uploaded byUX STRAT
UX STRAT 2013: Karen Pascoe, Implementing Lean UX Across PayPal: Lessons Learned
This document summarizes PayPal's transformation to a Lean UX process. It overcame barriers by starting with customer-centered design, prototyping concepts and testing them with actual users to iterate quickly. This involved UX designers, product managers, and developers collaborating closely. While the design phase is more flexible, the full product team follows Agile processes. Lessons included overcoming habits to stay focused on users, and scaling the process across a large organization. The new approach helped PayPal recentrer on customers' needs.
More Related Content
Similar to UX STRAT 2013: Karen Pascoe, Implementing Lean UX Across PayPal: Lessons Learned
![Chapt_4[1].ppt very interseting and important](https://cdn.slidesharecdn.com/ss_thumbnails/chapt41-251208222956-7cf5e0fa-thumbnail.jpg?width=640&height=640&fit=bounds)
![Chapter4_Initiation_of_Sediment_Motion_v2[1].pptx](https://cdn.slidesharecdn.com/ss_thumbnails/chapter4initiationofsedimentmotionv21-251208223747-f94ef163-thumbnail.jpg?width=640&height=640&fit=bounds)
UX STRAT 2013: Karen Pascoe, Implementing Lean UX Across PayPal: Lessons Learned
- 1. Lean UX @PayPal Sharing lessons from our transformation Karen Pascoe Senior Director, User Experience Design
- 2. Lean UX @PayPal Sharing lessons from our transformation Karen Pascoe Senior Director, User Experience Design
- 3. Lean UX @PayPal Sharing lessons from our transformation Karen Pascoe Senior Director, User Experience Design
- 4. The current paymentslandscape
- 5. Starting state: processcentered
- 6. We needed toget back to our roots
- 7.
- 8.
- 9. How we startedbuilding product Customer Centered Design Product Technology
- 10. Customer driven design& innovation Who is the customer? What do they need/want to do? Design concept for the flow and key screens Validate designs with users Improve design based on feedback Prioritize needs & wants Design Product Technology
- 11. A bit aboutdesign methods
- 12. A bit aboutdesign methods
- 13. Our Lean UXprocess Conceptual Design Prototype Test with actual customers Learn from customers IterateValidate Internally Whiteboards, ma rkers and post its. Who needs a wireframe when you can code it? Can we build it? Any business concerns? How does this fit in to our design standards? Live tests weekly with the whole project team in the lab What “didn’t” they get? Try some alternatives repeat, repeat, repeat.
- 14. Our Lean UXprocess Conceptual Design Prototype Test with actual customers Learn from customers IterateValidate Internally Whiteboards, markers and post its. Who needs a wireframe when you can code it? Can we build it? Any business concerns? How does this fit in to our design standards? Live tests weekly with the whole project team in the lab What “didn’t” they get? Try some alternatives Core team: user experience designers, product managers and front end developers
- 15. Our Lean UXprocess Conceptual Design Prototype Test with actual customers Learn from customers IterateValidate Internally Whiteboards, ma rkers and post its. Who needs a wireframe when you can code it? Can we build it? Any business concerns? How does this fit in to our design standards? Live tests weekly with the whole project team in the lab What “didn’t” they get? Try some alternatives Core team: user experience designers, product managers and front end developers Special guest stars: architects, product architecture, subject matter experts (legal, risk & regulatory)
- 16.
- 17.
- 18. Where we’re attoday Lean UX: Define the experience Agile: Build the experience into the full tech stackOur design phase doesn’t need to follow formal Agile cadences, and we’re OK with that Our full enterprise team likes formal agile cadences, and we’re also OK with that
- 19. Where we’re attoday Lean UX: Define the experience Agile: Build the experience into the full tech stackOur design phase doesn’t need to follow formal Agile cadences, and we’re OK with that Our full enterprise team likes formal agile cadences, and we’re also OK with that
- 20.
- 21.
- 22. Lessons learned • Weall need to be in the same place • Muscle memory is hard to overcome • Don’t stay “black ops” for long • This could have been easier w/o legacy
- 23. Implications for Design •Designers are perfectionists • Consistency requires investment • We need to iterate our user insight • We have more to do
- 24. Implications for Design •Designers are perfectionists • Consistency requires investment • We need to iterate our user insight • We have more to do
- 25.
- 26. Thank You :) Reachout via LinkedIn if you have questions or want to connect
Editor's Notes
- #2 Hi everyone, I want to thank you for joining this discussion on Lean UX lessons from PayPal. We’re about a year and a half into our broader transformation, so we’ve learned a lot along the way that I hope to share with you all. A lot of what I’ll cover is more strategic: how did we get support from sponsors, building alignment, getting teams ramped up, etc. But I’ll throw in some nuggets that may be more execution focused, but helpful in setting the broader context.But before I get started, I wanted to get a sense of the scale of organizations you all work in.Can you raise your hands if you work in a company that has less than 100 employees? Less than 1,000? More than 1,000?Great. I’m hoping to give insight to you all that will help regardless of the size or organization you work in. {TRANSITION}
- #3 I’m happy share the experiences we’ve had at PayPal in our journey to become a leaner & faster moving design team. And also on our efforts to become more customer engaged at every stage in the design process. I can speak from a number of vantage points. At PayPal, I’ve had a broad design management experience where I’ve been driving this change and now I’m currently leading the redesign for one of our highest growth products and where I get to do the fun stuff and apply this on a day to day basis.PayPal is an interesting case in point for a lot of reasons. We built a respected brand in online payments. We’ve been growing at a rapid clip. We were adding a lot of features. But we got to a point where we were moving really, really slow.Which is an issue (or a byproduct), as we’ve been growing really fast. In fact, we’re in 193 markets, 80 of which are localized sites. We have over 130 million active accounts. We transact in over 25 currencies. We’re growing over 25% each year. Our customers make $8 million in payments each day. Also interesting is our scale, from a UX perspective. Our design team is substantial. We have a global team of 130 individuals, who are visual designers, UI designers, content experts, researchers and producers. We’ve got teams in San Jose, Austin, Boston, Scottsdale, New York, Paris, Berlin, London, Singapore & Chennai. {TRANSITION}
- #4 So I’m going to give you some background into our transformation: what drove it, why it has been key to our strategy and lessons learned along the way. I tend to think of strategic initiatives as those that have a 2-3 year trajectory that eventually become part of the muscle memory of an organization. We’re about a year & a half in and have learned a lot along the way.{TRANSITION}
- #5 As UX professionals, the businesses we support directly impact how we shape our roles. In my case, it’s payments. The payments space is explosive & hypercompetitive. Mobile payments especially. There are over 700 Payments Startups being tracked by AngelList, with 2/3s of those are solely focused on mobile payments.We have some incredibly successful startups in this space that are formidable competitors like Square, Stripe & Braintree.Beyond startups, we have lots of big & mature players with great capabilities in this space.This includesDomestic & multinational financial services organizations who are slow moving, but have real scale in our business (Chase, Bank of America & American Express)Technology companies who move fast, have deep pockets (Apple with Passbook, Google with Wallet)Card networks (Visa, MasterCard), who have incredible scale and deep pockets as wellWe are seeing competition at every part of the ecosystem and had to make some changes. {TRANSITION}
- #6 But before I go into everything that has improved, it’s good to focus on what was wrong.We were largely oriented, at the enterprise level, around the relative effectiveness of coding in different sites around the world.We built up elaborate processes. We built up processes to check the processes.We documented everything and essentially we were a big waterfall assembly line.Product managers would work, often on their own, to come up with the requirements for the product.When they were done, UI designers would work, often with little engagement from partners or actual customers, on how the requirements would be realized in the experience.When they were done, it was filed into our enterprise system that rationalized all of the people in the different parts of the machine who could code this. The coders picked up the documents – that sometimes had been filed for months before they picked it up and actually coded it.Our time to market was awful. 6-12 months on features, 18- 24 on new products.So we needed to fix things, we needed to get simpler. {TRANSITION}
- #7 In order to fix our time to market, we needed to reinvigorate our startup DNA. We needed to get back to being the disruptor.PayPal has been on an interesting journey as a company. There were some smart folks at a startup in Palo Altoin 2000 who thought that sending payments from Palm Pilots was a good idea. They new how to expand and pivot, also offering email payments and other financial services. They were small, nimble and innovative. They were very responsive to how their product was performing, the customer feedback they were getting. They were excellent competitors. An explosion of creativity unleashed early ways of blocking fraud, becoming embedded into ecommerce sites, and allowing consumers globally the chance to move money without revealing their financial accounts to the recipient of a payment. In 2002, PayPal was acquired by eBay after a very competitive period between the two.{pause}It’s interesting, because this was the book I was reading when was getting ready to come onboard 2 years ago. And I was excited. It was energizing.{pause}But that’s not the PayPal I landed in. {TRANSITION}
- #8 So it was time for a change. And every change needs a good catalyst. In our case, we needed a catalyst commensurate with the amount of change we needed to drive & we got it. In our case, our President had left the company abruptly. That set the stage for a significant leadership change. And as many of you have likely experienced, every leadership change brings a fresh pair of eyes to a business. Ours was no exception.We had a new President appointed, David Marcus. He’d come into the company after we acquired his startup. He’d never run a organizationlarger than 150 people, compared to the 13,000 employees at PayPal. And he brought new thinking. He appointed key people into the right leadership roles. He acted quickly to gain focus – like collapsing 9 product organizations into 1 to streamline decision making.And when it came to building product, he wanted to shift the organization to the lean & nimble ways he knew in startups.{NEXT}
- #9 We had our mandate. And things started to change. Fast.It’s important to note that we gained alignment quickly across all parts of our organization: design was at the forefront of driving this along with product after living through the pain of excessive process that got in the way of shipping great experiences. Our head of technology couldn’t be happier to have this as a top priority to the business, he also new to his role. Other parts of our organization like our support services were all aligned to help us drive change.We had a real changing of the guard.{TRANSITION}
- #10 We really had to get back to basics. I know I’m talking to a room filled with UX practitioners & strategists, but our organization had gone astray. There are lots of reasons for organizations to get off track. I can imagine that each of you all have challenges big & small in your organizations.When we’d decided we wanted to change, the pieces needed to get things back on track started to come together.[transition]
- #11 We got back to a simple user centered design process, getting the key parts of the process starting to get the customer engaged in every stage of the design process. We had all of the right capabilities:A Market Research team who did a great job of letting us understand our customers from a segmentation perspectiveA User Research team who did a great job of running usability testing and had the latest & greatest in capabilitiesA great partner in our front end development team who was intent on allowing us to be setup for a front end design that could evolve, given feedback from customersA Product Management team who knew what we wanted to get out to market and new the competitive landscapeAnd a design team who knew how to designSo we stepped back a bit and went back to basics, and looked to re-introduce basic user-centered design processes. This is a parallel effort that we’ve been running at PayPal that has turned into a full fledged Customer Driven Innovation methodology or CDI for short. Supporting our engagement with customers, our CDI methodologies are being rolled out concurrently with Lean UX.{transition}
- #12 When it came time to decide how we wanted to design product, we spent some time thinking through the prevailing methods. There are different design methods by and large that can be used. We’ve got “Big Design Up Front” BDUF, whatever you want to call it. Designers who know user-centered design really well know this. They like it, because designers like to understand a problem before they go and try to solve it. But in doing so, you need to allow a considerable amount of time for researchto get up to speed. It could be 3 - 6 months of ramp time before designs start hitting the market. That was too long for us, given our waterfall baggage.Then you have a Studio model. This is the one where you rely on very talented, but very expensive design teams from interactive agencies. The interesting thing about interactive agencies is that they will never know your business & your constraints as well as you do. You get beautiful deliverables. Big, thick, well executed deliverables. They’d go “thunk” if you dropped it on a desk. But at the end of the day, that was really waterfall as well.{NEXT}
- #13 For us,we had the advantage of being a design team fully integrated into Product with a strong partnership with technology. So we had the teams & the scale. For us, we looked at iterative and wanted to start making sense of all of what was out there: Agile, Lean, Lean for UX. We were also very inspired by Lean Startup thinking: test & learn, pivot, cohorts.Thinking was emerging, best practices were starting to surface.And we liked iterative and worked to develop our own flavor of Lean UX. We wanted to design quickly, ship quickly, learn & pivot. We wanted to have the customer be highly integrated into the process.{TRANSITION}
- #14 For us, we started with 1 key program that was sponsored directly by the key leaders of our functions: design, technology & product. We got some guidance from the leading thinkers on Lean UX: Jeff Gothelf & Josh Sieden to guide our thinking.We started sketching and stopped going directly to design software. I mean we sketched. On post-its, on whiteboards, on paper.It was liberating. When we weren’t working on this formal artifact, our thinking started opening up. We started having conversations.As things evolved, our designers wanted to do full mockups & prototypes. Our front end developers had a different idea. They already had it mocked up on their screens. Usable code (or leveragable, downstream).And we were picking up steam. We validated internally and from a design perspective.And then we tested. Every week. And a funny thing happened. The whole project team came into the lab. Every week. We didn’t write big research reports. The input was right there. We had everybody. We could just tweak the design.Lather, rinse, repeat. We kept working and refining the process and things just kept on getting better.{TRANSITION}
- #15 There were folks who were critical path to this, and they worked out of the room primarily vs. their cube. This included the product managers, the designers and our front end developers. We had some support from the more services/back end developers as well.We also spent a lot of time with our Agile coaches our Lean UX coaches to guide us through the process. {TRANSITION}
- #16 And we had some occasional folks, like architecture who needed to engage early. We were building up a product architecture capability and it was helpful to have them in at the outset. And we had various subject matter experts. The guests were helpful, but a problem.The teams would get frustrated every time they needed to backtrack to get the SMEs up to speed. So we learned how to manage that better.We were open to understanding what didn’t work in the process as much as what did.We were forming opinions on what we wanted to include and what we could scale.Overall, PayPal is a good learning organization. It was open to making mistakes and learning from them. That’s worth noting as some organizations aren’t. When an organization isn’t good at learning, it makes teams very risk averse.{transition}
- #17 We needed to roll this out more broadly to our teams, to scale it. Keep in mind that PayPal is a 13,000 person global organization. As with any financial institution, we are subject to comply with regulations in the market that we are in.We really ended up doing rollouts in a few parts. We got our Lean UX consulting partners to run workshops in all of our key locations. We took friendly teams and worked with them to continue to expand our efforts & to learn what could be replicated. We tested and learned. We didn’t always have the right tools, the right co-location or the right mindset – but we continued to persevere and work through those challenges.One of the things that was key for us was to gain the confidence in our teams in our commitment to change. Our design team had been living with some challenging processes for some time, and was looking for a better way to work but also had a fair amount of skepticism in our ability to change. We found that we needed to do a lot of reinforcement with our teams. Then we needed to build their confidence in working in different ways. At every turn there was a desire to have big, documented artifacts. It was so ingrained in our thinking. People had to build trust in the new process.Then, the teams we expanded with start having successes. They started moving faster. [TRANSITION]
- #18 In addition, our formal Agile rollout was going on simultaneously. The broader enterprise made a firm commitment to transitioning to Agile in a big bang approach. That was key for us. Having lived through Agile transformations in other organizations, it’s hard to make it work because you have teams dependent on each other.This was very helpful for us. While we had a very willing partner in our front end development team and we had great dev leads in our more back-end processes, we had the same skepticism & muscle memory issues broadly in our technology organization. Formalizing the Agile rollout helped us immensely. It formalized the Agile coaching and helped us speak the same language with all of our tech partners.
- #19 Where we’re at today, a year & a half in, is that all of our new product development is working in Lean UX. The majority of our teams are working with a combination of Lean UX teams for the front end and Agile Scrum teams on the back end. The maturity may vary by team, and we’re OK with that. When we spread this across the organization, we needed to do a lot of training and selling. Beyond that, we moved to expand pilots more broadly across our organization. We keep learning, solidifying and expanding our capabilities.Where we’re at now is expanding our understanding of what we can do. For example, we have been leveraging this for all of our new PayPal Here enhancements. In fact, our most recent success was that we got an iPad app from drawing board to going to the Apple store in 30 days. Yes, you heard right – we did our first iPad app for the product, fully operational in 30 days. It is a Minimum Viable Product, but an incredibly promising one. We have a new suite of merchant reporting and a new developer toolkit that are in various stages of rollout after taking at least half the time that development at PayPal used to take. We currently have a full product redesign in progress right now that will get to MVP in 3 months: sketches to code. This is huge. We are moving today TWICE as fast as we did a year ago. [TRANSITION]
- #20 So we’re learning, we’re testing, we’re seeing what’s working and course correcting. As for the enterprise rollout, it’s really interesting. We’re ramping up training, we’re doing a broader co-location strategy, we’re building out new facilities in all of our campuses worldwide. The facilitybuildout is actually pretty cool. You pack your things on Thursday afternoon. You come back on Monday to new furniture. It took a bit to get that process orchestrated, but all of our key design & development centers will be on our target workstations by the end of Q3.What we’re seeing today is still some demarcation of our Lean UX processes & Agile. As we progress and our tech organization improves their maturity, we may see the Lean UX & Agile parts of the org coming in closer alignment. For our stage of maturity, our technical complexity and our scale; we have needed to run these as separate tracks. By the time we start to see more convergence, we’ll be at the maturity to get there.[TRANSITION]
- #21 We had stuff that we needed and stuff that we didn’t. Our barriers were largely technological, process or organizational.We didn’t need elaborate process anymore. So we got rid of that. But that was an uphill battle. Old process dies hard as we came to find. Co-location was also a big organizational hurdle. In our organization, we were setup with a bent towards the efficiency of coding vs. the quality of the experience. In that old world, we shipped artifacts to different locations for coding. That left us with a bit of a hodgepodge on where our talent was. In fact, co-location is one of the longest tail items for us to resolve over time.From a technology perspective, we needed the code, the designs and our thinking to iterate. We had a great partner in presentation layer development, we had great tech leads across our organization more broadly. We needed to build confidence in our design organization as much as our tech partners did. Getting rid of the artifacts is still an ongoing process for us on some teams. It’s not that we need the artifacts so much as we’re overcoming the muscle memory.[TRANSITION]
- #22 From a design perspective, we are still finding the balance of staffing. On our teams, we tend to have distinct UX disciplines. We’re more specialists than generalists. So our UI designers tend to focus on that, our visual designers on visual, our researchers on research and our content team on content. Figuring out where we would have folks aligned & dedicated vs. shared has been more art than science. We still find ourselves in situations that our Lean UX teams are feeding multiple Agile Scrum teams, which creates a bit of a juggling act at times.{transition}
- #23 Here are some of the lessons that we’ve learned:We all need to be in the same place:But when we can’t, Smartboards & IM help but our collaboration tools are not perfect.We are working through the enterprise to staff into dedicated & co-located teams, but this process takes longer than anyone would likeFor muscle memory: Letting go of artifacts in particular is tougher than you think, as so many parts of our organization have been so conditioned to be reliant on artifacts. Don’t stay “black ops” for long:For us, we wanted to mainstream this as broadly and quickly as possible. We had had prior efforts at transitioning the organization to Agile that failed and failed broadly – and failed because they tried to scale parallel efforts from smaller scale “black ops” approaches. Those efforts were still quite prevalent on teams minds, and we needed morale to be high across the company vs. on any specific team. A note on our technical complexity & legacy: We’re upgrading our tech stack along with our experience;We’re global and it will take us time to roll this outWe still need to react to market & regulatory, and we have to maintain our current product set while rolling out new initiatives. [TRANSITION]
- #24 The implications we’ve seen for design areThat Designers are perfectionistsIt’s hard for designers to let go of shipping greatWe’re doing a lot of work to syndicate with teams that they need to ship “good” and embrace test & learnThat Consistency requires investmentWe are investing heavily in patterns, frameworks & standards. We have currently rolled out frameworks for adaptive/responsive & for mobile. We are looking to move all of our designs to a “PayPal First” We are staffing up outside of dedicated teams to build up governance & controls to keep Lean teams focusedWe are doing more work on the design “infrastructure”[NEXT]
- #25 We need to iterate our user insight, because we don’t do exhaustive research up front. We’re still testing & learning on how to capture that information/insight on a rolling basis. We’re gathering it and gathering it ad hoc, but it is helpful to build richer personas over time.We have more to doWe used to have some skeptical staffers, but that has gone by the wayside at the 1 year mark (yes, it took that long)We have some confusion between Lean UX & Agile, but that is also tending to clearWhere we’re focused now is driving velocity: how can we take impediments away from the teams and allow them to crank work out faster. For us, we really see patterns & frameworks as key to velocity as much as it will drive consistency
- #27 Thanks everyone for your time. If this is a hot topic in your organization, reach out via LinkedIn and let’s connect more. I’m always happy to talk shop.