Developer Console High Fidelity Prototype

I’ve created a rich, interactive prototype of the Developer Console in UXPin to illustrate the types of experiences I worked on at PayPal while also excluding any proprietary information.

This UXPin prototype was built using Microsoft Fluent UI controls which were imported from Github. I did the programming to integrate these UI controls into UXPin. Visit the Developer Console prototype at and explore both the Applications and Test Environments “extensions” (modules).

Console Home Page: Here, we see a screenshot for the Developer Home Page. The design for this page changed over time. This sanitized version reflects a recent iteration promoting a new comprehensive DesignOps multi-module view, illustrating how code supporting PayPal.com moves through the entire SDLC (software development lifecycle) from the build stage to testing to to production.

Applications Extension Home Page

Within the Developer Console, each tool module is called an "Extension." The Applications Extension is tightly focused on helping PayPal's developers create new web services (called "applications" internally), and doing some high level management functions.

Applications Home Page: Our Home Page UI Pattern borrowed ideas from my time designing the Home Screen on Motorola's Android devices. Specifically, using Cards to surface important information about the apps (web services) most important to each developer -- their own, with easy access to others apps that are important to them, such as upstream or downstream integrations via "Favorites."

DesignOps Note: I designed and programmed multiple UI controls in JavaScript for prototyping in UXPin, all of which were integrated into the Console SDK to speed development of new Extensions:

• - Page Header: Which had easy-to-set props for the main heading, as well as super and sub text, plus a dedicated area for displaying toolbar buttons
• - Page Footer: Featuring props to display the name of the team responsible for managing the Extension, along with easy ways to contact them (e.g., via Slack or email), access its help guide, and more.

Application Details Page

One of the key UI Patterns in the Console is a Details Page for any entity, in this case an Application (web service). I trained dozens of internal tools teams on the importance of a page tightly focused on one significant entity: For displaying important configuration data, security considerations for managing edit and delete operations, standardizing for status, ownership, and much more.

DesignOps Note: I designed and programmed multiple UI controls heavily used on Details Pages, all of which were integrated into the Console SDK:

• - Meta-Data Pair: Which shows a label on one side, and an object on the right, such as text, status info, a contact person, etc.
• - Entity Bridge: In the dark blue band near the top of the page, click on "App Overview" to reveal a list of related Extensions which can show information about this entity (an Application Entity called debitnodeserv). I designed this feature and the Console SDK team built it.
• - Timestamp: Time is relative -- kind of. Working in a global corporation with teams scattered everywhere, I designed a new Timestamp control to drive a consistent display of time across tools. This UI control also allowed a developer to copy an epoch or UTC value in case they needed to dive into server logs for debugging.
• - Profile Card: Click or hover on a face in a FacePile or Persona. The Profile Card was created to encourage collaboration between developers and teams.

Test Environments: 'List of' Page

Most Extensions (modules) within the Developer Console have fairly simple information architectures consisting of just 3 pages, and which we had clear UI Patterns for each: Home Page > List of Entities Page > Entity Details Page. Even more complicated Extensions used ones of these UI Patterns for most of their pages.

List of Test Environments Page: This page shows a list of Test Environments that contain a given Application (web service). Because developers focus on individual apps, it's useful to have an app-focused view of the world of test environments. This also makes it easy for users to pivot from other extensions where they see other 'List of <Entities>' directly to this page, such as a list of pipelines for the same app, list of functional tests, etc.

DesignOps Note: The 'List of <Entities>' Page UI Pattern had a few key points which were relevant across extensions (modules). For example:

• - Page Header: Standardized approach to displaying the app and entity names.
• - CommandBar: The UI Pattern called for a consistently placed CommandBar with an Add/Create button on the left (hidden if irrelevant), and a SearchBox on the right with a certain width. The SearchBox is how a developer could look up other entities in these large databases that they didn't own or hadn't already favorited.
• - Data Visualization: I had conversations with dozens of teams about how to optimize their table displays for user benefit. For example, the most important fields to display for each entity, their display order, how to maximize spacing, the UI controls to use for dates and people, etc.

Test Environment Details Page

I used the Test Environments Extension as one of the key test cases for the early iteration of the Entity Details Page UI Pattern. The top Meta-Data Section showed the test environment's own configuration details. In addition, there was a one-to-many relationship for the individual applications (web services) included in the test environment. Those apps were listed below in the data table.

DesignOps Note: This Entity Details Page template design was extremely versatile and leveraged across dozens of page in the Console. I also needed to invest in educating individual teams in how security considerations should drive how features like Edit and Delete commands appeared in the page toolbar, the importance of cleanly separating view and edit modes, and more.