Review

A short and accessible introduction to DX. The author does a good job of comparing and contrasting to UX. I hoped this book went deeper into the practical realities of doing discovery work in developer facing domains.

You Might Also Like:

Lean UX

In Lean UX, Jeff Gothelf combines Lean Startup, Agile, Design Thinking, and User Experience Design to create a collaborative and user-centered approach to product development. Lean UX focuses on reducing waste, fostering team participation, and adopting an experimentation mindset to achieve better outcomes. Instead of prioritizing outputs like features or documentation, teams are encouraged to focus on outcomes—measurable changes in human behavior that create business value. This approach allows for continuous learning through small, iterative experiments, where the emphasis is on solving user problems rather than building predetermined features. Ideal for product teams seeking a more agile, customer-centric method to deliver meaningful results.

andrewclark.co.uk

Book Review and Summary: Designing Machine Learning Systems by Huyen Chip for Product Managers

Get a comprehensive review and summary of the best-selling book "Designing Machine Learning Systems" by Huyen Chip, specifically tailored for product managers. Learn how to apply the key insights and takeaways from this must-read for tech leaders and professionals to your role as a product manager.

andrewclark.co.uk

Practical Recommender Systems

Recommendations have become an important part of most products. As such, Product Managers need a good understanding of the underlying technology. Although the theory can be complex, having an understanding of the tradeoffs and limitations of your system is crucial.

andrewclark.co.uk

Key Takeaways

The 20% that gave me 80% of the value.

Developers thrive in environments where tools, workflows, and APIs are reliable, intuitive, and efficient. A positive developer experience (DX) not only increases productivity and satisfaction but also drives product adoption, advocacy, and long-term value. Good DX involves thinking about everything developers touch: documentation, APIs, runtime environments, error messages, build tools, upgrade paths, and more. By anticipating developers' needs and eliminating friction, organisations can encourage deeper engagement and build a sustainable developer community.

A key reason DX matters is that dissatisfied developers will abandon tools that slow them down. In contrast, good DX creates faster feedback loops, intuitive interfaces, and supportive defaults—all of which lead to higher usage, better products, and happy end users. It also minimises common frustrations like slow build processes or unclear error messages. Overall, a solid DX strategy enhances the entire software delivery chain, influencing speed to market, team productivity, and business outcomes.

At the core, DX focuses on usability, credibility, findability, usefulness, value, and accessibility—similar to user experience (UX), but tailored for a more technical audience with longer, more complex journeys. Developers typically integrate multiple tools and services and may frequently adapt or reinvent their stack. They also operate in team settings, multiplying the impact of good (or bad) developer experiences. By implementing strong defaults, offering clear migration paths, and optimising iteration speed, a toolset becomes a natural extension of a developer's workflow.

To ensure a tool or service delivers good DX, it must be:

1. Usable: Straightforward to install, set up, and integrate, with minimal steps required. Documentation should be clear and comprehensive, including easy "Hello World" examples and advanced troubleshooting guides. APIs must be intuitive, well-organised, and provide immediate error feedback so that developers can diagnose issues without significant context-switching.
2. Credible: Reliable behaviour and consistency are essential. Tools should include backward compatibility where possible, clearly communicate deprecation timelines, and show a transparent roadmap. Developers trust systems that maintain security standards, stable APIs, and strong community support.
3. Findable: Developers need to discover information quickly—whether it's the initial product, a specific feature, or instructions for fixing an error. Easy-to-navigate documentation, active forums, live sample applications, and well-structured knowledge bases ensure time isn't wasted hunting for solutions.
4. Useful: The product must align with real-world developer goals, supporting the features, patterns, and workflows they actually need. Scalable architectures, best-practice examples, debugging tools, and performance-focused designs all help developers see immediate value and reduce the time spent reinventing solutions.
5. Valuable: Good DX ultimately saves time and money. Streamlined workflows, automated tasks, and integrated testing or deployment pipelines let developers focus on innovation rather than tedious setup. Tools become indispensable when they continually reduce friction and accelerate delivery.
6. Accessible: Different roles and working styles should be supported, from CLI aficionados to visual IDE users. Providing various options (plug-ins, language settings, light/dark mode, and so on) helps a broader range of developers feel comfortable. This also means supporting multiple operating systems or environments to remove adoption barriers.

Enabling a DX mindset involves having a clear vision, continuously measuring and refining experiences, and minimising friction at each step of the developer's journey. Onboarding is critical; the first few minutes can make or break adoption. Quick, hands-on tutorials and self-service setups allow developers to see immediate results and build trust. From there, a smooth path into deeper features ensures they remain engaged rather than looking elsewhere.

