To evade the bad guys, the Western town in the 1974 movie Blazing Saddles hatched a plan. They recreated their entire town in the middle of nowhere in hopes of luring the antagonists into a trap. Rather than physically rebuild every structure in the town, they merely erected facades of each place. When viewing the town from Main Street, it seemed like the real thing. However, behind each structure were boards leaning to keep it standing tall.

In this fake town of Rock Ridge, this simplistic approach worked. The townspeople planted booby traps and explosives. With the antagonist stunned, they were able to win the day.

Don’t expect the same easy victories with developers. They will look behind the facade of a polished portal and want to see how your product works. The traps you set for them—even accidentally—will keep them from being successful with your API.

Developer experience is not simply a well-designed site, though that can certainly help. It’s the sum of every interaction a developer has with your company, from before they even discover your website through being a veteran customer, assuming they make it that far.

If you attract developers to your facade with platitudes and hype, it could easily provide a negative impact. Instead, turn your focus to the elements of developer experience we’ll discuss in this post.

Is DX Really Marketing?

So developer experience is important, but is it really marketing? That can depend on where you fall into the developer marketing continuum. And for any dev-focused company, the answer is a resounding yes.

In our work with dozens of these companies, there are 13 criteria that make a good developer experience, including:

Can you find anything that is clearly focused on a developer?

If even that’s missing, imagine what a developer who comes to your site thinks when they see that there’s nothing there for them. There’s no link on the homepage or nav bar that says developers or documentation, as is the case for 46% of the top dev-tool homepages, including MongoDB.

Maybe then they scroll down to the footer and there’s nothing there either. Or, if there is something for them, they click on it and it pops them over to a completely different site. They’d wonder, do you really care about developers if you’re providing such a poor experience? And that’s just on being able to find the documentation, let alone some of the other 13 criteria we’ll discuss next.

What Is the Most Important DX Criteria?

You might see 13 things and wonder what you should do first, or which is the most important. My recommendation is getting started with getting started.

Too often, we find this part missing when we do developer experience reviews for clients. There will either be no getting started or it will be a getting started that doesn’t actually get you started. Maybe it’s more of an overview of concepts, or there’ll be multiple getting started’s that are different projects entirely.

Instead, you ought to choose what that first experience is going to be like, and how can you walk a developer through that. If you’re only going to focus on one of the 13 criteria in developer experience, this is the one to go for.

Some common mistakes we see all the time include making it too long or attempting to cover everything, including some long list of concepts that you feel like they need to know before they actually use your product, as Snyk does:

Instead, it’s okay to keep it focused and to give just-in-time context, as someone is getting started. Let them see what comes back. If it’s an API, what call is returned? What does it look like when they integrate your developer product with a tiny little sample? Or a hello world app? Let them see all of that.

Only then can you start to layer in the concepts that are going to be important. Those become the next steps. That’s your path to the first success. Whereas getting started is all about that first experience.

Improve Your DX with the Other Criteria

We’ve covered two of the 13 DX criteria: prominent, in-depth getting started guides and discoverable documentation. That leaves the 11 others we look at when we provide an expert review of your developer portal and documentation.

You’ll see where you are succeeding and where you should focus to improve your developer experience. Get this high-level view of your developer experience and clear next steps to improve your results today.