How to build software experiences that developers love
------------------------------------------------------

Developers are expected to use increasingly powerful tools to deliver increasingly complex and innovative software. So, why do developer tools often feel like an IRS tax form?

I argue that it stems from a culture that treats aesthetics and functionality as exclusive, whereas I would argue they are highly intertwined. When software is consumer facing, we see a sweeping trend of minimalist elegance aimed at cultivating an emotional connection with the user. But, when that target user is now a developer, design seems to take a back seat to functionality.

Still, we must also recognize that developer tools target a very specific user: the developer. These tools typically serve critical functions and are used habitually for highly consequential actions.

For many consumer apps, it’s relatively easy for a non-engineer to understand a product’s scope. Let’s take Uber for instance. The UI/UX team assesses the front-end environment, the social caveats, and the broad technical requirements for peer-to-peer transportation. Overall, they are catering to a consumer audience that wants simple, quick, and reliable service. The design team can construct some broad personas and hypotheses regarding transportation from years of empirical experience and common sense.

However, building a developer tool is a bit different. Developer tools are not necessarily made to make things less complicated for engineers. They are made to enhance functional power and allow developers to do things that they could never do before. In the past, designers were not core to the development cycle. If the primary purpose was functionality.. why would you focus on usability and aesthetics?

“It just needs to work! Not look good!” is what I’ve heard in the past. This is the notion that accurately performing a task correlates to function, that putting in the correct inputs and receiving a reasonable output is the benchmark of success. But, shouldn’t there be other indicators of success? What about time saved? What about ease of use? What about scalability and reliability? What about the ability to make informed decisions? I can show someone a spreadsheet of tabular data or I could show them some informative charts. Both present the same data. Both functionally deliver. But, one works much better at delivering the information and fulfilling its purpose.

### DX

Hence, **Developer Experience (DX)** is about delivering robust functionality that is stable, speedy, and visually intuitive.

### Function

Function is absolutely paramount. A developer tool is only as good as the functionality it delivers. You cannot mask subpar functionality with beautiful aesthetics or clever marketing. If it doesn’t work well, then it just doesn’t work.

### Stability

Stability is a cornerstone of trust. A critical component of DX is to ensure uptime and dependable performance. Stability also manifests in the ability to rectify errors to avoid critical failure. Without stability, your product becomes unreliable, making your ‘amazing’ functionality irrelevant.

### Ease of Use

Developers hate to take their hands off the keyboard. Every movement to a mouse or trackpad feels like a Herculean task. _Ease of use_ does not just mean the tool is easy to navigate, but it means that you can access things quickly and efficiently. Keyboard shortcuts, tabular navigation, saved preferences, and intuitive searching/filtering should all increase the speed with which developers can interact with your application. However, _ease of use_ is also about performance. User interfaces that take seconds to load instead of milliseconds can be the difference between usable and debilitatingly frustrating.

### Clarity

This category is the closest to aesthetics. DX is about delivering an intuitive interface that surfaces critical information, mitigates user error (ex. confirmation dialogues on critical tasks), and provides visibility into your orientation (ex. navigation through affordance). Clarity is about the developer having full visibility into the potential consequences of an action and into the history of their actions (ex. auditing and analytics).

### Developers are People Too

Just because functionality is paramount does not mean design is not important. Design is about effectively delivering functionality to the developer. The more intuitive your design, the more the developer can take advantage of your product’s core functionality.

Design, therefore, is not just aesthetics — it is about usability. For developers, this usability is about surfacing functionality as quickly and intuitively as possible.

You can be the most patient engineer in the world, but if you are using a product that combines enterprise-grade functionality with an unusable interface, then your life will be filled with frustration and pain.

We must remember: **developers are people who value well-designed things**. When we embrace DX, we catalyze the growth of more powerful developer tools.

_To learn more about DX, I recommend the podcast series “_[_Don’t Make Me Code_](http://www.heavybit.com/library/podcasts/dont-make-me-code/)_” hosted by Stephen Boak and David Dollar. More specifically, Episode 5 discusses how_ [_Developers are people too_](http://www.heavybit.com/library/podcasts/dont-make-me-code/ep-5-developers-are-people-too/) _and the associated implications for DX._

Target

Uber

Too Long; Didn't Read

Cassandra Forward a free Cassandra-focused community event

Developer Experience (DX) — Devs Are People Too

Too Long; Didn't Read

Companies Mentioned

@justindesign

RELATED STORIES