01
Overview
Documentation is the most important product an API-first company can build. At Stytch, as the company scaled and released new features, the docs couldn't keep up — they'd grown organically into something that was hard to navigate and didn't answer the questions developers actually had. I led a full rethink of the documentation experience, from surface-level UX improvements to a net-new Docs Home that made Stytch's value proposition immediately legible to any developer landing for the first time.
Impact
For an API-first company, documentation isn't a support resource — it's the product. Developers evaluate whether to build with Stytch almost entirely through the docs. If they can't quickly understand what Stytch does, how to get started, and whether it fits their stack, they move on.
As Stytch's product surface grew, the documentation became harder to navigate. Information was buried, key evaluation questions went unanswered, and the structure didn't map to how developers actually approach a new tool — first scanning for fit, then digging into integration.
"As a developer, all that matters is docs. New company? Bad docs? Don't care." — Research participant
I conducted research with Stytch customers and ICP participants to understand the specific questions developers need answered at each stage — evaluation, integration, and ongoing reference. The research surfaced two clear failure modes:
These two problems required different solutions, which shaped the strategy for how I approached the project.
Rather than wait for a full overhaul, I sequenced the work into milestones that could ship value independently. First, I addressed find-ability with targeted UX improvements: a new search experience, in-page linking, breadcrumbs, and updated navigation labels that matched how developers think about authentication and fraud — not how Stytch internally organized its products.
These changes gave developers better tools to locate what they already knew they needed. But they didn't solve for the developer who arrived without a clear entry point.
The bigger unlock was designing a net-new landing experience — a Docs Home — for developers arriving for the first time. The goal was to answer "what is Stytch, and can it solve my problem?" before sending anyone deeper into technical content.
I designed it around patterns developers already recognize from other developer platforms: product overviews, quick-start paths, and decision frameworks that help them self-select into the right integration path. It had to sell Stytch — clearly, quickly, without feeling like marketing — while immediately connecting to actionable next steps.
After launch, navigation increased significantly across all core product verticals. The most meaningful movement was in quickstart navigation — the clearest signal that developers were arriving, understanding the product, and taking their first step toward building with it.
Qualitative feedback from customers confirmed that the experience felt clearer and more legible. The response from one customer said it best:
"New docs look slick."
This project made the case internally that documentation design is a direct lever on developer acquisition — not just a support function. By treating the docs as a product with its own user journey and conversion goals, we unlocked meaningful improvement in how developers evaluated and adopted Stytch.
It also established a foundation that the team could build on: a clear structure, consistent navigation patterns, and a home page that could evolve as the product did.
Key Decisions
Fix navigation vs. rethink the entry point
Research surfaced two distinct failure modes: findability (developers can't locate what they need) and evaluation (new developers have no good place to land). Rather than choosing one, I sequenced the work — ship targeted UX improvements for findability first, then build a net-new Docs Home for evaluation. This delivered value early while setting up the bigger unlock.
Sell without feeling like marketing
The Docs Home had to answer "why Stytch?" before sending anyone into technical content. But developers are allergic to marketing copy. I designed it around patterns they already recognize from other developer platforms — product overviews, quick-start paths, decision frameworks — so it felt informative rather than promotional.
01