Measuring DX can be both qualitative and quantitative. Surveys, interviews, and usability tests capture direct feedback and help pinpoint pain points. Data such as build times, error rates, and feature adoption indicate where friction might occur. In addition, metrics like Developer Velocity highlight the connection between strong toolchains and business success, including faster releases, higher-quality code, and improved morale.

Successful roadmaps often begin with journey mapping—visualising the end-to-end path developers take from discovering a product to scaling it for production. Frequent "toothbrush" journeys (like daily builds or local testing) demand maximum convenience, while "pivotal" moments (like registration or version upgrades) need extra clarity to avoid dropout. By identifying these key stages and addressing the biggest frustrations, organisations can systematically improve experiences that matter most.

DX maturity tends to progress in four stages: initially suffering from poor practices, then recognising the importance of DX, actively applying its principles, and finally pioneering or innovating in ways that set new benchmarks. Central to this evolution is fostering a feedback-rich environment and embedding developer advocacy within product teams.

With AI's growing role, developer experience is poised to change even more. AI code completion and error detection can accelerate workflows, but they also require careful design to maintain trust, transparency, and control. Developers should be able to accept, reject, or modify AI suggestions without feeling coerced. Over time, as mental models of AI tools become clearer, the collaboration between human creativity and automated assistance will deepen, further streamlining the development process.

Deep Summary

Longer form notes, typically condensed, reworded and de-duplicated.

1. Introduction

• Developers appreciate it when the products they work with are reliable and easy to use.
• Make it easy for developers to find the right path to success.
• Setting developers up for success - and keep them using our tools.
• About the usability of APIs, documentation quality, development speed, production readiness, understanding of architectures, maturity of ecosystem and ease of debugging when things go wrong.
• DX: how easily and effectively developers can get things done.
• DX is how developers percieve their environment - and how they are affected by it in turn.
• Productivity and efficiency of developers (also clearer thinking)
• DX involves crafting tools, APIs and workflows to provide exceptional experience for developers
• DX: understanding developers, anticipating their needs and streamlining their workflows
• Good DX is about designing intuitive tools and workflows that help developers be productive and successful
• Measure quantitatively and qualitatively:
• Usability, accessibility, find-ability, credibility, usefulness and value

2. Why do we need DX?

• Unsatisfied and unhappy developers will give up on the products they are using and look for alternatives. Quality DX is no longer optional - it is necessary to remain competitive.
• Examples of good DX:
• Good Error Messages: HTTP codes. Or also. What happened, reassure, why it happened, help them fix it, give them a way out.
• Good DX is important because of its relationship to usage and adoption.
• Good Dx → Developer productivity & satisfaction → usages → referral
• DX is critical to the success of any product used by developers
• Good Dx → Build better products → Fewer issues → Happy End Users → More Usage
• DX: Understanding developers, what they need, what they value, their abilities and their limitations.
• What makes a Good DX?
• Enable them to get started quickly → optimise for fast iterations and feedback loops
• Change management / upgrades: limit blast radius of changes, make change opt-in, give notice, include automatic migration scripts, helpful error messages,
• Strong defaults
• Iteration latency - with slow development tools, the feedback may take time to generate.
• Low iteration latency can keep developers in flow and avoid switching contexts

Good DX typically looks like this... - You try for the first time, and you're able to do a hello world quickly - You see an error, and you're able to fix it yourself - You can try something without adding a credit card - You use an API, and it has all the params you need

