Developer Experience has become a big thing, and the growth of software products of all kinds is surely one of the drivers: In 2021, the SaaS market totaled $152 billion, and is expected to reach $208 billion by the end of 2023.
There are multiple apps available for business, including ones that allow you to use your phone as a mobile office. But there are also many tools and products used by developers themselves. Developer experience (DX) is something many organizations focus on and, without a good level of such experience, you may encounter problems in your workflow.
Just what is developer experience and why is it so important? How do you ensure that you achieve – and maintain – a sufficiently high level of DX so that developers are happy with your tools, and products? We take a look at this often-misunderstood area of the development of tech products.
What is developer experience?
You will already be very familiar with user experience; how end users of tech products view their various interactions with apps, software, and so on. Knowing CSAT meaning can help understand DX more. DX is just the developer version of that, and refers to the experiences of developers when using a tool or product. That experience covers all aspects including:
- APIs
- Frameworks
- Documentation
- SDKs (software development kits)
- Libraries
- Open-source solutions
- General tools
While there are many parallels, there are also distinct differences as developers often have vastly different needs from an everyday end-user of a product. Those needs can also vary greatly; one project could be a straightforward auto attendant system, the next a vast stock control system. However, the end goal is the same; a developer who finds a tool or product with good DX will use that tool for longer, and are more likely to recommend it to others.
It used to be that issues with a product or tool were left to developers to fix themselves, but as we see increasing consumerization of the enterprise-level IT sector, the expectations of developers have grown, and DX is becoming more and more important. Poor DX is now very much ‘frowned upon’ and developers want products and tools that offer a better overall DX so that their efficiency is easier to maintain, and where they can innovate easily.
How do you measure good DX?
One problem faced by companies in this area is actually measuring what makes good DX. You can collect qualitative feedback but that is, mainly at least, a series of opinions that may offer some good insights but don’t tell the whole story. Looking for numerical context in any feedback can help confirm whether you are getting things right or wrong.
One way to achieve this is to survey your users in the same way you would your customers when measuring customer satisfaction. After all, the developers ARE your customers. You can design your own DX survey that asks users to rate the various aspects of your product on a scale such as 1-5 or 1-10.
You can then widen this survey to include specific qualitative feedback. For example, if a developer rated your product as poor when it came to APIs, then you can have a follow-up question that asks them to identify specific issues they encountered. If you see patterns in negative feedback, then you can focus on these issues, and have your own DevOps teams look to fix them if possible.
This shouldn’t be a difficult exercise. List the main attributes that matter to the developers using your product, and ask them to score them. The added qualitative inputs can help your DevOps team focus more on what parts of the product are causing issues. If you encounter a lot of issues, it may also be worth using user testing apps from a specialist company.
Look long term, not short term
Depending on the size of your organization, you may have anything from a single small team to several teams focusing on DX. Whatever your size, having staff members who are focused on DX means you are investing not only in your products but also in the long-term life of current, and future products. That investment is a long-term one that, if you can achieve and maintain good DX, will show good ROI over any product’s lifetime.
DX is wide-ranging, and covers everything from design, and initial onboarding to more involved aspects such as libraries and SDKs. It also doesn’t exist in a vacuum nor should it be a one-off observation. You need to be aware that DX may change with the different projects the developers work on. What was smooth and painless when they used it on one occasion may be less so on another.
With that in mind, it is worth noting two important points. Firstly, you need to fully understand the developer’s journey. Secondly, you need to return to that journey multiple times to ensure that good DX is repeated, and ongoing. While factors such as a developer’s first impressions and first experiences are crucial, so are the last impressions, and experiences.
Developers working on a project such as a telepresence and video conferencing system may encounter many hurdles as such a system is complex from a development perspective. Understanding the development journey can help you improve DX.
What to look at in DevX
While you may be measuring, both quantitatively and qualitatively, many aspects of DX, there are several aspects of DX you should be, initially at least, prioritizing when it comes to collecting feedback:
- First impressions
First impressions can happen before a developer even uses your tool. They may read a review online that extols the virtues of your product or they may even have the product recommended by a friend or colleague. They may also find your site, and your products via a web search when they are seeking new (or better) tools to use.
To create a good first impression, there should be a dedicated area of your website where developers can access all the initial info they need. If the info confirms that your product can meet their needs, then enhance that first impression by offering them a free trial or account so they can see your product in action.
- First experiences
If first impressions are good, then the next stage for any developer is to try your product, and see how it works in real life. They may still be unsure of your product’s ability to meet their needs and solve their particular problems, so they may experiment with the product in various ways to see how it performs when applied to the tasks they want to carry out. For example, developing software for frontend ecommerce may need different approaches.
Their first experiences with your product are perhaps the most crucial when it comes to DX. You want to make it as easy as possible for them to onboard, and start using your tool. That means you should include a quickstart guide and easy-to-understand documentation. You may also want to consider providing tutorial videos, and having a simple to access helpline can go a long way to getting past any initial teething problems.
- First successes
So, the developer has onboarded, learned about your product, and is ready to use it in their actual work. That first experience, and the successful use that hopefully comes with it, can be a great measure of DX, and can also help you identify any issues that need to be addressed. By providing a high level of DX, you help with cases, and also enable developers to find solutions quickly.
If your product offers good DX, you will offer developers sample applications for each potential case where they may use your product. That can include offering versions in the different coding languages they could be using so that they can adapt your product to their exact needs. By combining impressions, experiences, and successes in a positive way, you can ensure that a developer not only likes, and uses your product but also recommends it to others.
Ongoing work and support
Even if you’re not a technical person, you will be well aware that nearly all tech products have post-release bugs, or have fixes or upgrades added later. What that means in terms of DX is that it is not a linear process with a start and end but can be constantly ongoing from their perspective, and thus also in terms of using your product.
You need to keep all aspects of your tool updated so that the version they are using is the best available. That covers everything from documentation to APIs. You don’t want developers encountering issues that originate with poor documentation or a failure to update functionality that has been shown to fall short of expectations.
When it comes to supporting developers, you should offer two main routes to support. Where possible, offer self-service options so that they can solve issues themselves. In terms of agent support, ensure there are clear (and speedy) routes to seeking support, and that agents who can solve specific or specialist issues are clearly identified.
Enable continuous delivery in DX
One important thing to remember when it comes to DX, and the product you provide is that developers want, and usually need, to be able to deliver continuously. Just as you have a responsibility to the developers in terms of DX, so they have a responsibility to the users of the software or apps they are working on.
If your DX means that they can maintain continuous delivery, then you have a good product or tool.
Provide them with everything they need from your tool to ensure they can develop and deploy the project they are working on, then support it post-release. That can include previously mentioned things such as libraries, and operational support so they can get the very best from your product.
Understand developers’ needs
It can be easy to turn off when developers begin discussing the issues they face, and the solutions they need. After all, if you’re from a non-tech background, it can sound like they are speaking a foreign language at times. Making an effort to understand what they need and want can be the difference between poor DX, and great DX.
That means listening to both them and to your own IT teams, and developers. Good and effective management involves using the resources you have to maximum effect, and recognizing some of the common problems your customers (the developers) face.
- Outdated code
The entire tech world is constantly evolving, and that applies to development too. If you are using old code or even overly-complex code, then your product will fall short of users’ expectations. Developers want your tools to have libraries that offer them a choice of codes, and those should include the ones most commonly used today.
- Archaic tech
You know that tech is constantly evolving and changing and you likely have several requests a month to invest in the newest forms with all its bells, and whistles. You need to find a balance between budget, and good tech. The most important thing is that you are using – or letting your developers use – tech that does the job efficiently, and quickly.
- Too many cooks
Projects may well have multiple developers working on them; that’s the nature of software development. However, DX is going to be vastly reduced when those multiple developers work on one aspect of the project. While this is outwith your control, it is something that can make your product less valuable as the end product may be messier than it needs to be; that can look bad for you.
The takeaway
Developer experience is just as important as user experience. In fact, most developers would argue that DX is the more important of the two. It doesn’t matter whether they are developing a simple game or a complicated stock management software system. They still want the same level of DX when working on both.
Recognizing and understanding the issues they face, and any problems they encounter with your product are crucial factors in perfecting your tool. DX should be front, and center of what you do when developing your products so that you provide the best possible experience for the developers using them.
Read this article to discover more about developer experience!
