When people talk about User Experience (UX), they often talk about their beloved consumer products: a smartphone, a messaging app, or perhaps a pair of headphones.
User Experience also matters when you build something for developers. People tend to forget that developers are users too, and software development is an intrinsically human activity limited by not only how computers work, but also how programmers work. Admittedly, there are fewer developers than consumers in general, but the more usable developer tools are, the more energy developers can spend on delivering value to their users. Therefore, the UX of developer products is just as important as for consumer products. In this post, I am going to introduce the developer experience, explain one of the ways we assess it at Google, and share some lessons we learned from a specific study we conducted on Flutter, a new SDK for building beautiful mobile apps.
The idea of developer experience is not exactly new. Research on developer experience dates back to the early days of computing, since all users at the time were developers to some degree. “The Psychology of Computer Programming”, published in 1971, is a landmark book on the topic. When we talk about developer experience, especially applying the term to an SDK or library, we usually refer to three aspects of the product:
- API Design, which includes the naming of classes, methods and variables, the abstraction level of the API, the organization of the API, and the way the API is invoked.
- Documentation, which includes both the API reference and other learning resources such as tutorials, how-tos, and developer guides.
- Tooling, which involves both the command-line interface (CLI) and GUI tools that help editing, debugging, and testing the code. For example, research has shown that autocomplete in the IDE has a large impact on how APIs are discovered and used in programming.
These three pillars of developer experience complement one another, so they need to be designed and assessed as a package.