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.
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.
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.
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:
Some good examples of companies that provide a pretty effective developer experience include:
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.
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.