• Developer Velocity Index:
• Top quartile DVI scores correlate with 4-5x faster revenue growth when compared to bottom quartile DVI scores.
• 4 Key Factors impact developer velocity and business performance are: tools, culture, product management and talent management
• Developer Velocity can impact:
• App Development: Time to market, Customer attraction and retention, Developer productivity
• Delivery: Competitive positioning/market share, Customer satisfaction metrics, Brand recognition/reputation
• Operations: Revenue growth, Developer recruitment/retention, Profitability
• UX should be the priority for application developers
• DX should be the priority for platform products (those that build tools and libraries for other developers to use)
• Good DX will encourage more developers to create and innovate using a technology.
• Good DX can enable a decent UX for those with worse devices and network connectivity.
• Good DX can create strong defaults that improve UX.
• DX may be reverse-engineering based on UX requirements.
• There is no need for DX to rival UX. Good DX should help enable good UX.
• Build Time (DX) vs Page Load Time (UX): A clever developer environment (with a different prod and dev setup) might be able to achieve both.
• Key Questions for good DX:
• What do developers want?
• What is their ideal experience?
• What are the factors that affect their coding style and efficiency?
• Areas of good DX:
• Tools and Languages
• Tools/languages/frameworks that work well together
• Auto code completion - immediate error feedback
• IDE: linting, formatting, documentation, debugging support
• Fast & complex code search
• Reliable, conflict-free dependencies
• Well-organised documentation and changelogs
• APIs
• Intuitive design with clear grammar
• Self-service with accessible documentation
• Interactive testing playground
• Clear error messages
• Instant, barrier-free onboarding
• Free tier for early adoption
• Clear SLAs and policies
• CLI/plugin testing tools
• Developer portal for monitoring and management
• Dev Environment
• 90% programming, 10% overhead time ratio
• Well-managed repositories with best practices
• One-click installation with configurable defaults
• Automated build, deployment, and operations
• Zero infrastructure bottlenecks
• Consistent behaviour across environments

3. What makes for good DX?

• UX: usable, useful, credible, accessible, findable, desirable, valuable
• DX = UX for developers
• Key differences between UX and DX:
• Developer journeys are longer and more complex, requiring continuous interaction with the product, while user journeys are considerably shorter and more predictable.
• A combination of tools not just a single app.
• Continuous reinvention of tools and best practice.
• The developer’s impact is somewhat scaled.
• Developers usually working in a team - multiplayer.
• DX often targeting expert/professional users.
• DX is about creating a collaborative environment where developers can be their most productive, impactful and satisfied.
• Productive: how quickly changes can be made
• Impact: friction from idea to production
• Satisfaction: how the environment, workflows and tools affect developer happiness

UX Principles and DX Interpretations

Hierarchy of Needs:

1. Functional - RESTful, JSON, OAuth
2. Reliable - Uptime, Latency, Infosec
3. Usable - Docs, SDKs, Demos, Changelog
4. Extensible - CLI, GraphQL, OpenAI, Webhooks
5. Enable creativity - API Explorer, surprises, merch

4. How do we enable a DX mindset?

Steps to enabling a DX mindset:

1. Establish a vision and principles for DX
2. Measure: qualitative and quantitative methods for measuring success
3. Implement: understand pain points, with data, journey maps
4. Refine: feedback loop to refine experience and maturity level

• Understanding the context of use, what developers need to complete their taks, what they value, underlying technology, integration points and focusing on how developers feel while using a product or service
• Onboarding is super important - you need a great initial 5 seconds, 5 minutes, 60 minutes
• You need developers to decide to invest further - its incredibly easy to walk away in the first instance
• Deliver value as quickly as possible - minimise initial expenses and smoothly spread costs over time.
• Two DX Goals:
• Increase value of the end state
• Reduce ramp up time (low friction, spread work in small increments over time)
• DX Principles:
• The developer should be in control: Allow developers to dictate their pace and provide resources that suit their individual learning style.
• Fast is better than slow: Prioritise speed and productivity by minimising wait times and measuring key metrics developers care about.
• Friction must be zero at T0: Make onboarding seamless with one-click setup and allow developers to start coding immediately without documentation or videos.
• Avoid turbulence in flight: Help developers take small, incremental steps with just enough information to progress without overwhelming them.
• Enable learning by doing: Provide hands-on experimentation opportunities rather than just reference documentation.
• Fight complexity at all costs: Don't let easy things become complex; when making complicated things easier, ensure developers maintain final control.
• Fight uncertainty at all costs: Provide clear guidance on getting started and next steps, with opinionated "one true way" approaches to reduce initial uncertainty.
• It's not enough to solve 80% of the problem: Focus on creating fully functional applications with real-world authentication rather than just scaffolding.
• Harness the power of cloud computing, where applicable: Leverage cloud for virtually limitless computing resources and easier team collaboration.
• Create magical moments: Design tools that feel "indistinguishable from magic" by reimagining products to deliver exceptional developer experiences.
• Create functional, reliable tools and APIs by applying UX principles to developer experience:
• Focus on utility by addressing core developer requirements
• Ensure responsiveness and performance, respecting attention span limitations
• Build credible, consistent tools that provide reliable outputs and predictable updates
• Design intuitive, simple interfaces with sensible defaults while allowing configuration
• Understand pain points to create innovative, delightful solutions (visual design, unique features)
• Create accessible documentation with tl;drs, diagrams, and release dates
• Maintain live examples through platforms like GitHub, CodePen, and Glitch
• Avoid bloat by minimising dependencies and limiting binary/installation size
• Design for interoperability across hardware, operating systems, and software environments

