Why do we need developer experience?
You test your code to make sure it works. But is it usable? Do you wonder why it's so difficult for other people to use your library?
Well, chances are you're the world's leading expert in whatever it is you built. Nobody else knows it as well as you, and that gives you as warped perspective.
As the founder of Haxor Developer Experience Testing, I hear this time and time again. Some smarty pants engineer built a library, wrote a readme (which is really just a collection of their CLI commands), and thinks anyone else who can't use the product is "stupid."
I was that engineer once, but when I moved into product roles my perspective changed. As engineers, we spend a lot of time thinking about systems, but we forget about people.
What is developer experience?
This is where developer experience comes in. If you haven't heard, developer experience (or DX) is user experience for developers. It's the study of human computer interaction when the "human" is an engineer writing code.
Sometimes I think of it as human-computer-computer interaction. In the modern days of APIs, often times I'm interacting with a computer, which is sending a message to another computer.
What is the difference between developer experience and user experience?
One user experience professional I met outright got up and left when I said that DX and UX were different. They insisted they were the same, and the same rules and tools applied.
That forced me to really think about the differences. Consider the experience of someone ordering a pizza through their phone, and someone who's ordering a pizza through an API.
1. Intention
A user's goal is to order a pizza. Their task is complete when the pizza gets to their house, and they consume it.
A developer's goal is to build an application. The goal is to create, not consume.
2. Task Time
Someone ordering a pizza might complete the entire process within 10 minutes.
According to our research, it's generally going to take at least 30 minutes for a developer to make an API call and at least an hour to do anything useful.
3. Environment
Ordering a pizza happens within an app, on your phone. All of the information and tools exist within one small container. Most of the time there isn't a need to leave the soft padded confines of the app, unless something drastically goes wrong.
On the contrary, development happens on a local machine. Every developer's device is different; they have different operating systems, packages, versions, preferences. While a user might have an outdated Android, a developer is using Google Chrome or VS Code with 20 extensions created by other developers.
A developer is not restricted by the confines of a developer portal or documentation. We often find that the best developer resources are 3rd party and our clients aren't even aware of those guides. Think about how many times you've used Stack Overflow instead of some official documentation.
4. Learning
A user can learn everything they need to know about ordering a pizza within the application. They've ordered pizza before, and they've definitely eaten it. There are standards in user interface, we don't need to explain what a button or text field is.
A developer is overwhelmed with knowledge, new proprietary vocabulary, brands, tech lingo, and concepts they've never seen. It would be akin to ordering an entirely new type of cuisine.
5. Scale
Most of the time, you're ordering pizza for yourself or your family. It's easy to make decisions that only affect yourself or people close to you.
Have you ever ordered pizza for a large group of people? That's what it's like for a developer. Every decision affects some infinite number of users of their app. While you might not think much of something like a 5 second delay, it makes a big difference scaled across thousands of users.
It's still just UX for development
Despite these differences, we can still apply UX concepts. In fact, it's not as difficult as it sounds.
Our task times are longer. Our user experience testing needs to happen on the desktop. We create documentation that guides users and do everything we can to support scale.
It's a very interesting time right now. UX researching are asking "how can I get involved with DX?" and at Haxor, we're constantly talking to DX and DevRel folk about UX concepts. DX is truly the hybrid between developers and UX.
Developer Experience Testing
If you're interested in testing the DX of your API, reach out to us at Haxor. And if you're a developer who wants to shape the future of developer tools, sign up for our mailing list.
Top comments (0)