As developers, we’re all painfully aware of the collision that exists between User Experience (UX) and Developer Experience (DX). We design for UX but with each helpful or useful element that’s added, we’re also heaping on a ton of extra code if we’re not careful. It’s code that makes things easier for the developer but not for the user. And that’s why UX and DX collide.
The resulting bloat can sound the death knell for any website.
The Problem With a Code-Heavy Product
Gone are the days when web developers could design away with little thought given to load time and other performance indicators. In case you hadn’t noticed, we now live in a mobile-first world. That means more users are accessing the web on the go rather than from their PCs.
Here’s where the issues arise. On-the-go users, no matter where they are in the world, don’t enjoy seamless powerful coverage as they move about. In some countries, millions of people are surfing at speeds we’d consider unacceptable in the United States or any other place in the world that enjoys above-average connection speeds.
When a developer is tapping into all those great open-source solutions for the project they’re working on, they often do so at the extreme expense of the client’s global traffic. Do you really want your client’s app or website to lose traffic as their potential visitors lose patience with a slow-loading product?
All it takes is three seconds before people give up on a slow-loading site.
The Problem With a Totally Bespoke Solution
It’s basic knowledge these days that our products need to load fast and not be full of bloated code. So why don’t we just tolerate the grunt work of making sure every single component of the product is as user-friendly as possible? In other words, audit everything for performance and accessibility and anything else that affects UX. We could also write wonderfully light and efficient, bespoke code for every project, from scratch.
That would be how we could speed up load times, thereby prioritizing UX.
But doing things this way would mean compromising DX. Good UX often comes at the cost of DX for two reasons.
- Job Satisfaction. Developers wouldn’t meet their goals and they’d probably end up hating their jobs because of all the tedious, basic code they’d be writing over and over.
- Job Performance. Developers are under pressure to deliver on time and within budget. They’re almost always stretched pretty thin due to these constraints, even without performing a full UX audit on everything they do. Writing fresh code every time, without the help of reusable foundational code would bring the whole show to a grinding halt. Forget about deadlines and budgets. You’d have an efficient code but at what expense?
So developers make the best of things by cutting corners, delivering buggy code (not due to negligence but because of these constraints), and planning on revisiting certain problem areas later.
What ends up happening, very often, is users end up with a less-than-stellar experience. Sure, deadlines were met and budgets were kept — but at the expense of UX.
Hence, the UX/DX collision we’ve been talking about.
Developers are Part of the Solution
There’s a quote that often gets bandied about in developer circles:
“Source code is a liability, not an asset”
To understand this, you simply have to take a step back and try to define the role of a coder on a development team. Contrary to what the name implies, coders aren’t just there to write code. Like everyone else in the development environment, a coder’s job is to deliver business value.
In other words, developers exist to solve problems.
The code that gets written is merely a tool that helps a developer deliver their contribution to the project. If there’s too much code delivered, it brings down the UX. If there’s too much time spent writing bespoke code to improve UX, it brings down the DX.
Developers can be part of the solution by carefully weighing the tradeoffs between UX and DX. By keeping both priorities top-of-mind, the right balance can be found. That entails:
- Considering the cost when making decisions. Knowing when bespoke code is worth it and when it’s not is a valuable skill. It will require a deep knowledge of the project specs, among other things.
- Understanding the trade-offs. Knowing how to research your problem to use what others have learned and then applying your discoveries to an original solution tailored to the specific task at hand — this is key.
- Acquiring familiarity with the open source environment. Developers who are skilled at tapping into ready-made solutions from the open source community will know how to save their efforts for the tasks that really require a custom solution.
Wrapping-Up
The real point we wanted to make is this: UX and DX don’t actually have to be at odds with one another… not if developers know when and how to make the right kind of trade-offs between the two so that everyone ends up happy. All it takes is awareness of the dichotomy between the two and a willingness to make good decisions with both goals in mind.