Introduction to the Chase Developer Center
The Developer center Is a platform where a developer can build and securely integrate their digital solutions with Chase’s vast network of customers and business clients. All while using Chase’s leverage as a global leader in payments to help promote better company wide trust in this space. Think Apple’s X-Code, or Google Developer.
6 months from inception to MVP
Senior UX Designer on a small Innovation team
Main Business Goal
Capture more of the marketplace segment for payment API Integration by creating a new platform for Chase.
Have the right information and right structure. The Developer center portal is more than reference documentation, and should be understandable for all types of users.
Ensure it reflects brand. People are more likely to be recurring users of an interface that is consistent with the company’s brand.
Clarity in naming parameters, use terminology that users will understand.
Is it easy to interact with? It essential to perform user testing on the API portal to see how easy it is to navigate.
So why is this important?
Reshaping the Future of Payments
APIs have the growing need for real-time service experiences and information, including the ongoing implementation of real-time or “immediate” payments infrastructures across the world.
Public pages: Home page, Products page, and support page
Private Pages(after login): Products page, Documentation, Test and verify pages, Internal tools, and support pages.
Sandbox environment: for developer to test out code.
Competitor study with users
A competitor study provided us insight into what our competitors are doing well and where opportunities lie. It also helped us learn about the value and usability of their product designs or features.
Quotes from Users
“I would start with a quick set-up page first, then go to documentation…then I would go to individual product pages.” -Steve
“Documentation should be based on the functionality of the Apis” -Haroni
Since we had done some research into the topic and had a basic scope we decided to see what we could discover through simple paper testing with developers in the office. This was done first to define some of the desired content which later evolved into higher fidelity wire-frames.
Synthesize the information
Below is a matrix created with the UX Researcher. We then took these findings to synthesize the pain points into the major user and business goals.
Main goals from synthesis
#Important to Business: Engaging with the brand, and producing excitement to consume the API as an asset in the users productivity toolbox. This would directly promote the growth of the “Tech” side of Chase.
#Important to Users: There were some usability issues that elicited frustrations in these studies. These pain-points included: Irrelevant content on the landing page and an indirect path to the api documentation. The ability to find and the quality of API’s documentation dictates the developer experience.
Using the information collected above, I create two provisional personas to help me communicate my users’ motivations, goals, and behaviors.
Goals: Identify right payment strategy for merchant, and Facilitate technique implementation with internal & external tech team.
Behaviors: Initialization discussion, analyze user need and narrow down solution.
Pain points: Too much manual checks and paper work process, andInefficient search/filter for integrator information, analytics.
“ My goal is to provide the best solution(s) to meet my client payment processing objectives”
Goals: Install tool & maintain functionality
Behaviors: Testing, validating, customizing and debugging.
Pain points: Lack self-service system, Too much manual check, specs finding and version maintenance
“ As a developer, I always look for Documentation or API references “
Once I figured out what the most important features were, I created a user flow and mapped out the exact steps to show the preliminary happy path.
Sketching and Brainstorming
it’s relatively easy to sketch out ideas. To have an idea of how things are really working, we encouraged user tests to gain valuable insights and feedback on the dev portal before moving on to higher fidelity versions.
I jumped into Sketch to create first low-Fi mockups of my proposed solutions. Below are the Hi-Fi mockups of my final solution before and after testing.
Through this case study, I learned the value of sticking with a research in the user experience design process. I understood the needs of the users through testing and one on one conversations. From guerrilla usability testing to user affinity mapping to building a prototype and conducting validation testing. Working for a big company allows for all of these things, but ultimately it also makes it hard to do anything fast.
To validate my proposed design solutions, I tested screens again with friends outside of the field, and got a positive response. Please feel free to ask, to see a more in depth version of this project with more screens.
Thanks for Watching!