Developer experience is UX where the interface is an API, a CLI, or a documentation site. When adoption is the KPI, the work is reducing friction, improving flow, and making the right path the easy path. I design developer-facing products that engineers reach for by default.
Who it's for
Teams building developer-facing products: APIs, SDKs, CLIs, docs, or developer platforms. The 'user' is an engineer, and adoption depends on reducing friction, not adding features.
Problems this solves
- Developers try your API or CLI once and don't come back—time-to-first-success is too long.
- Documentation exists but doesn't match how developers actually discover and use your product.
- Error messages, authentication flows, and onboarding create unnecessary friction.
- Your API surface has grown organically and lacks consistency—naming, pagination, error formats differ across endpoints.
What you get
- API or CLI interaction models with consistent patterns, naming conventions, and error handling.
- Onboarding flow optimization focused on time-to-first-success and progressive disclosure.
- Documentation architecture that matches developer discovery patterns (search, browse, reference, tutorial).
- Friction audit with prioritized improvements based on developer feedback, support data, and adoption metrics.
How it works
Typically 3–6 weeks. Starts with a developer journey audit (onboarding, first call, error handling, advanced usage), identifies friction points through developer feedback and usage data, and produces interaction models and documentation architecture. I build working prototypes when that accelerates validation—including CLI prototypes.
Proof
Frequently asked questions
- Do you write the API documentation?
- I design the documentation architecture and write key reference pages, getting-started guides, and error reference. For large-scale docs, I establish the structure and style guide that your team or technical writers can follow.
- Can you work with our engineering team on API design?
- Yes. I work directly with engineers on API surface design—endpoints, naming, pagination, error formats, versioning. The goal is consistency and developer ergonomics, not just functionality.
- What makes this different from a regular UX engagement?
- The "user" is a developer, and the "interface" includes APIs, CLIs, error messages, and docs—not just screens. The evaluation criteria are different: time-to-first-success, cognitive load, discoverability, and whether developers reach for your tool by default.
Start a conversation
Describe your constraints and the decision you need to make. I'll tell you if I can help.