ROLE
TIMELINE
8 months
TEAM
PM, API team, developers
SCOPE
IA, UX, UI, components
Open Gateway is Telefónica’s API marketplace, connecting businesses, developers and partners with standardised telecom network capabilities.
But the information was scattered and highly technical. Each audience had different goals and levels of expertise, and finding the right API took too much time and effort.
BUSINESS
DEVELOPER
PARTNER
I started by mapping every API, use case and resource. My first architecture grouped the content the way Telefónica’s teams were organised. When I walked through it as each type of user, it became clear it wasn’t how they would look for things.
THE INSIGHT
Developers usually know which API they need. Businesses start from a problem.
01 · FIRST ARCHITECTURE
Six sections, all at the same level
Open Gateway
Solutions
Finance
Retail
Marketing
APIs
Catalogue
Developers
Get started
Partners
Program
Resources
News
Events
Updates
Blog
Repeated across sections
02 · WHAT I FOUND
Four problems with this structure
01
Too much at one level
Technical content had no hierarchy, so nothing stood out.
02
Organised around the company
Sections mirrored the teams that owned the content.
03
One path for three audiences
Businesses, developers and partners navigated the same way.
04
No clear next step
Nothing led users from finding an API to integrating it.
03 · WALKING THROUGH IT
Every journey ended in a question
Business
Developer
Partner
Business. Three sections in, and still no clear answer to which API solves the problem.
Developer. Knew exactly what they needed, but the docs were split across three places.
Partner. Found the programme, then had to go back to see what they could actually offer.
DECISION 01
We discussed creating separate sites. I proposed one shared structure to avoid duplicating content across teams.
Trade-off: less personalisation for each audience.
DECISION 02
We also considered a search-first catalogue. Since most businesses don’t know API names, users filter by sector, service and country, and see where each API is available upfront.
Trade-off: search is no longer the main way in, though it stays available across the site.
DECISION 03
A consistent template for every API.
Business information and use cases come first, with Docs and Sandbox one click away for developers.
Trade-off: the same structure makes the catalogue easier to learn, although some pages end up with less content.
I worked side by side with the development team. From day one we had a simple prototype of the page structure, so we could validate the idea early. I then tested the three key pages in wireframes and designed the final UI with Telefónica’s design library.
HOW IT CAME TOGETHER
01
Content map
Every API, use case and resource in one inventory.
02
Prototype
A simple, clickable structure shared with dev from day one.
03
Wireframes
The key pages tested end to end before any visual design.
04
Final UI
Final screens built with Telefónica’s library.
05
Launch
Live at Mobile World Congress 2024, on a fixed date.
WIREFRAME → FINAL
The key pages, before and after.
Kept from the wireframe. One clear message and two paths: discover the value, or try the APIs.
Changed in testing. [What changed between wireframe and final]
Added in UI. [What Telefónica’s library added]
DESIGN SYSTEM
Telefónica’s brand, turned into components for APIs.
I started from Telefónica’s foundations and designed the components an API platform needed, following its brand guidelines. Few enough that every section could share them.
01 · FOUNDATIONS - FROM TELEFONICA´S LIBRARY
COLOUR
TYPOGRAPHY · TELEFÓNICA SANS
Aa
Heading
H1 · H2
OVERLINE
LABELS · NAV
Body text
BODY
ICONOGRAPHY·LINE
02 · COMPONENTS - DESIGNED FOR OPEN GATEWAY
BUTTONS
Filled for the main action, outline for secondary, text links to move around.
Blue for sectors, neutral for APIs. Same chip across catalogue, news and resources.
Clear states for what’s selected and how to undo it.
Entry by industry, for businesses that don’t know API names.
Where it works, what it solves and who it’s for.
How to join a programme, in four clear steps.
Open Gateway launched on time at Mobile World Congress 2024. Over its first four months, more people found their way from discovering the platform to the APIs and their docs.
API catalogue engagement
More users explored the catalogue and found relevant APIs.
Users reaching API pages
More users went deeper into the APIs and their documentation.
Developer Hub visits
More traffic to the Developer Hub and technical resources.
−17%
Drop-off during discovery
Google Analytics, first weeks after launch compared with four months later. Launch campaigns also played a part, so I read these numbers as a good sign of a clearer structure rather than a direct result of the design alone.
See the live site ↗
I’d test the journeys with external developers before launch, and agree on success metrics from the start. Today I’d also explore AI-assisted search: users describe their problem in their own words, and the platform suggests the right APIs and explains why they fit.
CONCEPT · AI-ASSISTED SEARCH · NOT SHIPPED
1.Describe. One open field instead of three filters, with examples to get started.
2.Understand. Each suggestion says why it fits, so the result can be trusted, not just accepted.
