Standardising and simplifying the API development workflow, so developers can design, test, monitor and publish APIs in one place.
Visit Rapid’s API Hub
I owned the developer tools experience at Rapid, from conception to release. I worked with product and engineering squads across three time zones to make the tools that developers use every day simpler and more effective.
Most of Rapid’s paying users weren’t technical, but a small group of experts drove half the revenue.
Non‑technical users
70%
of paying users
Seasoned API developers
5%
of users, generating around half of revenue
Any change had to make APIs approachable for newcomers without slowing down the experts.
API development covers a vast technical landscape with a steep learning curve, especially for people without a computer science background. Rapid’s tools already covered most of the workflow, but the architecture grouped features by what they were rather than what users were trying to do.
We ran remote tests with each user group and I turned the findings into empathy maps. They showed that moving between tasks in a journey was the hardest part. That led to our central hypothesis.
A goal-oriented architecture would help users finish tasks faster, and give us clearer sight of our conversion funnel.
The Customer Journey empathy map for Sarah Cox, a developer new to Rapid: how she felt at each stage of building an API, from her first project to testing, and the opportunities we found along the way.
Four principles guided every decision, and each one shaped a specific part of the product.
Onboarding and shared understanding. Curated API discovery reduced the need for prior knowledge, while search-led entry supported people who already knew what they wanted.
To meet developers where they work, the hub also had to live inside their IDE. Designing for Visual Studio Code meant balancing powerful features against an already busy interface, while respecting each user’s theme and interaction habits.
The Rapid API Hub inside Visual Studio Code: browsing recommended and popular APIs, then opening the NBA API’s endpoints, all without leaving the editor.
resources/images/rapid/discover.jpgDiscovering APIs in the Hub, with curated collections for newcomers and search for people who know what they need.
Design documentation for the API Hub in VS Code: the builder flow for unsigned, registered and paying users, endpoint screens for each, and responsive breakpoints. It let us build the extension with engineers, for engineers.
Guided progression. Step-by-step flows reduced uncertainty, and pre-configured requests sped up setup, so users could get from finding an API to making their first call without getting stuck.
resources/images/rapid/first-call.jpgPre-configured requests take people from finding an API to making their first call.
Clarity over complexity. Standardised endpoints built familiarity across APIs, and building requests inside the product simplified setup.
resources/images/rapid/testing.jpgBuilding and running API tests without leaving Visual Studio Code.
Adaptive experience. API linting offered simple entry points with advanced control when needed, and a consistent experience across the web, tools and integrations.
resources/images/rapid/linting.jpgLinting rules and results, consistent across the web and Visual Studio Code.
The empathy maps gave me what I needed to make the case to business leaders for redesigning the architecture, in staged releases that fitted a lean, agile way of working.
They also helped other product managers prioritise their own work. We fixed small issues in existing workflows while planning the bigger changes, so Engineering could keep shipping while Product and Design worked out the best path.
Handoff documentation for exporting logs as CSV, annotated screen by screen: the logs table, processing, log details and downloading exports. Built from existing design system components, work like this took days rather than weeks.
The current journey from testing locally in VS Code to becoming a subscriber, mapped across discovery, account creation and acquisition. Markers flag feature and strategic issues, which aligned stakeholders on where to focus next.
Our team was spread across San Francisco, Central Europe and Tel Aviv. Working well together took careful scheduling, the right collaboration tools and clear communication habits.
Working across so many perspectives and cultures made me more adaptable, and taught me to be deliberate about how and when a distributed team makes decisions.
The whole team in one time zone for once, at our 2023 kickoff in Marrakech.
After a year of iterative design, conversion rose 30% across every point in the workflow, from onboarding to monetisation, and across both core user segments.
Our IDE extensions had the highest daily active users of any of our platforms, reaching 100k users in their first week. In the Visual Studio Code marketplace, Rapid’s extension became the most popular that month.
Limited resources meant a short discovery period, so I focused on hypotheses with the biggest impact for the business. Accepting that I couldn’t master every technical detail at once helped me focus where design could add the most value.
Urgency and rigour were both core values at Rapid. Knowing when to move fast and when to slow down was what let us keep delivering value without cutting corners.
More dogfooding and more time with technical peers would have shortened my ramp-up.
Docs, dashboard and SDK examples each grew their own conventions. A shared pattern library would have made the product feel coherent sooner.
Regional teams served customers with different levels of API maturity. Closer collaboration would have caught more edge cases earlier.
Usability issues often reached us through support tickets. More frequent sessions with real customers would have caught friction sooner.
