Principles of Developer Experience: An Introduction

Good products pay attention to the overall experience of their customers. They understand that a good User Experience is more than just what the product looks like and how it behaves. Think about Amazon. Their user experience doesn’t only cover what the product page looks like or how you checkout. Their massive product selection, free shipping options, easy return policy, putting product return kiosks in Kohl’s department stores, delivery lockers in apartment buildings... All of these things are part of the user experience. They all play a part in how and why you use Amazon. If you want your product to be successful, you need a great user experience beyond just your product design.

Developer products are no different. Developers are people too and they are attracted to a great experience just like any other person. If you want your developer product to be successful, you need a great developer experience beyond just your API design.

The experience matters a whole lot more to a developer product’s success than it does for many other products. Customers will often live with a poor experience because they don’t have much of an option. For example, if no one else makes a substitute for the product, you’ll be more inclined to suffer through a bad user experience. But developers tend to have a lot of options. If they can’t use your API, there may be some open source tools they can put together as a substitute. Or since they are developers, maybe they’ll just build it themselves.

For many developers, "I could build that" is the default thought. By targeting developers your primary competition is Do It Yourself. Most people aren’t going to go shopping for a dining room table with the idea that if they don’t find something they like, they’ll just build one. But that’s exactly now most developers evaluate APIs.

The way you create a quality developer experience is by putting their needs first. By understanding the developer, what problems they’re solving, how they go about their life, and how they react to adversity. You have things you need as a company providing the product. You need to make money, you need to secure your data, you need to build the pet feature of your biggest customer. But if you start from a position of what you need, you’ll fail. You cannot design a great developer experience without solving for the needs of the developers.

I’ve found there are six primary principles that you need to follow to create a fantastic developer experience. And just like User Experience isn’t about product design, Developer Experience isn’t about API design. A well-designed API is your minimum starting point. It’s the basic requirement you need before you even get started on Developer Experience because without a well-designed API, your product will fail.

There are lots of articles on the internet about how to create great APIs. This isn’t one of them. What I want you to do is intentionally craft the overall experience around the great API you’re already creating.

In addition to that great API, you’ll need to understand what else goes into the developer experience. You’ll need to understand what core guiding ideals should guide you in creating those.

Your developer product needs to be Easy to Understand. A developer that’s looking at your product wants to know what your product does. What is it good for and what it’s not good for. Can the developer look over what you’ve published in your documentation and marketing materials and understand what the product does, how to do it, and what the costs are going to be?

The product must be Easy to Use. How hard is it for a new developer to get up and running? Can they create and revoke access keys without your help? Are there code samples and SDKs in the programming languages the developer uses?

When a product makes it Easy to Build you’re enabling developer productivity beyond those first Hello World steps. You’re giving them tools to build and maintain robust applications. Tools for debugging or an SDK that evolves predictably. Developers will be more productive if your APIs and SDKs have intelligent defaults, syntactic niceties, and recipes for common tasks.

You need to make it Easy to Get Help when a developer is stuck or something goes wrong. The people providing support need to understand development so they can help debug. Put common error messages in your documentation to aid searchers. The faster you can unblock a stuck developer, the better their experience will be.

Developers must feel your product is Easy to Trust. Developers can be less tolerant of marketing over substance. If you say your product can do something, it needs to do it. Not sort of do it, not do it in the future, not do it if you get this partner add-on. Your communications need to be honest and straightforward. If they’re going to build part of their business on your product they need to believe that you’re going to do the right thing for them and their customers.

Finally, your product must be Easy to Maintain. If your documentation is hard to update and has the same information scattered everywhere, they’ll quickly fall out of date. If your SDKs each need a manual change in 25 places when you add a new API property, how likely is it that you’ll be able to provide more than one SDK? If it’s hard to get a new error message to show up in the debugger, you’ll ship the error before the debugger and confuse developers.

You can create a great developer experience for everything you build. Look at your product through the eyes of an outside developer. Make sure everything you build is something you’d want to use yourself. Make it easy for developers to be awesome.

More about the Six Principles of Developer Experience

• Principles of Developer Experience: An Introduction (You Are Here)
• The Components of A Developer Experience
• Principle 1: Easy to Understand
• Principle 2: Easy to Use
• Principle 3: Easy to Build
• Principle 4: Easy to Get Help
• Principle 5: Easy to Trust
• Principle 6: Easy to Maintain