• Developer Relations:
• Be the first customer.
• Liaison for bi-directional feedback and comms
• Outreach and education
• Community management
• Don’t just think about your product: Product + Docs + Content + Community

5. How do we measure DX?

• Usability - Gather feedback from real users (Guerilla, Lab, Remote usability, interviews)
• Accessibility - Developer journey maps - note the challenges. Ask the community, conduct friction audits at different journey steps, analyse usage metrics.
• Find-ability - Finding the product itself, a feature or a workaround to an issue. Measure the time.
• Credibility - stable products with correct functionality - automated and manual testing.
• Usefulness - understand developer use cases, measure critical developer journeys.
• Value - number of paying users, repeat users, referrals and recommendations
• HEART: Happiness, engagement, adoption, retention, task success
• Developer Productivity - team velocity or features shipped.

6. Implementing a DX roadmap?

• Journey mapping visualises the end-to-end developer experience from their perspective. It helps understand how developers interact with products at different stages. A developer journey is defined by goals, roles, and contexts. Look across all the touchpoints.
• Types of journeys:
• Toothbrush journeys: Frequent and important interactions
• Pivotal journeys: Infrequent but important interactions (e.g., discovery, registration)
• A developer journey:
1. Discover: Developers find the product when looking for solutions
2. Evaluate: Developers analyse if the product meets their specific needs
3. Learn: Developers sign up and try the product through tutorials or sample apps
4. Build: Developers use the product for real-world use cases
5. Scale: Developers grow with the product and become part of the community

• Everyone in the DX organisation needs a shared mental model of the product
• Critical journeys should be identified through metrics like completion/abandonment rates
• Journey maps help identify friction points that can be optimised
• Try and prevent cognitive drain: reducing. cognitive load is crucial for developer engagement: try reducing choice through defaults and automating tasks.

7.DX Maturity Levels

1. Suffering because of bad DX: Products fail due to poor developer experience (low usage, adoption, and negative feedback)
2. Understanding DX: Organisations recognise DX importance and begin learning principles to reduce negative impacts.
3. Applying DX: Companies actively implement DX principles by tracking developer journeys, mapping needs, and enhancing products accordingly.
4. Pioneering DX: Teams share insights, create content, build communities, and become known for outstanding developer experience innovations.

8.Developer Experience and AI

AI and GenAI are transforming how developers build applications and products. Code completion, bug finding, testing and documentation are improving developer workflows.

The concepts that underpin human collaboration and teamwork should guide AI assistant design.

• Trust is built through consistently helpful interactions. AI suggestions must be contextually relevant, incremental, and explained. Reliability and predictable behaviour are essential. Systems should prioritise precision over quantity initially.
• Developers need time to build mental models of AI capabilities. Effective strategies include clear onboarding, customisation options, and transparency. Co-learning between users and AI creates mutual improvement. Design should leverage existing collaboration mental models.
• Control. AI should enhance developer autonomy, not restrict it. Developers must be able to accept, ignore, modify, or revert suggestions. Customisation and configuration options are essential.
• Interaction design should frame AI as a collaborative partner, not a superior

9. Conclusion

• Usable
• Intuitive, simple, and easy to use - Measured by time taken to complete a 'getting started' journey
• Developer-friendly documentation - Measured by time taken to find specific information on product use
• Responsive and performant - Measured by time taken to complete a task or journey
• Faster build times and smaller binary sizes - Measured by size of binaries, install size, download size, build time
• Credible
• Credible, consistent, and reliable - Measured by the number of issues in functionality or performance
• Interoperable and compatible - Measured through developer journey maps and friction audits
• Privacy and security - Measured by privacy and security legislation specific features or pain points
• Findable
• Engagement with the developer community - Measured by the number of positive user interactions on community forums or through blog posts
• Live examples for use-cases - Measured through interviews to check if examples corresponding to developer needs exist and time required to find something in the product
• Useful
• Useful in terms of functionality - Measured by tests and interviews to check if developer requirements are met
• Use field knowledge to guide developers - Measured by documentation for FAQs and best practices
• Valuable
• Tools for easy testing and debugging - Measured by points of friction that affect testing and debugging across frameworks and browsers
• Desirable
• Innovative and delightful - Measured by the number of users using the tool more than once
• Collaborate with other frameworks - Measured by the number of features developed in collaboration
• Accessible
• Accessible to different roles - Measured by number of unique developer journeys fulfilled successfully