| name | developer-experience |
| description | Improve developer experience by measuring the path from intent to working change, locating friction, reducing unnecessary cognitive load, and validating improvements with real users and delivery evidence. |
Developer Experience
Use when engineers lose time to setup, discovery, local environments, builds, tests, deployment, debugging, platform interfaces, or unclear ownership.
Procedure
- Define the developer population and the job they are trying to complete. Measure the actual path from starting intent to useful outcome instead of optimizing an isolated tool in a vacuum.
- Gather evidence from task timing, failed attempts, support requests, onboarding sessions, build/test/deploy telemetry, interviews, and repeated workaround patterns.
- Map friction by stage: discovery, access, environment setup, code navigation, feedback loop, testing, dependencies, platform usage, deployment, observability, and recovery.
- Distinguish unavoidable domain complexity from accidental platform/tooling complexity. The platform should absorb repetitive mechanics while keeping important system behavior understandable.
- Prioritize bottlenecks by frequency, time lost, error risk, and population affected. Do not chase cosmetic polish while a slow or unreliable core loop dominates the experience.
- Improve the default path using automation, clearer contracts, faster feedback, better errors, discoverable docs/examples, sensible defaults, and self-service access where appropriate.
- Keep escape hatches and diagnostics available. A paved path that hides all underlying state can make unusual failures harder to solve.
- Validate changes with representative developers performing real tasks. Measure before/after completion time, success rate, retries, support burden, or another relevant outcome.
- Instrument the experience enough to detect regressions as the platform evolves.
Decision rules
- Developer experience is the usability of the engineering system, not the number of internal tools.
- Faster local commands do not help if access, CI, deployment, or diagnosis remains the real bottleneck.
- Good defaults reduce decisions; they should not remove required control from advanced cases.
- Documentation should support the workflow, but recurring mechanical confusion may indicate a product/platform defect rather than a documentation defect.
Quality gate
The improvement is done when a real developer workflow becomes measurably easier or more reliable, the dominant friction is reduced rather than relocated, exceptional cases remain diagnosable, and telemetry or feedback can reveal future regression.
