Seve Kim

Case Study: Developer Onboarding Redesign

First published on

Project Overview

Problem Statement

Developers need a way to quickly access, test and integrate with our API. Developers will submit a form waiting for the business development team to reach out and approve them with the possibility of receiving access to their API key.

This leaves access up to the availability and discretion of the business development team member, leaving developers to wait days if not weeks to try the API out.



Collect Baseline Metrics

Our API usage was not instrumented prior so it was challenging to gather baseline data. We instead built our TTFHW metric based on time when the account was first created to when the first API request was logged.

Usability Testing Existing Flow

Started by understanding how the existing user flow by observing new engineering hires to undergo the flow. Users were provided a prompt of navigating to the website with the goal of testing out the API.

Define User Journey & Pain Points

After taking note of users, screenshots were taken of the existing paths that were taken for users to achieve their goal of testing out the API. Pain points were highlighted along the user journey.

Stakeholders from the Business Development team had made the decision to request gating access to the API only after scheduling a call with the sales team. After understanding their needs, we had agreed that providing limited non-production access was feasible so long as an upgrade path was easily accesssible after testing.

Created Product Requirements Document (PRD)

After identifying the opportunities from observing developers attempt to onboard, I created a PRD to highlight these challenges, what requirements were raised from stakeholders such as engineering, legal and sales.

Competitive Analysis

Reached out and spoke to vendors that


Developers were provided self-serve access to sandbox API keys, increasing unique API key holder growth & TTFHW.