# Design Developer Experience

> Design the developer experience for a platform, API, or SDK product. Use this skill when a team is building developer-facing products and needs to think through DX from a product perspective.

- Skill: `alexe-ev/design-developer-experience` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add alexe-ev/design-developer-experience`
- Raw SKILL.md: https://api.skillmd.com/api/skills/alexe-ev/design-developer-experience/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: alexe-ev (https://skillmd.com/u/alexe-ev)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/alexe-ev/design-developer-experience

---


# Design Developer Experience

## Purpose
Help teams design a developer experience that minimizes time-to-first-value, reduces friction in adoption and integration, and builds the trust that leads to long-term developer engagement.

## Skill type
Conceptual skill

## Use this skill when
- A platform, API, or SDK product is being designed or redesigned
- Developer adoption is low despite technical capability being available
- Onboarding for developers takes too long or requires too much hand-holding
- A developer portal or documentation experience needs to be structured

## Do not use this skill when
- The goal is API design itself (technical design — engineering-owned)
- The goal is internal developer tooling without external users

## Required inputs
- Developer product type (API, SDK, platform, data product)
- Target developer segment (skill level, use case, integration context)

## Optional inputs
- Developer feedback or support patterns
- Time-to-first-call data (if available)
- Competitive DX benchmarks
- Current documentation state

## Upstream context
Works best when:
- Platform product thinking is defined
- Target developer segment is clear

## Downstream handoff
Output can feed:
- plan-product-launch (DX is part of developer launch readiness)
- run-usability-testing (developer experience → usability study for devs)
- write-requirements-prd (DX requirements → product requirements)

## Instructions
1. Define the developer persona: skill level, context, integration goal, and time constraints.
2. Map the developer journey: discovery → signup → first API call → integration → production → expansion.
3. Identify the "hello world" moment: the fastest path to a working first result.
4. Design the documentation structure: getting started, guides, reference, examples.
5. Identify friction points in the current or planned experience.
6. Define the developer support model: self-serve docs, community, developer relations.

## Output
Provide:
- Developer persona(s)
- Developer journey map
- Hello world path (steps and target time)
- Documentation structure
- Friction points and proposed solutions
- Developer support model
- DX success metrics (time-to-first-call, activation rate, support ticket volume)

## Risks / caveats
- Developer experience is a product, not documentation — it requires the same product rigor
- Incomplete or outdated documentation is worse than no documentation
- Developer trust is hard to earn and easy to lose — reliability and accuracy matter more than polish

