A Fresh Look at Developer Experience (DX) in 2020

While a lot of attention gets paid to creating effective user experiences (UX) in software products, much less attention is typically paid to the developers' experiences.

User experience is very important, but incomplete as a means for completely satisfying business requirements. Users experiences, today, are inter-product, and therefore how/where those users transition between  products is important. Developers' interactions with APIs, among other things, influences how those inter-product user experiences go.

In this post we'll dive into developer experience, including what it is, how it impacts users, and how it's evolving.

What is Developer Experience (DX)?

Put simply, "developer experience" represents the same ideas applied in the user experience (UX) domain, but applied to the specific tech-focused audience that works with the back-end of your software (mainly APIs).

Usually when a product team talks about "users" and their experiences, they are talking about people interacting with the user interface of an application--the web app, the mobile app, the Alexa commands, etc. An effective user experience helps the user receive the desired benefit from the product with minimal friction.

In this traditional user experience context, the product team creates these interfaces (screens, chatbots, terminals) to wrap complex underlying logic--often business logic--in simplicity. For example, if you are filling out an application for health insurance, there is probably a whole series of decisions and calls to different data services happening behind the friendly application you see on the web browser. The product is built such that the way you experience it as a user is more friendly than what is actually happening under the hood.

However, there is another constituency who "uses" the product in ways that are different than a typical end user. Developers who build software that talks to a product through APIs, web services, and other means work with the underlying system more directly. When most people are driving the car, these folks are plugging things into the engine.

Developer experience as a domain is considering how effectively that group of people are empowered to accomplish their goals. It's different from user experience, because it targets a specific, more technical group of people who have a set of goals very different from that of the end user.

Why is developer experience important?

Your user's experience with your product extends beyond your product. Software doesn't exist in a vacuum. You are one tool in your user's toolbox, and they use all of those tools to get their job done.

It isn't good enough to just have a great user experience within your product. You must provide a great user experience on edges--the place where your product and its features overlap (or blend...hmmm) with those other products' features.

In other words, your ability to enable, assist with, and support integrations or customizations has direct impact on your user's experience. Developer experience is how you enable this. (We'll focus on integration, because that's what we do.)

Integration is a pretty tech-heavy thing to get done. You don't have to write code to accomplish it anymore (more on that later), but traditionally it was a task assigned to a developer/engineer. Hence: developer experience is that person's ability to build integrations that build effective inter-product user experiences.

A poor developer experience impedes the developer's ability to integrate your software and its user experience. An effective developer experience makes it easier and faster. It frees up the developer for critical thinking about creating an above and beyond user experience instead of spending cycles on frustrating, avoidable issues.

In a world where your user's experience is necessarily unbound by the edges of your product, developer experience is fundamental to improving the user's overall experience.

What does an effective developer experience look like?

Much has been written about what an effective developer experience looks like. This article contains some good links to dive into these ideas further--especially the one about different developer personas.

Developer experience is a big topic that we'll cover from many angles in this blog. At a high level, an effective developer experience looks like the following:

• It reduces unnecessary friction for the integration developer. Documentation is comprehensive and complete. APIs and web services are reliable and predictable. Data in and out is consistent. Anything unexpected or secret adds friction and usually frustration.
• APIs/web services adhere to commonly understood and ideally best practice standards. HTTP APIs that respect the values of REST allow developers to imply more about your API, reducing their reliance on documentation. (Note: documentation is still necessary.)
• It balances the simplicity of limited functionality with the optionality of robust functionality. This is a tricky balance, but if APIs are too restrictive they limit value that can be derived from integrations. If they are too robust, the complexity slows innovation by adding difficulty.
• The documentation, community, resources, and even the APIs themselves inspire developers to add value around your product. The strongest ecosystem hub software companies understand the value of cultivating a developer culture around their products.
• It is backed by a community. Software products backed by communities that are empowered by paid employees at the software company tend to have evolve faster, learn with their ecosystem of developers, and understand the demands of that constituency.

Some good examples of companies that provide a pretty effective developer experience include:

• Shopify - Well documented, predictable APIs. Multiple versions of developer communities. Limited out of the box features and reliance on development partners to add value to the product. Almost zero friction to becoming a technology partner.
• Stripe - Built as an API-first product with really robust documentation, chock full of examples. Lots of resources put into building the developer community, which is critical to the company's growth.
• Slack - There is a huge culture of people building into Slack's ecosystem. They've done a really good job using that asset to expand on the fairly limited out of the box feature set.

How Developer Experience is Evolving

The name "developer experience" states quite clearly that the people doing the integrations or customizations are in fact developers. These days that reliance on developers is waning.

The last five or so years have produced a bunch of low-code or codeless technologies that allow tech-savvy non-developers to build integrations, user experiences, and software products.

For example, most integration platform as a service (iPaaS) products are low-code environments for moving data between APIs. They don't require developers to set them up--to actually enable an integration. This means other personas get to participate in creating inter-product experiences. Often these means business users with domain expertise, better understanding of the customer, or just different perspectives due to different backgrounds.

Some the same principles apply for non-developers: the API should be consistent, well-documented, etc. But, when you must factor non-developers into the equation, you have to expand your developer experience to other, previously irrelevant personas.

Oh, by the way, developers are still super important! They still do a huge amount of customization and integration. That means you can't abandon them for the new personas. You've got to expand and be inclusive.

Is "developer experience" the right term?

This begs the question: is "developer experience" even the right term to use anymore?

For now, we aren't in the business of trying to change an industry's vocabulary, but as we continue down this path, the term "developer experience" is less and less correct.

The future of software will include mesh-like networks of connected software. That connectivity will be organic and decentralized. Your product team will be required to produce something that can participate in a dynamic ecosystem where you can't predict, force, or dictate how your product is used in conjunction with others.

When this happens, "developer" is just one person on the team. Developers will work alongside end-user citizen integrators, integration specialists, business subject matter experts, and artificial intelligence to create inter-product innovation.

We should be thinking today about what tomorrow will look like, so we can start to talk about what we want to create.