How the developer experience builds trickle-down usability

Developers are people; that seems fairly obvious. What might be more constructive is to consider developers as users, too.

So let's stop to consider the happiness and experience of developers in using a particular tool or product. As with user experience (UX), developer experience (DX) is the difference between early termination of a transaction or successful engagement.

Developers are also interface users, be it an API, a GUI tool or a command-line interface. You will find that the laws and guidelines around developer experience -- how they experience a product -- are similar, if not identical, to those that govern UX and usability.

Usability is a topic that surfaced formally, it seems, in the 1980s. Many of us have studied human-computer interaction, especially in our coursework. If you were like me, you did not make the connection between a mandatory -- usually 101 -- subject and the future of application design. It's essential to engage users intelligently and efficiently in a manner that leads to greater traffic, transaction completion, user engagement and revenue.

Fortunately, luminaries such as Steve Krug have codified this discipline into a more digestible and relatable format.

Especially in the last 15 or so years, the disciplines of usability and UX have flourished and matured. We now see specialized roles, along with dedicated research and training.

DX is following this path, and organizations have created roles to look after the developer experience. These can be called developer evangelist or developer advocate.

In my role, I am called a senior developer advocate for our internal cohort of developers. In this context, I advocate for developers and to developers in the use and adoption of our internal platforms. I am not a salesperson. I don't sell them promises. I encourage developers to accept tools and features that will prevent them from having to reinvent the wheel. Plus, I talk with platform teams to relay the feedback and suggestions that the developers provide.

This role requires empathy, a strong sense of collaboration, a nose for product management (and each tool or platform should have its own product manager, too) and awareness of brand. It's also important to gather and analyze metrics.

Developer evangelist Manfred Bortenschlager put it this way: "DX should comprise the whole developer journey from encountering you (or your product) for the first time till integrating and operating with your product -- or even at some point [divesting] your product."

Pamela Fox defined this developer experience journey as follows:

1. Do I want to use it?
2. How do I sign up?
3. How do I get started?
4. How do I use it?
5. How do I get help?

A developer consuming your product wants a good UX and journey. That means no friction, clear signposts, succinct, meaningful and clear documentation, testable code, extensible code (if possible), reusable code, avenues for question answering, simplicity, and no need to think (or code).

This brings us back to Steve Krug. In his seminal book Don't Make Me Think, he made several observations about improving UX that can be directly applied to DX. Let's discuss three of them:

1. "Like road signs, your navigational tools should be uniform in appearance and so big that no one can miss them."

An excellent example of good DX is the one provided by Heroku. Right from "get started," it marks every step clearly: choosing your language, setting up your local build environment, writing code, all the way to a deployed application. The whole journey is effortlessly and flawlessly laid out before a developer's eyes, and, like magic, it just works. I am not advocating for (or against) the tool per se, but I do applaud the frictionless onboarding.

2. "To refine your site, conduct repeated usability tests."

When someone has to think too hard to navigate your documentation or your tool, you have created friction. This leads to a reduction in usability.

Test your platform or tool or API before releasing it into the wild. Is it usable? Does it make sense? Can someone pick it up and produce working code in short order? These and other questions need answering by testing real users (developers), not your own team, which will have biases and blind spots.

3. "It's a fact: People won't use your website if they can't find their way around it."

Friction is the enemy. When you cannot make next steps or answers obvious, when someone has to think too hard to navigate your documentation or your tool, when the documentation font and spacing are hard on the eyes, when you cannot easily search for an answer, when the road signs are not clear, you have created friction. This leads to a reduction in usability and engagement and thus uptake.

If you are a producer of developer tools and platforms, it behooves you to become educated on usability and UX/DX. Conversely, if you are a consumer in DX or a manager of these consuming teams, please realize that DX matters. We already know and should not have to explicitly – and non-sarcastically -- point out that developers are people, too.