This portfolio piece is under construction
🛠️ Lo siento, I’m in the process of adding this portfolio case study. 🛠️
Feel free to explore this first draft.
Timeframe
Dec 2021 - April 2022
Role
UX Lead, interaction designer
Skills
UX design, interaction design
PayPal: Building a coding playground
After working on design systems for a few years, I yearned to return to my roots as a product designer and challenge myself by working in a new domain. From my experience working in the cloud computing and mainframe industries, I had familiarity with designing tools for developers. In October 2021, I joined PayPal as a Senior UX Designer in Developer Experiences.
—
The power of persuasion:
When buyers see a PayPal button during their checkout experience they are 54% more likely to complete their online purchase using PayPal as a payment option.
In order to build a frictionless checkout experience, merchants of all sizes partner with and depend on developers to evaluate and implement the right solution for their business needs.
The challenge:
Faced with tight timelines, developers need a way to explore and play with code so that they can effectively evaluate a solution without navigating through multiple layers of documentation or tools. However, in the current PayPal Developer portal, they must navigate through a maze of 24 steps and 5 different environments in order to demo and test a checkout integration.
Navigating through different environments, documentation, and code snippets makes it harder for developers to find a straight-forward solution to their use cases.
The solution:
As the Lead UX Designer on PayPal Developer, I led the design efforts to build a productive, lead-gen tool for any developer to tinker and experiment with any PayPal integration, now and for any future checkout product offering in under 4 months.
"Developers are one of the most valuable constituencies in business today, regardless of industry. A platform company’s developer ecosystem can make or break its success."
— Accenture
Rocky starts with firehoses
Before I joined PayPal, the Developer team was an island with little design support. The team was super scrappy and creative at problem-solving but needed to define a north star for an ideal developer experience amongst fierce competition in the payment space.
The UX designer contractor previously supporting PayPal Developer abruptly left at the end of my first week, leaving behind a wealth of knowledge that wasn’t distilled to me. Although I was still ramping up, I decided to douse myself with a firehose and learn as much as possible while jumping into the work.
Let’s embrace the suck and get down to business
I immediately set up 1:1s with my 3 product managers, development lead, and upper design leadership to:
Build a tighter relationship between product, engineering, and design.
Understand their roadmap plans
Gain domain knowledge
I took on critical design tweaks/supports to become familiar with a new design system while learning how to use Figma for the first time. Although I moved slower than normal, this would set me up for success to provide design direction for the future integration builder while still providing coverage and support for the front-end devs.
Research: Devs like PayPal but feel like they jump through hoops
In the most recent Developer Diary study, I learned that most Developers had positive views when using PayPal products but mixed opinions using our developer documentation site and dashboard to test solutions.
When a developer makes payment solution decisions on behalf of merchants, they make decisions based 3 deciding factors:
Can I quickly find out if my use cases are supported and documentation is available?
Can I play with any code immediately?
Is there an existing developer community that has sample code, debugging support, and recommendations for this solution?
Working with my PM, we focused our efforts on the second pain point, enabling devs to play with code, while also providing other ways to interact with sample code outside of documentation.
Scoping: Understanding the problem space
Let’s go back to square one to figure out what is problem space before committing to a design.
When I joined the team, stakeholders had conflicting opinions on what the integration builder be.
Should it be an interactive tutorial? A code playground to pass in different props? A debugging and testing tool?
While the team was throwing features and solutions on a wall, I organized whiteboard sessions to capture what were questions, assumptions, and facts.
The whiteboards opened few key questions in order to meet the needs of developers:
What existing tools are they using?
What is the integration builder? What should it be? Does it actually matter?
What are developers expecting?
How might it evolve?
Each whiteboard session allowed me to create scenarios, concepts, and user flows to quickly collect feedback and critique with the core team. Each study and sketch got us closer in fidelity to the desired experience while revealing internal knowledge gaps (e.g. when does PayPal Credit appear vs Pay Later?)
Spinning my wheels on the concept designs (draft)
In the final stage of our product discovery, we conducted a concept test study to understand which visual representations of our solutions were most valuable to developers, and why. In our concept testing, we introduced low-fidelity designs of the checkout simulator to a group of 11 developers from across the world.
The Problem we are trying to solve:
How can we better support different levels of developers (novice and advanced) in evaluating and understanding the PayPal Checkout service early on, before they sign up for an account or contract to use PayPal's Checkout services?
The concepts explored a few key ideas:
Do developers prefer to test and demo integrations via their use cases or payment method?
Navigation: should the integration builder follow a step-by-step linear flow that walks a developer through the integration journey or be flexible to encourage exploration?
Which documentation references should be included in the experience?
Locking in on the vision (draft)
Efficiency and speed are the top value propositions of the checkout simulator
Instant preview and the ability to leverage credentials provided by PayPal were immediately recognized for the value of saving time and speeding up the evaluation and integration process
Guidance is useful for all levels of developers
When guidance is integrated into the design, especially navigation, it supports the experience of "advanced" developers and "beginner" developers alike
Highlight how to move forward in the experience
In an experience that may offer many advanced or custom options, buttons and calls-to-action should first and foremost very clearly highlight next steps in the primary flow of moving the developer forwards in the checkout simulator flow or experience
Developers consistently voiced frustration with any secondary links that might be of interest but that might compete with or take them out of the "primary flow"
Don't make me hunt
As much as possible, ensure that developer doesn't have to hunt for buttons or calls-to-action related to the primary flow of checkout simulator (i.e., "Next" button)
The Outcomes (draft)
I ended up leaving PayPal after ten months, which was shortly after the Integration Builder launched. It was not an easy decision to make. I loved working with my fantastic team, my amazing manager, and being able to work on really cool projects. I miss all the great people I have had the pleasure of working with over the past year.
After the past few months, I realized I was missing something in my life and needed to go out and find it.
Although I ended one journey earlier than expected, I'm about to start a new one shortly which is a dream job.
Business impact:
Tool helped developers preview checkout integrations and customizations before implementing
Tightened collaboration, designing this tool revealed gaps in internal relationships
User impact:
Improved PayPal Developer’s end-user experience by reducing 19 steps from documentation to code