Overview
Verizon’s API First initiative built a set of self-service developer portals, branded internally as “Hubs,” that let teams across the company and its enterprise partners publish, discover, and integrate APIs. The overarching goal was to maintain enterprise governance over API development best practices while eliminating redundant engineering by promoting efficient reuse across business units. The ecosystem grew over time. When I joined in May 2023, the work centered on the internal Hubs: a producer Hub for teams publishing APIs according to enterprise standards, and an authenticated consumer Hub for teams discovering and integrating them. Soon after, the initiative expanded to address a critical market need: a brand-new, public-facing developer Hub designed from the ground up to bring enterprise partners directly into the pipeline. During discovery for this public surface, we uncovered deep architectural silos across the ecosystem; unifying identity across all three surfaces became the central focus of my work on the project through December 2025.
I was the UX lead for the consumer Hub, one of three designers on the team, from May 2023 through December 2025.
PRoblem
Finding an API was never the hard part. Using one was.
The team designed against a five-stage consumer journey: find, evaluate, request access, use, and get support. Stages one and two are what people picture when they hear “developer portal”—a searchable catalog and good documentation. Stage three was where the experience broke down.
A developer would find the API they needed, read the docs, and then hit a wall. To actually call it, they needed permission from an owning team they had never met, through an opaque process with no visibility into whether the request was moving, stalled, or lost. The program was measured on time to first call. That handshake was where the time went. When teams faced weeks of administrative friction to consume an existing endpoint, they routinely opted to build redundant services from scratch, undermining the enterprise’s core goals of reuse and governance over standardized development practices.
There was a second, systemic problem discovered while designing the public portal from scratch. The existing Hubs had grown up as separate surfaces with their own notions of who a user was. A prospective partner arrived on a public marketing site, but everything of value sat behind authentication, and there was no continuous path from anonymous visitor to provisioned developer on a team with scoped permissions. Early technical and user discovery proved that retrofitting these legacy patterns would fail; the seam between public and authenticated was leaking the acquisition funnel, and solving it required a unified identity foundation built from the ground up.Role and Responsibilities
I led UX for the consumer Hub, covering the catalog, API documentation, and the access request experience. Working alongside product owners, security teams, and lead developers, I produced journey maps, user flows, high-fidelity prototypes, and design specifications, and presented work to senior leadership stakeholders.
The three portal leads sat on the same team with daily standups and split across Boston and India, which meant staying fluent in all three Hubs and covering for each other when someone was out.
Role and Responsibilities
I led UX for the consumer Hub, covering the catalog, API documentation, and the access request experience. Working alongside product owners, security teams, and lead developers, I produced journey maps, user flows, high-fidelity prototypes, and design specifications, and presented work to senior leadership stakeholders.
The three portal leads sat on the same team with daily standups and split across Boston and India, which meant staying fluent in all three Hubs and covering for each other when someone was out.
Catalog and documentation. I shipped a rebuilt catalog with advanced search and filtering, and documentation pages that presented request and response examples across multiple programming languages so developers could work in their own stack. Clear documentation and discoverability were essential to drive adoption of approved endpoints, ensuring engineering teams could easily inspect schemas, adhere to shared API standards, and reuse tested services rather than building duplicates. I also evaluated and implemented Scalar, a white-label documentation platform, to replace the existing approach and give the team a more maintainable, developer-friendly foundation.
Identity and access management. I led design on a unified IAM layer spanning all three Hubs, providing the connective tissue the ecosystem had been missing. Discovery revealed that trying to patch identity onto existing silos was unsustainable; instead, we designed the entire system from the ground up with identity as the primary anchor.
The design addressed three critical areas:
A continuous entry path: Connected the public Hub seamlessly through authentication into the product, ensuring prospective enterprise partners never hit dead ends.
Delegated administration: Established self-service team and user management, allowing organizations to create teams and invite developers directly rather than bottlenecking behind IT support tickets.
Granular access control & governance: Structured scoped, role-based access modeled on AWS permissions—attaching roles and policies to groups with least-privilege defaults and delegated approval authority. This upheld rigorous architectural governance without grinding developer velocity to a halt.
I built the journey maps and high-fidelity prototypes, worked the designs through exhaustive reviews with security and engineering, and secured sign-off from senior leadership. One key decision centered on density: Verizon’s brand standards specified generous table spacing, but the SMEs and developers administering permissions daily needed information density to review access efficiently without constant scrolling. Because misreading an access row risks serious permission errors, readability and data density were critical. I designed a balanced, high-density table layout that satisfied security audits while respecting core design system principles.
Designing inside constraints. Both efforts ran against hard limits: white-label platforms with real feature ceilings, and telecom security requirements that were not negotiable. A meaningful share of the work was sitting with security and engineering to find which compromises we could absorb without gutting the experience.
For example, legacy protocols initially required every user to download one specific authenticator app before accessing endpoints. For an external developer testing an API, that friction was prohibitive. We partnered with security to open the multi-factor step, validating users via email or third-party authenticator apps they already used (like Google Authenticator or Duo). At the same time, we aligned with security's decision to prohibit SMS verification, protecting the enterprise platform from SIM-swapping risks.
Results and Impact
The unified IAM framework and high-density permissions interface successfully cleared rigorous enterprise security and architectural reviews, earning full approval from executive leadership for development. By directly tackling the access bottlenecks, the new design provided the structural governance required to enforce API best practices and actively encouraged reuse across internal and partner teams. Alongside the IAM foundation, the Scalar documentation architecture was finalized and scheduled for rollout, establishing a complete, developer-ready specification and design system for the engineering teams to build directly against without ambiguity or scope churn.
Reflection
Most of what makes a developer portal good is invisible. Developers don’t remember a nice catalog. They remember whether they got to a working API call that afternoon or three weeks later, and whether integrating an existing service was easier than reinventing the wheel.
The interesting design problem wasn’t the interface. It was identity and governance. Who is this person, what organization do they belong to, what are they allowed to reach, and who decides. Everything else in the experience hangs off those four questions, including how much you can show a stranger before they sign in, which turned out to be as much a business decision as a security one.
That problem isn’t specific to APIs. Any organization putting governed capabilities in front of builders, whether internal teams, external partners, or both, runs into the same thing: governance only works when the path of least resistance is also the compliant one.
