Back in the early days of software development, when computers were restricted to a few privileged technical experts, very little attention was given to optimizing the steps to build applications. There was no critical mass to justify the effort.
The rise of the microcomputer in the late 1970s has changed the landscape, democratizing not only computer ownership but usage and software development. In the 1990s, the Internet expanded this trend by allowing developers to share their knowledge and experience with a much larger audience. Since then, a lot has changed in the industry. However, there is a pervasive idea that software developers do not necessarily need easy-to-use tools because they are technically more capable than most users.
This premise may lead development tools to fail in delivering a good user experience. They would settle for something that works, no matter how cumbersome it could be for the developer to figure out how to use the product. The common understanding is that developers are power users, so they have what it takes to figure out how something works. Sure enough, developers will eventually figure out how the tool works. But probably not without spending more time than necessary and going through a fair amount of confusion and frustration.
The scenario has changed in the last few years. Companies started to be more concerned about user experience as developers and their employers appear to have grown more receptive to spending on apps that boost productivity and save time. The best developers I had the privilege to work with are more interested in solving the hard problems unique to the products they are developing rather than rebuilding solutions already available in the market. That is precisely where good development tools are more beneficial: they help developers focus on what is critical to add value to the solution they are building.
When designing tools for developers, we need to work under the premise that a developer is also a user. As users, they have goals and pain points. So the first thing to do is define who the developer is and what their goals are when using our product. These definitions should be based on actual data acquired by applying user-centered design research methods such as in-depth interviews, surveys, and direct observation.
We can then translate user goals into user stories, which will determine the features that need to be built. Then we set ourselves on a journey of exploring, combining, and creating new alternatives to what is currently available. Once the potential solution is developed, it is time to test and validate them with real developers. The results will guide us on what works and what needs refinement.
This process will be repeated until no significant usability issues are found and the product is ready to hit the market. Naturally, the product will keep on evolving based on user feedback during its entire lifecycle.
We must not forget that documentation is a fundamental piece of the development tool. The documentation should be carefully crafted to be clear and easy to follow, containing relevant examples and visual content that support the concepts behind what the tool is capable of.
User experience is a broad concept. It encompasses the entire user journey, from the moment someone discovers and decides to use your product all the way to becoming a happy paying customer willing to recommend your product to others.
Here are some of the items to check when considering development tools:
There is no better way of knowing how good a product is than actually using it. The days in which we used to buy based only on a promise of a good experience are long gone, and companies are aware that the best way to earn trust is by allowing potential customers to test the solution before buying it.
But there is a caveat. If you do not fully commit and dedicate a reasonable amount of time testing the tool, you may risk buying it based on a first impression. Ideally, you should use the tool as if you have already bought it and apply it to an actual use case within your context.
You can also ask other developers in your team to test it, so you have a second opinion. The interface must be intuitive to accelerate the learning process, but more importantly, the developer should be able to complete the tasks the tool was hired to deliver without much difficulty.
Regardless of what the tool does or how complex its structure may be, clear documentation will help the developer to be more productive and thus more satisfied.
The documentation should be consistent and accessible to different knowledge levels. It should be structured in a way that shows a logical information hierarchy, allowing developers to either have a quick look or to dig deeper whenever necessary. When relevant, it should also display visual content and use case examples.
If you spend more time looking for a piece of information than by reading it, or if you have to read a couple of paragraphs to make sure the information is what you are actually looking for, it means the documentation is below expectation.
A good developer experience implies access to multi-level support through different channels. Common requests should be solved faster by directing developers to established resources such as FAQs, demos, and documentation. For more complex issues, developers should have access to knowledgeable specialists.
To keep up with the evolving nature of development tools, customers should be able to report bugs, place feature requests, and follow updates in the product roadmap. By choosing a collaborative approach, the company will encourage developers to build a community around the product, making it trustworthy and relevant to other professionals.
Finally, once you feel the tool can help improve productivity, is easy to use, provides good documentation and comprehensive support, it is time to evaluate if it will remain stable and performant while scaling.
Ideally, you should use the trial period to run load tests before committing to the tool. As an alternative, you can also rely on reviews from other developers and third-party auditing and certification.
Usability is indeed for everyone, including professionals responsible for building software that is used by and benefits everyone else. Complex tools do not necessarily need to present complex interfaces. On the contrary, the best development tools are the ones that achieve simplicity and ease of use by applying thoughtful reduction, focusing only on the components that are key to help developers get things done.
By carefully choosing the right tools, companies will empower their developers, allowing them to spend more time on what really matters: solving the hardest problems, adding value to the products they build, and keeping customers satisfied.