Tech writing can be full of more lingo than an insurance convention. It can feel impossible to decipher, let alone master each micro-discipline. DX and UX, which stand for developer experience and user experience, respectively, are particularly impenetrable, as two small letters don’t even give enough context to offer insight into how they can literally make or break a tech product.

Let’s start with some definitions. Understanding what DX and UX are will help to dispel any confusion. Then we’ll wrap up with a side-by-side comparison, which should answer “how is DX different than UX?” once and for all.

What Is DX?

The question “what is DX?” is particularly thorny, which is part of why answering the “how is DX different than UX?” question is so confusing. It requires some disambiguation, as several acronyms use the same abbreviation. In our context, it doesn’t mean ‘mod X,’ which is how DX is used in math. It’s not ‘digital experience,’ either, although that’s closer to the meaning you’ll likely encounter when reading about APIs and API-consuming products. It’s not digital transformation, either, although focusing on developer experience can help create a transition to digital business models.

For developers and programmers that use their APIs, DX stands for ‘developer experience.’ Developer experience refers to the developer’s journey with a piece of software and the degree of friction they experience while using it. Microsoft defines developer experience as as “how easy or how difficult it is to perform essential tasks to implement a change.” They break DX down into four main stages:

• Build: Verifies that changes are error-free and can be compiled.
• Test: Verifies that all automated tests can be passed.
• Start: Ensures every component can be launched via simulated execution in a deployed environment.
• Debug: Includes a tool for detecting and correcting any errors.

Microsoft’s definition of developer experience is adequate for a general understanding of DX. Yet, API developers and consumers have specialized needs, which means API developer experience deserves its own explanation. NGINX defines API developer experience as as “the overall perceptions and emotions a developer has while interacting with an API.” They list infrastructure, tools, processes, and support as key components to API developer experience.

What Is UX?

Now, let’s take a quick look at UX to better understand the difference between UX and DX. UX stands for user experience, which Nieman Group defines as “all aspects of the end-user’s interaction with the company, its services, and its products.”

User experience takes every aspect of an end-user’s interaction with a product or service into account. Everything from the user interface (UI) to the backend performance and marketing materials play a part in UX. For a product to offer exceptional UX, information architect Peter Morville talks about the UX Honeycomb. According to the UX Honeycomb, a product should meet seven criteria to deliver exceptional UX.

The UX Honeycomb. Image credit: @semanticstudios

How Is DX Different Than UX?

As we have seen, DX is a specialized branch of UX. If UX is the genus, DX is the species, with its own unique strengths, weaknesses, and needs. With that being said, DX and UX are intricately intertwined, as focusing on the developer’s experience can also help you deliver superior end-user experiences.

In some regards, DX is more demanding that UX, though. Developers have much more demanding requirements and rigorous standards, for one thing. 99.999% uptime, for instance, is even more important for developers than general users since they depend on your API to power their own products and tools and integrate with other applications. You need to keep all of these things in mind when dealing with DX.

In reality, you can’t slack on either UX or DX. General design principles, like those laid out by AMP, state the order of importance to be ‘User Experience => Developer Experience => Ease of Implementation.’ That’s why it’s important to distinguish who will be consuming your service. In the case of API products, developers are the users, so the two terms are essentially synonymous.

Ways to Improve Developer Experience

Creating materials specifically for developers lets you assume a higher level of technical proficiency than if you’re creating products for a general audience. Creating onboarding materials that take brand-new users with zero tech experience to high-level data scientists, analysts, information architects, and developers with years of experience is incredibly challenging. Although you don’t want to get too complicated, it should be safe to assume that developers working with your API will have a higher level of technical proficiency than someone picking up a smartphone for the first time or sending their first HTTP query.

To truly differentiate how DX is different than UX, it’s useful to listen to that specific audience. Spend some time where your core user base is hanging out, like GitHub, for example. Ask specific questions, like what languages they’re using, what libraries they’d like to see, what integrations they’d find particularly useful, and the like.

This brings us to another core difference between UX and DX: developers are more likely to be using multiple environments. If you’re creating tools for developers, it’s a good idea to include SDKs and code samples for the most popular programming languages and development environments. You might also consider creating tools and resources for popular development and testing environments.

Considering there are over 20 million Postman users, it’s a safe bet that it’d be worth your time to create a Postman collection to help developers effortlessly integrate your API. You might ask about how they intend to use your API, as well. If you know how developers plan to use your API, you can create demos to showcase your API in action in helpful ways.

Which brings us to another distinction. It’s even more important to facilitate a healthy community for developers using your API. It needs to be as easy as possible for developers to report bugs or ask for features they’d like to see. It’s also important to respond to concerns and requests as quickly as possible when dealing with DX. While listening to customers is always important, it’s particularly important with DX. As developers are creating their own tools and products that use your API, there’s likely more money on the line than with individual users. Every developer potentially represents a major revenue stream. Respond accordingly.

Final Thoughts On DX Vs. UX

As we have seen, DX and UX are like squares and rectangles. Every square is a rectangle, but not every rectangle is a square. In other words, DX is UX, but it’s a highly specialized form of UX with its unique demands.

To summarize, it’s safe to assume that developers using your API will likely be more technically savvy than if you were designing products for a general audience. It should be safe to use slightly more advanced language in your onboarding materials. Instead of creating tutorials for every experience level, you can focus on making your onboarding materials even more targeted, usable, and valuable. You want developers to be able to get up and running with your API as quickly as possible. The slightest stumble could cause them to look elsewhere, losing you a valuable long-term customer in the process.