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
- Define the developer persona: skill level, context, integration goal, and time constraints.
- Map the developer journey: discovery → signup → first API call → integration → production → expansion.
- Identify the "hello world" moment: the fastest path to a working first result.
- Design the documentation structure: getting started, guides, reference, examples.
- Identify friction points in the current or planned experience.
- 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