Product Practice for [CX|UX] vs DX

Why DX is no longer an option

Developer Experience (DX) is critical for software products with an ever-growing technology stack. Similarly, to user experience (UX), developer experience (DX) focuses on enhancing the developer journey, minimising roadblocks, and encouraging success throughout the product delivery process. With the increasing relevance of SaaS, excellent DX is no longer an option – it is required to remain competitive.

In brief, DX (Developer Experience) = Ease + Productivity – Toil = Developer Happiness.

Developer Experience (DX, DevX, or Dev EX) is like user experience but oriented toward product developers. To have a superior DX, an ecosystem must be functional, usable, well-designed and have self-service and intuitive capabilities. This broad quality metric can be used to any developer-facing utility.

Treat your developers like Bond, James Bond

Most 007 films have a lab segment with MI6’s R&D director “Q”. This man ensures James is equipped with life-saving technology and gadgets. Bond needs all the support to do his job for the Queen. Imagine James’ stories if he had to travel in a rusting Fiat or a large hiking gear. I predict a quick resignation. So can your developers if they are unhappy with the tool!

Organizations have achieved success by deferring to developers’ judgement when adopting new tools rather than following a top-down direction. In this context, usability drives competitiveness. That is, developers value usability as much as end users.

There are also more APIs available than before. Because the API economy is growing exponentially, software companies like Twilio, Stripe, and Shopify are winning the battle for developer experience. Improving usability increases user engagement and sales.

So, the bar has been raised with respect to developer tools/platforms and to navigate the challenges of this new paradigm, SaaS must be discoverable with self-service features. With spec-driven development comes slick documentation, common libraries, testing sandboxes, and more open experiences suited to developer preferences. These days, the market expects APIs to provide straightforward, self-service experiences. High-quality DX is no longer an option in this new reality.

Developer-Experience Vs. Customer/User – Experiences

The iceberg metaphor helps us comprehend how the inversion of technology occurs in the ecosystem or architecture; the user experience is at the tip of the iceberg, while the developer experience is at the bottom. The choices we make for each reinforce and seep into each other.

Customer experience refers to how customers interact with a tool, website, app, or other system. A positive user experience means the system is easy to use, works well, and helps the user achieve their goals.

Testing, user surveys, user testing, heat mapping, and analytics tools are used to evaluate CX | UX. Using this data, UX specialists can offer improvements to the design and development teams.

Thus, DX is essentially user experience for developers… right? Not exactly.

Developer experience relates to how developers experience your software while developing it.  Good DX means your technology is easy to evaluate, install, test, integrate, secure, and manage. Better communication, documentation, stability, speed, a modern user interface, and more support choices can help improve DX.

Comparing UX / DX 

To put it simply, user experience is concerned with end users, whereas developer experience is concerned with developers who utilise your software to help their end users. But there are many parallels. Both UX and DX aim to create a better product that is easier to use and more enjoyable. Surveys, user testing, feedback, and personas can also be used to evaluate UX and DX.

UX vs DX: What’s more important? 

You’ll need to consider both UX and DX, but what happens when the UX conflicts with the DX experience? For example, you may need to choose between correcting a customer-facing bug and improving your software’s package for developers to upgrade or install. So, which should you pick?

That, of course, is dependent on the priority order.

This means that if your tool is user-facing, it is more critical to prioritise the user experience, even at the expense of developer experience or ease of deployment. That makes sense because the primary goal of developers is to provide value to the end user.

However, this does not negate the importance of developer experience.

Improving DX can pave the way for better UX 

With an improved DX, developers can gain a better grasp of how to build and customise your software, enabling them to create a better user experience for their consumers. They will also be aware of the various features available to them and how to optimize their utility.

Examples of DX tools in use

• The Dynatrace APM tool configured by the SRE team is very adaptable – there are numerous ways to tailor it to the monitoring requirements of benefit teams in specific situations.
• Amazon Macie is one of the security tools set up as part of the cyber uplift programme. It recognises and ranks important data in your S3 buckets, such as personally identifiable information or intellectual property.

But what if you can only choose one?

You may need to make that tough choice between UX and DX. Investing additional effort to your software implementation may be justified if it improves the mobile experience for users. Delaying user experience improvements may be acceptable if it results in a tool that is faster and easier for developers to utilise in their own projects. Indeed, a faster and easier to use tool will attract more developers and users, allowing you to reinvest in better UX and DX.

It all boils down to prioritising your goals, really.

Some tools that can help enhance Developer-Experience

Keep an eye on this space for additional blogs on positive developer experiences and the numerous benefits they can offer to your business and customers.

Cited Sources : https://tsh.io/blog/developer-experience/

About the Authors:

Nitin Sareen, a former entrepreneur who has transitioned into product management, is fascinated by the unravelling of all aspects of technology through the use of a concept he coined: Stakeholder Neutral Language. He aspires to bring objectivity in the realm of Product Practice.

Veeran Patil is an inquisitive product aficionado and an upbeat techie. He currently works with engineering teams to help them create excellent products and deliver them quickly.