Developer Tooling

What this is

At Circle I led experience strategy and design across the developer journey: Circle Docs, Arc Docs, sample apps, App Kits, and the emerging AI building tools. Arc Studio is its own case study; this one is about the system it sits inside.

What began as an effort to improve documentation became a broader redesign of how developers discover Circle’s products, understand what they can build, find the right implementation path, and move from learning into working software.

Over the course of the work the audience itself changed. Docs were no longer consumed only by people. AI agents were increasingly using them as an input to software development, and by October 2026 they were generating almost twice as much traffic as humans on Arc Docs.

The problem

Circle had powerful developer products, but the experience of understanding and adopting them was fragmented. Developers hit too many undifferentiated entry points, unclear relationships between products and SDKs, duplicated guidance, navigation organized around Circle’s internal product structure rather than developer goals, examples that varied wildly in completeness, and weak transitions between learning about a capability and actually building with it. Docs, developer tools, samples, and AI experiences all operated as separate surfaces.

The result was a gap between interest in Circle and successfully building with Circle. I started by understanding that gap through actual developer tasks rather than individual pages or products.

Reframing the developer journey

I developed a developer experience framework centered on what someone was actually trying to accomplish. Instead of asking developers to understand Circle’s organization first, the experience helps them move through a progression:

That led to the principles that shaped everything after: organize around developer goals; recommend clear paths rather than presenting every option equally; prioritize runnable examples; expose complexity progressively; clearly distinguish production-ready resources from demos and experiments; connect documentation to the tools required to complete the task; and make AI-generated output understandable, editable, and grounded in reliable context.

The platform decision

One of the first major decisions was the documentation platform itself. I evaluated Mintlify, Fern, and GitBook across developer experience, authoring, customization, analytics, AI capabilities, integration requirements, and migration effort, and recommended Mintlify. Then I worked through the implementation with the team: providing designs, reviewing vendor work, identifying gaps between the intended and implemented experience, and establishing the visual and interaction foundation for both Circle Docs and Arc Docs. Circle Docs migrated in November 2025.

The platform choice mattered beyond the redesign: it gave the team analytics and feedback loops we hadn’t had.

Redesigning how developers find the right path

Working with technical writing and Product, I redesigned the information architecture around developer activities rather than product categories. Instead of needing to know which Circle product they wanted, developers could start from a goal: accept payments, create wallets, move assets across chains, manage gas, deploy an application, test an integration. Product-oriented navigation stayed available for people who already knew what they needed.

The homepage and navigation were deliberately an incremental step: clearer entry points and a use-case structure without requiring the entire documentation corpus to be rewritten first. I carried the same approach into Arc Docs, where the implemented experience included a new navigation structure, use-case cards, workflow entry points, common tasks, overview pages, and AI tooling.

Agent paths where intent is highest

The programmatic paths (skills, the MCP server, Studio’s CLI) existed before this work, but nothing surfaced them where a developer was actually deciding how to build. The redesign placed them at those moments instead of on a separate “AI” page:

• On the docs homepage, “Start with skills” and “MCP server” sit beside the human entry points, so an agent-driven setup is a first-class way in rather than a footnote.
• On “Build on Arc”, a “Build with AI” rail (Studio, Studio CLI, Skills, MCP) appears next to the quickstarts, at the point where someone has chosen a goal and is picking a path.
• From a sample app or quickstart, a contextual prompt launches straight into Origin with the page’s context, so the handoff into an AI building tool starts from what the developer already read.

The same product, reachable through a human door and an agent door, placed at the same decision point.

Designing documentation for agents

As AI coding systems became a larger part of the developer workflow, docs stopped being only an interface developers read. They became an information layer consumed by software that needs to understand Circle’s products well enough to act.

The broader team introduced the machine-oriented infrastructure: llms.txt, product-specific agent entry points, token-optimized content. My work was the experience architecture around it: how agents discover the right information, how examples and skills should be structured, and how machine-oriented content connects back into the developer’s workflow.

I also worked directly on agent onboarding. I created and tested an initial set of developer recipes and found that separating capability-oriented skills from task-oriented recipes confused the agent I was testing. I proposed combining capability discovery with relevant workflows so an agent could understand both what Circle can do and how to use it for a task: information architecture for an AI consumer rather than a human one.

Making examples part of the product

Examples were another major weakness. A sample could be a production-ready starting point, a half-implemented demo, a component, or an experiment, and developers had no way to tell which. I created a framework distinguishing maintained sample applications, starter components, demos, and experiments. For each, the expected audience, ownership, maintainability, setup guidance, metadata, functional completeness, and where it should live.

I also mapped the full adoption journey for SDKs like StablecoinKit, from discovery and fit assessment through installation, customization, and testing. The goal was to make examples a trusted part of implementation rather than supplementary inspiration. That work later became the redesigned sample-app experiences in Arc Docs.

Connecting learning directly to building

The largest evolution came from questioning why documentation and the building environment needed to be separate at all. People arrive wanting different things (a specific answer, a sense of what they could build, something to browse, an example to start from, or to prototype immediately) and I designed an integrated experience that connected those intentions instead of forcing everyone down the same path.

I built a working prototype (Figma Make and Vibe Box) that demonstrated homepage → use case → quickstart; use case → sample app → remix in Origin/Studio; docs search → AI answer → contextual building session; guided paths for building an app, creating integration adapters, customizing samples, and writing contracts; and embedded actions like wallet connection and testnet funding. It included reusable homepage, use-case, quickstart, and sample-app templates, plus a context system that simulated appropriate AI responses, implementation plans, and generated code for each workflow.

The prototype turned a broad vision into something Product and Engineering could experience, critique, and start implementing. I also built a feedback system into it: reviewers could comment on the overall concept or select a specific element and leave targeted feedback, categorized into a dashboard. That interaction model was later picked up as inspiration for commenting in prototyping tools used beyond this project.

Vision to production

This wasn’t strategy and prototypes only. I worked with technical writing, Product, and Engineering to move the direction into production: phased delivery plans, content requirements, use-case prioritization with Product, technical dependencies, implementation review, visual and accessibility QA, and contributing CSS and production styling directly to the docs repository.

Shipped: redesigned Arc Docs IA; new homepage and workflow navigation; section overview pages; use-case entry points; common-task navigation; AI and MCP entry points; embedded faucet; redesigned sample-app experiences; contextual Docs-to-Origin handoffs; visual and dark-mode improvements across both doc sites.

Impact

Arc Docs saw substantial developer usage after launch, and Product leadership reported positive feedback on its usability and workflow. By October 2026, Arc Docs was receiving almost twice as much traffic from agents as from humans.

That doesn’t establish that my work caused the growth in agent traffic. It does establish something strategically important: documentation had become infrastructure for AI-mediated software development, which validated designing it for agents discovering, interpreting, and applying information, not just for people reading pages.

The organization later set business targets around developer activation, sample-app adoption, App Kit installs, new builders, and applications launched on Arc. This work built the mechanisms those targets depend on.