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