If you’ve been in tech for a while, you’re probably familiar with the term User Experience (UX), which refers to how seamless and enjoyable the user’s interaction with a product is, be it a mobile app, or an online shop, or an IoT device.
In this sense, UX is concerned with a user’s perception of the product and their feelings, including emotions. A UX designer’s goal is then (simplified) – make sure that the product makes users happy (or, at least, does not cause negative emotions) in achieving their goals.
The rapid development of the API business that started around 2012 (with approximately 40 APIs released weekly) brought forth new models of business aimed at the developers (business-to-developer model, aka B2D). Thus, developers got in the spotlight of UX practitioners (because developers are users too), and developer experience became (DX) a field of its own. Today, DX is an emerging practice that has already gained industry recognition and credibility.
So what is DX, and how is it different from UX?
DX is the study of a developer’s perception of and feelings about a tool or a set of tools that allow achieving goals related to software development.
In this sense, DX is UX but focuses on a very particular group of users, software developers.
But is it different from the UX? If developers are users, why do we need a new term and a new field of studies covering developers only?
The answer is simple. Developers are not only users of, say, API, or a cloud platform. They are co-creators with high expectations, little patience, and an understanding of how things should work. An average user of an app might not be able to tell what exactly is wrong with it. A mid-level developer will probably find a couple of arguments why your API sucks, from poor documentation to complicated key generation, to non-obvious features.
Developer experience starts with your portal’s landing page, continues with your documentation and “Hello, world!” application, and concludes with the celebration of a developer’s success. A DX practitioner’s goal is then to ensure a fantastic developer journey, from the moment a developer goes to this “Developers” tab of your portal for the first time to the moment he or she releases the app to the audience.
How can one ensure that the developer experience of their product is optimal?
A short answer is to ensure that it allows the developers to achieve their goal (working software) with as little cognitive load and negative emotions as possible. The moment a developer experiences negative feelings regarding your product, he or she starts searching for alternatives.
A longer answer is you need to make sure that every step in the journey you defined serves a single purpose of creating a software product that brings value. Besides, for every action, you should ask yourself:
Why do we need this step? What can I do to make it as simple as possible?
Think of “Hello, world!”, for example. The shorter and simpler the path from zero to the first “Hello, world!” program is, the higher the chances that your API will resonate with the developers. Ideally, this time should not exceed 5 minutes, and if you’re capable of doing it in an even shorter amount of time, the better. On the contrary, if a developer needs to perform many steps or wait unreasonably long to write the first “Hello, world!” program, the less likely it is that they will stay on your platform.
Different metrics can help assess the DX of your product, and time to hello world is just one of them. Metrics are important in discussing the overall developer experience, and I will talk about other metrics in future posts.
One way to think about developer experience is to ask:
How much effort is required from a developer to implement the API?
If the effort is too high, you may never succeed. If the effort is low, well, then you’re probably doing everything right and are good to go!
Remember that excellent developer experience starts with the user in mind, that is the developer. And developers are people too.