Xome API Developer Portal
UI/UX Design | User Research | Product Design
UI/UX Design | User Research |
Product Design
UI/UX Design | User Research |
Product Design
A strategic initiative to elevate Xome's API Developer Portal to better support Xome's various API Products. This project aimed to improve the developer experience, enable seamless integration with the platform, and advertise the value of Xome's APIs.
Completed as part of a UI/UX Design Internship with Xome.
Key Features
01
Manage APIs
Manage your APIS and their keys through the dashboard, with the ability to track the status and health of your projects as well!
02
API Documentation
Find detailed guidelines, experiment with the 'Try It' feature, and shift between different SDKS and versions of the APIs.
03
Product Information
Learn about key product uses and highlights through the product landing page.
04
Browse Products and APIs
Utilize the Product and API catalogs to easily find the ideal Product or API for your business
Key Features
01
Manage APIs
Manage your APIS and their keys through the dashboard, with the ability to track the status and health of your projects as well!
02
API Documentation
Find detailed guidelines, experiment with the 'Try It' feature, and shift between different SDKS and versions of the APIs.
03
Product Information
Learn about key product uses and highlights through the product landing page.
04
Browse Products and APIs
Utilize the Product and API catalogs to easily find the ideal Product or API for your business
Key Features
01
Manage APIs
Manage your APIS and their keys through the dashboard, with the ability to track the status and health of your projects as well!
02
API Documentation
Find detailed guidelines, experiment with the 'Try It' feature, and shift between different SDKS and versions of the APIs.
03
Product Information
Learn about key product uses and highlights through the product landing page.
04
Browse Products and APIs
Utilize the Product and API catalogs to easily find the ideal Product or API for your business
Key Features
01
Manage APIs
Manage your APIS and their keys through the dashboard, with the ability to track the status and health of your projects as well!
02
API Documentation
Find detailed guidelines, experiment with the 'Try It' feature, and shift between different SDKS and versions of the APIs.
03
Product Information
Learn about key product uses and highlights through the product landing page.
04
Browse Products and APIs
Utilize the Product and API catalogs to easily find the ideal Product or API for your business
Details
June 2025-August 2025
TIMELINE
Figma, Userlytics
TOOLS
Lead UI/UX Designer on a Product Team
Lead UI/UX Designer on a Product
Team
Lead UI/UX Designer on a Product
Team
ROLE
UI/UX Design | User Research | Product Design
UI/UX Design | User Research |
Product Design
UI/UX Design | User Research |
Product Design
DISCIPLINES
In our current business model, an account executive works with a buyer to help them decide what properties to buy. This process is labor-intensive. It requires a back-and-forth exchange between the account executive and the buyer. Additionally, the account executive is currently manually placing bids for these VIP buyers. Sometimes an auction closes before the account executive can place all the VIP buyers' bids, making it so the buyer can’t actively participate in/bid on all the properties they are interested in. This ends in reduced conversion for our Buyers and Sellers.
By employing a developer portal, buyers could leverage our APIs and receive real-time data to make their decisions. Cutting out the need for curated lists as well as the back and forth between them and the account executive, accelerating decision-making. Additionally, the buyers are able to place bids themselves, cutting out the middleman and reducing the possibility of missed conversion.
Challenge
My Role
In this position, I represented UX on calls with third-party vendors, conducted in-depth user interviews utilizing userlytics, and created several iterations of hi-fi wireframes and clickable prototypes of a new design for the API Developer Portal— leveraging existing design system components as I did so.
Assumptions
Through several discussions with Product, I outlined a few assumptions I had to make in order to proceed with this design so that I would not design experiences for features that haven't been decided.
My Process
Throughout this project, my design process was anything but linear. I often faced ambiguity and would have to design based off imperfect information. Nevertheless, I made this an opportunity to use my designs to discover more about the experience and drive buy-in for the Developer Portal.
Personas
I spoke with Account Managers who work directly with our VIP buyers to define key user personas, clarify business goals, and uncover pain points.
The main takeaway from the Personas is that the first person to look at the Developer Portal will likely not be a Developer. That means we need to make an experience that appeals to representatives at real estate companies who have little technical knowledge, as well as independent buyers, and make APIs approachable to them. That being said, it’s also important that when Developers come to our platform, they’re able to easily understand and integrate with our products. The key here is to strike a balance between these two user groups.
Challenge
My Role
In this position, I represented UX on calls with third-party vendors, conducted in-depth user interviews utilizing userlytics, and created several iterations of hi-fi wireframes and clickable prototypes of a new design for the API Developer Portal— leveraging existing design system components as I did so.
Assumptions
Through several discussions with Product, I outlined a few assumptions I had to make in order to proceed with this design so that I would not design experiences for features that haven't been decided.
My Role
In this position, I represented UX on calls with third-party vendors, conducted in-depth user interviews utilizing userlytics, and created several iterations of hi-fi wireframes and clickable prototypes of a new design for the API Developer Portal— leveraging existing design system components as I did so.
Visual Design Direction
As I created my first iteration of wireframes, I thought about what the visual design direction of the platform should be. I created several different versions of how to approach the visual direction and asked the UX team to weigh in and give their guidance.
Ultimately, I thought it pertinent to focus on a design that was visually accessible as well as simple and dynamic. For that reason, I chose Style E.
First Design Iteration
With the findings from my competitive analysis in mind, as well as my personas, I created sketches of the new Developer Portal platform. Then, utilizing the Xome Design System, I created wireframes of the new Developer Portal. I decided to focus on the Unverified view (when a user is not logged in) because thats what I looked at in my competitive analysis.
I decided to make the following pages:
Homepage
API Catalog
API Documentation Page
Product Catalog
Product Landing Page
During my first design iteration, I faced a lot of ambiguity about what was and wasn’t necessary. I decided to go through with the design with the goal of driving conversations amongst various stakeholders regarding what is and isn’t necessary for the platform, how we can best meet our users’ needs, and how we can maintain alignment of product vision and understanding.
Competitive Analysis
I conducted a competitive analysis of leading developer portals, focusing on how these platforms tackled the four issues I identified in my UX audit of the original platform.
I looked specifically at Wells Fargo, Plaid, Twilio, Spotify, Visa, and the Shell Developer portals for inspiration and guidance.
Second Design Iteration
For my second iteration of designs, I refined the designs according to feedback received from various audiences.
Additionally, I decided to change the Catalogs so that filters were presented on the side instead of the top. This makes it easier to select multiple filters at once.
Before presenting my second iteration of designs to Product and Development, I decided to turn them into a clickable prototype. I did this because it would better display not just how the platform looks, but how it works.
Sitemaps
To get a clear idea of how the interaction design for the portal works, I put together a Sitemap that shows where every action leads.
As opposed to designing then creating a sitemap, creating the sitemap first for the Verified view then proceeding with design allowed me to pinpoint any issues prior to design and create a seamless experience.
-Unverified Experience
After creating this sitemap, I realized that there were many instances in which buttons with the same label would link to different pages. I also noticed that there were many different labels for buttons that linked to the same page.
I decided that I had to rectify this issue because it would likely confuse users and provide an inconsistent experience where user's don't grasp what will happen when they take an action. I fixed this by unifying the content and making sure that the same wording was used across buttons and links that had the same function.
-Verified Experience
To map out how the Developer Portal would change when transitioning to a Verified User Experience, I made a sitemap for Verified users. The main differences between this sitemap and the unverified sitemap are:
Removal of Restrictions on Content and Features
Addition of Dashboard
Manage APIs
Analytics
Dynamic Homepage
Feedback
I conducted two design demos of my first iteration of wireframes, one with Product and Development and the other with Account Executives. During these demos, I received feedback on my designs as well as key features to include in the wireframes.
Additionally, I received feedback from other UX Designers in the organization to help guide the second iteration of designs.
I considered the design demos to be a success because I was able to further define key UX requirements and drive cross-functional collaboration and conversations.
User Research
Leveraging Userlytics, a remote user testing platform, I conducted in-depth interviews with Developers who had experience with API Developer Portals. The goal of these interviews was to understand how people use API Developer Portals–what they find useful, what makes a good portal, and how they evaluate different ones during their discovery process.
I interviewed 4 Developers then coded each of my interview transcripts. Based on these codes, I made an affinity map and gleaned key user research insights from the results.
Third Design Iteration
For my third iteration of the prototype, I asked the question: how does the experience change when the user is logged in? I focused on building out the verified experience, further refining the existing designs to maintain alignment with product, and creating designs for the dashboard.
Before jumping into the final prototype, I received more feedback from the UX team and made some final adjustments to the wireframes to ensure that they were the best they could be.
Happy Paths
I worked closely with Product to define two happy paths that represent an ideal user experience. The first happy path presents an initial impression and exploration of the Developer Portal while the second happy path describes the experience of adding an API/Product to an already active account. I built user flows for each of these happy paths and made scenarios that represent the experiences. I focused on actualizing these happy paths in my designs/prototypes.
Happy Path 1 Scenario:
Joe is a representative at a real estate investment company. After his company buys a handful of properties through Xome.com, a representative at Xome reaches out and provides them with the API Developer Portal. Joe is tasked with evaluating the portal. He activates the link and looks through the homepage. He wants to understand how one of Xome’s products could complement his business’s strategic goals. He clicks on the Product Catalog and surfs through it before finding a product that seems interesting. He clicks on it then looks through the highlights and uses. The product seems like it’d be a great help to his company. Joe returns to his company and recommends the Xome Developer Portal.
Happy Path 2 Scenario:
Joe’s company adopted the Xome API Developer Portal and have been using it actively. After missing out on a few bids due to back and forth between Joe’s company and Xome Account Executives, Joe’s company decides they want to add a Product that allows them to place bids in real-time. Joe goes to the API Developer Portal, find the Product and clicks ‘Start a Project.’ He views pricing information, signs a document through an external link to eSign, and then is directed to the dashboard. In the dashboard, Joe can manage APIs, view important analytics, and more.
Details
June 2025-August 2025
TIMELINE
Figma, Userlytics
TOOLS
Lead UI/UX Designer on a Product
Team
ROLE
UI/UX Design | User Research |
Product Design
DISCIPLINES
In our current business model, an account executive works with a buyer to help them decide what properties to buy. This process is labor-intensive. It requires a back-and-forth exchange between the account executive and the buyer. Additionally, the account executive is currently manually placing bids for these VIP buyers. Sometimes an auction closes before the account executive can place all the VIP buyers' bids, making it so the buyer can’t actively participate in/bid on all the properties they are interested in. This ends in reduced conversion for our Buyers and Sellers.
By employing a developer portal, buyers could leverage our APIs and receive real-time data to make their decisions. Cutting out the need for curated lists as well as the back and forth between them and the account executive, accelerating decision-making. Additionally, the buyers are able to place bids themselves, cutting out the middleman and reducing the possibility of missed conversion.
My Role
In this position, I represented UX on calls with third-party vendors, conducted in-depth user interviews utilizing userlytics, and created several iterations of hi-fi wireframes and clickable prototypes of a new design for the API Developer Portal— leveraging existing design system components as I did so.
Assumptions
Through several discussions with Product, I outlined a few assumptions I had to make in order to proceed with this design so that I would not design experiences for features that haven't been decided.
My Process
Throughout this project, my design process was anything but linear. I often faced ambiguity and would have to design based off imperfect information. Nevertheless, I made this an opportunity to use my designs to discover more about the experience and drive buy-in for the Developer Portal.
Personas
I spoke with Account Managers who work directly with our VIP buyers to define key user personas, clarify business goals, and uncover pain points.
The main takeaway from the Personas is that the first person to look at the Developer Portal will likely not be a Developer. That means we need to make an experience that appeals to representatives at real estate companies who have little technical knowledge, as well as independent buyers, and make APIs approachable to them. That being said, it’s also important that when Developers come to our platform, they’re able to easily understand and integrate with our products. The key here is to strike a balance between these two user groups.
Original Portal Design
There is a beta version of the API Developer Portal that was made by product and engineering. This beta was delivered to VIP Buyers with the understanding that it would become monetized in the near future. It's main purpose is to test out servicing APIS to VIP Buyers.
Homepage
UX Audit
To define baseline design requirements for the redesign, I evaluated the UI/UX of the current developer portal and identified four key issues:
Repetitive and Unintuitive Navigation
Unclear Product Model
Lack of Getting Started Instructions
Plain Visual Design
API Catalog
API Documentation
Product Catalog
Personas
I spoke with Account Managers who work directly with our VIP buyers to define key user personas, clarify business goals, and uncover pain points.
The main takeaway from the Personas is that the first person to look at the Developer Portal will likely not be a Developer. That means we need to make an experience that appeals to representatives at real estate companies who have little technical knowledge, as well as independent buyers, and make APIs approachable to them. That being said, it’s also important that when Developers come to our platform, they’re able to easily understand and integrate with our products. The key here is to strike a balance between these two user groups.
Original Portal Design
There is a beta version of the API Developer Portal that was made by product and engineering. This beta was delivered to VIP Buyers with the understanding that it would become monetized in the near future. It's main purpose is to test out servicing APIS to VIP Buyers.
Homepage
API Catalog
API Documentation
Product Landing Page
UX Audit
To define baseline design requirements for the redesign, I evaluated the UI/UX of the current developer portal and identified four key issues:
Repetitive and Unintuitive Navigation
Unclear Product Model
Lack of Getting Started Instructions
Plain Visual Design
Competitive Analysis
I conducted a competitive analysis of leading developer portals, focusing on how these platforms tackled the four issues I identified in my UX audit of the original platform.
I looked specifically at Wells Fargo, Plaid, Twilio, Spotify, Visa, and the Shell Developer portals for inspiration and guidance.
First Design Iteration
With the findings from my competitive analysis in mind, as well as my personas, I created sketches of the new Developer Portal platform. Then, utilizing the Xome Design System, I created wireframes of the new Developer Portal. I decided to focus on the Unverified view (when a user is not logged in) because thats what I looked at in my competitive analysis.
I decided to make the following pages:
Homepage
API Catalog
API Documentation Page
Product Catalog
Product Landing Page
During my first design iteration, I faced a lot of ambiguity about what was and wasn’t necessary. I decided to go through with the design with the goal of driving conversations amongst various stakeholders regarding what is and isn’t necessary for the platform, how we can best meet our users’ needs, and how we can maintain alignment of product vision and understanding.
Visual Design Direction
As I created my first iteration of wireframes, I thought about what the visual design direction of the platform should be. I created several different versions of how to approach the visual direction and asked the UX team to weigh in and give their guidance.
Ultimately, I thought it pertinent to focus on a design that was visually accessible as well as simple and dynamic. For that reason, I chose Style E.
Feedback
I conducted two design demos of my first iteration of wireframes, one with Product and Development and the other with Account Executives. During these demos, I received feedback on my designs as well as key features to include in the wireframes.
Additionally, I received feedback from other UX Designers in the organization to help guide the second iteration of designs.
I considered the design demos to be a success because I was able to further define key UX requirements and drive cross-functional collaboration and conversations.
Second Design Iteration
For my second iteration of designs, I refined the designs according to feedback received from various audiences.
Additionally, I decided to change the Catalogs so that filters were presented on the side instead of the top. This makes it easier to select multiple filters at once.
Before presenting my second iteration of designs to Product and Development, I decided to turn them into a clickable prototype. I did this because it would better display not just how the platform looks, but how it works.
Sitemaps
To get a clear idea of how the interaction design for the portal works, I put together a Sitemap that shows where every action leads.
As opposed to designing then creating a sitemap, creating the sitemap first for the Verified view then proceeding with design allowed me to pinpoint any issues prior to design and create a seamless experience.
-Unverified Experience
After creating this sitemap, I realized that there were many instances in which buttons with the same label would link to different pages. I also noticed that there were many different labels for buttons that linked to the same page.
I decided that I had to rectify this issue because it would likely confuse users and provide an inconsistent experience where user's don't grasp what will happen when they take an action. I fixed this by unifying the content and making sure that the same wording was used across buttons and links that had the same function.
-Verified Experience
To map out how the Developer Portal would change when transitioning to a Verified User Experience, I made a sitemap for Verified users. The main differences between this sitemap and the unverified sitemap are:
Removal of Restrictions on Content and Features
Addition of Dashboard
Manage APIs
Analytics
Dynamic Homepage
Happy Paths
I worked closely with Product to define two happy paths that represent an ideal user experience. The first happy path presents an initial impression and exploration of the Developer Portal while the second happy path describes the experience of adding an API/Product to an already active account. I built user flows for each of these happy paths and made scenarios that represent the experiences. I focused on actualizing these happy paths in my designs/prototypes.
Happy Path 1 Scenario:
Joe is a representative at a real estate investment company. After his company buys a handful of properties through Xome.com, a representative at Xome reaches out and provides them with the API Developer Portal. Joe is tasked with evaluating the portal. He activates the link and looks through the homepage. He wants to understand how one of Xome’s products could complement his business’s strategic goals. He clicks on the Product Catalog and surfs through it before finding a product that seems interesting. He clicks on it then looks through the highlights and uses. The product seems like it’d be a great help to his company. Joe returns to his company and recommends the Xome Developer Portal.
Happy Path 2 Scenario:
Joe’s company adopted the Xome API Developer Portal and have been using it actively. After missing out on a few bids due to back and forth between Joe’s company and Xome Account Executives, Joe’s company decides they want to add a Product that allows them to place bids in real-time. Joe goes to the API Developer Portal, find the Product and clicks ‘Start a Project.’ He views pricing information, signs a document through an external link to eSign, and then is directed to the dashboard. In the dashboard, Joe can manage APIs, view important analytics, and more.
User Research
Leveraging Userlytics, a remote user testing platform, I conducted in-depth interviews with Developers who had experience with API Developer Portals. The goal of these interviews was to understand how people use API Developer Portals–what they find useful, what makes a good portal, and how they evaluate different ones during their discovery process.
I interviewed 4 Developers then coded each of my interview transcripts. Based on these codes, I made an affinity map and gleaned key user research insights from the results.
Third Design Iteration
For my third iteration of the prototype, I asked the question: how does the experience change when the user is logged in? I focused on building out the verified experience, further refining the existing designs to maintain alignment with product, and creating designs for the dashboard.
Before jumping into the final prototype, I received more feedback from the UX team and made some final adjustments to the wireframes to ensure that they were the best they could be.
Final Prototype
Learnings and Takeaways
Learnings and
Takeaways
Over the course of my internship I learned extensively about how to collaborate cross-functionally and lead UX projects. Some of my takeaways and learnings are:
Ask for specific Feedback. I often required feedback from various audiences in order to move forward with my designs. I found that the best way to garner useful feedback was to provide the people I was asking feedback from with 2-3 options instead of just asking for feedback in general.
Iterate, Iterate, Iterate. Throughout my project, I continually iterated upon my existing designs. I found that in the real world you often don't have all the information you need before you get started. It's best to stay adaptable and use your design iterations to drive conversations and gain buy-in.
The importance of maintaining alignment. Something unexpected that I often found myself doing was reaching out to various stakeholders to try to understand why we are making certain decisions. I found that it's very important to maintain alignment across various job functions and make sure that there is a shared understanding behind our product and decisions.
Next Case Study: NOAA Website Redesign
Next Case Study: Produce Trading App Design
Next Case Study: Produce Trading
App Design
Next Case Study:
Produce Trading
App Design
Next Case Study:
Produce Trading
App Design
Next Case Study: Produce
Trading App Design
I'd Love to hear from you!
I'd Love to hear from you!