Developer Experience vs. User Experience

While they may seem similar at first glance, Developer Experience (DX) is not just “User Experience (UX) for developers”. Rather, DX is an extension of UX focused on users who build with technical languages and tooling. DX follows the same core principles of UX but extends it by recognizing that technical details and mechanical processes can be understood and utilized efficiently by a developer.

Great DX happens when developers feel they are being spoken to and having their needs met directly. This means showing code, providing lots of detail, and giving clear instructions for multiple use cases.

User experience is a set of general principles most commonly applied to end-users, who may be non-technical and use software for both business needs and personal consumption. Developer experience is focused on enabling developers to use software to build solutions. The distinction between UX and DX comes from the different needs that end-users and developers have. In this article, we’ll explore what good UX and DX entail, the key differences between them, and the practical differences when you develop products for developers.

Great DX Starts With Principles From UX

Good UX has two components: make it easy to start using your product, and ensure it’s enjoyable to continue using it. Developer experience extends these same core ideas, applied to a goal-oriented technical audience.

First, make it as easy as possible to start using a new product. In UX generally, this means avoiding sign-up flows if possible, or keeping them simple when they are necessary. Products should be intuitive - an end-user or developer should be able to start using your product and achieve their goals with minimal instruction. It is also crucial to remember the value your product is providing. You can use some of the same tools to evaluate UX and DX, like A/B testing, user surveys, and analytics software.

The first key difference between UX and DX is the user journey. Good UX keeps the user journey for your product as straightforward as possible. Too many choices can be overwhelming for end-users, which can make it harder to accomplish a task and get value from a product. Good DX needs more flexibility to enable many different possible developer goals. Similarly, while end-users don’t need technical details to successfully use your product, developers need access to detailed information so their requirements can be evaluated. Good DX makes it easy for developers to understand how a product or service works so they can build with it successfully.

While good UX makes a product equally accessible to users with different technical capabilities, DX should take different users’ technical capabilities into account and offer different levels of support. More experienced developers want access to more powerful tools, while less experienced developers may need to start with a simpler workflow that may be easier to configure. It is important to understand what level of technical ability your primary users have in order to make your developer experience better fit your products.

Now that we’ve compared the high-level differences between developer experience and user experience, we’ll take a look at an example of an application that shows the difference in practice.

UX vs. DX - A Practical Example

Let’s walk through what UX and DX would look like in the real world.

Most of us have probably been end-users of a consumer shopping app. Imagine a user on a new shopping app for the first time, looking for a new sweater. They might enter a search term, “sweater”, in a search box, or click through category navigation. Then, they would select the sweater they would like and add it to their cart. To check out, they might have to create an account with billing and shipping information, or they might simply click “Pay with PayPal” and let the site handle the rest. All our user needs to do now is wait for their sweater to arrive.

Now, imagine a developer building the same functionality into a new app. Leaving aside any APIs used for search functionality, they would have at least one API to handle authentication and billing, and likely more. First, they would have to install any required libraries or SDKs and resolve dependency issues. Next the developer would generate an API key and it to the app’s environment variables for reusability. Then the developer would write the API call to the authentication endpoint for the user, and write a listener that confirms the user has been authenticated. The next step is writing a call to the app’s backend that confirms there are still sweaters available, and an API call to process the payment. Finally, if the payment is successful, the developer should write code that listens for a response from the API, updates the backend to remove a sweater from the inventory, sends information to a fulfillment center, and schedules a package for delivery.

For a developer to succeed in building this app, they need to understand which API endpoints to use, what methods are allowed at different endpoints, what responses to expect from the API, and how to securely authenticate API calls with an API key. Without good DX, developers may quietly drop your product at any point if they can’t resolve problems quickly, or may never attempt implementation at all if they’re not confident they can succeed.

Just as consumers have a lot of choices for sweater shopping, developers have a lot of tooling options. Making yours a compelling choice starts with good DX. Developers will choose your product if they feel confident they can use it, and they will keep using it if they feel successful.

Great developer experience starts with knowing developers’ unique needs as users. In the next section, we’ll look at how general UX standards apply to developer-facing products and how you can tailor them to a developer audience.

Unlock API Product Value With Good Developer Experience

Developer experience encompasses what happens when a developer interacts with your service or product when they are building. Developers want to feel empowered to create and innovate, and good DX helps them see the possibilities and the steps to achieve their ideas. You need to set up a developer experience that inspires confidence, and then monitor to ensure your users are succeeding and expanding their integrations.

Let’s take a more detailed look at the features of good DX and how they are often implemented in practice.

Developers need to be able to configure the services they use to fit a variety of workflows. A linear user journey is less than ideal because it doesn’t reflect how developers work or how applications are built. Great DX provides the tools and information to support flexibility, so your product should support different configurations whenever possible. Good ways of accomplishing this include:

• Provide a range of well-scoped API endpoints
• Develop SDKs in multiple languages
• Split code into smaller reusable methods
• Create readable jargon-free code
• Document your product extensively

It is essential that you give developers enough information to understand the technical details of your product.

Your documentation is a developer’s entry point to your product and informs their decision to implement it. If developers can understand how your product works, they can confidently implement it in their workflow. You need clear, up-to-date, and thorough documentation so that developers can learn how to use your product, troubleshoot problems, and integrate it into their existing workflows. This is particularly important if you build your product for developers with different skill sets and levels of expertise.

Ultimately, developers need to feel like you understand their pain points and that your product, tools, and documentation address them. With good DX, any developer should be able to set up a basic implementation of your product with minimal instruction. More experienced developers should feel confident extending the functionality of your product to fit unique use cases. You can accomplish this by showing example code, providing detailed explanations in your documentation, using API analytics to understand how developers use your API, and demonstrating clear examples for multiple use cases.

Developer Experience: Beyond First Impressions

Retaining developers requires more than first impressions. Just as good UX needs to be evaluated, refined, and tested over time, good DX is an investment in the long term. You won’t know how well you’ve succeeded without using analytics to evaluate your DX and test changes. Monitoring your API helps you identify users who have not been able to successfully make API calls, find patterns of success and failure for developers, and see how different users are engaging with your product over time. While tracking UX metrics is relatively straightforward for products focused on end-users, DX metrics differ in important ways. You need to develop a good strategy for API analytics so that you track relevant business value metrics while avoiding vanity metrics.

While developer experience shares many key aspects of user experience, it is important to remember that developers have specific needs that go beyond standard UX principles. You need to understand DX when you build products for developers so that you can attract developer users, inspire their confidence and creativity, and support their increasingly complex integrations over time. Building good UX and DX can be challenging, but with the right analytics stack, you can monitor your API and use metrics to craft the perfect API developer experience.