Let’s Talk About Developer Experience (DX) Design

I’m a designer, but I have some trouble talking with other designers about what I do. I make developer tools, and though our goals are the same there’s a lot about this work that other designers don’t relate to. On-boarding new users is complicated (does your product require new users to deploy code?), the importance of good API documentation can’t be overstated, and building a successful product means becoming part of a developer’s flow.

As software consumes the world around us, good design in our tools is a growing competitive advantage. The term Developer Experience (DX) Design isn’t getting used much right now, but it has a huge impact. Our tools shape our work, and great tools change the shape of our industry. The influence Amazon Web Services (AWS) has on the way we write and deploy code, the impact that Twilio has had on the availability of VOIP in our applications, and the iOS SDK’s introduction of an entirely new platform to developers are just a few examples of the impact our work can have when we do it well.

We talk a lot about the importance of a strong engineering team, but not enough about the design of our tools and the impact it has on the quality of the products we build. We should be talking about DX more, and it’s not enough to talk about UX alone.

What Makes DX Different?

The conversation about UX still feels fresh, and design’s seat at the table is still being earned. With all this new attention on UX, why should we fork DX into its own topic?

1. Our Customers Write Code
   Early use of the term DX was more-or-less synonymous with API design, which definitely isn’t something a typical product designer is concerned with. Though a well designed API with strong documentation and example code is important, it’s not always applicable — and in a fast-growing ecosystem of developer tools, designing the developer experience is about much more than that. It’s about how we weave our tools into the everyday workflows of developers, which will mean different things to each of us, and it’s a unique and important consideration in building our products.
2. The Stakes Are High
   We ask for a lot of trust, and have to earn it. If our product goes down, our users don’t want to see their own products taken down with it. Potential customers try us out in personal or staging environments before they risk putting us in production, so we have to show value in less than ideal circumstances. We have to earn trust by designing experiences that feel intuitive and powerful before we get the keys to the castle.
3. Designing Developer Tools Is a Partnership
   As a designer building products for developers, I’m dependent on a design-focused engineering team to help me find elegant solutions to our product problems. In the past few months alone I’ve had to learn how container scheduling works, how VPCs and subnets work, and how to measure the health and performance of a SQL database. I can try (and have tried) to design solutions to these problems in a vacuum, but it fails every time. One of the reasons I like designing in this space is getting to work with great engineers who care about improving their tools, and since I’m not a user of the product I need lots of help. I think this is a barrier to entry for a lot of designers, which means there’s also a lot of opportunity for improvement.

There are, however, problems with focusing on DX at the expense of UX as a whole.

Monitoring tools generally aim to maximize information density at the cost of usability

What’s Important to Remember About UX?

Thinking of our customers as experts and power-users can be a red herring. As we aim to design better tools, we need to keep a few universal UX principles in mind:

1. Our customers can write code, but that doesn’t mean they want to. What they want is the same as any other user: “don’t make me think”.
2. Designing for power-users, we tend to maximize information density and functionality at the cost of usability. Simplicity and clarity are always the most important goals in designing a product, no matter who the user is.

This is only the beginning of the conversation, though.

Let’s Continue the Conversation

@dontmakemecode

If you want to talk more about DX, you’re in luck. I’m co-hosting a new podcast called Don’t Make Me Code with David Dollar, CEO of Convox and founding member of the DX team at Heroku. Find us on Twitter @dontmakemecode. We’re releasing our first episode on Wednesday, January 20th. We’d love to hear about your experiences building developer tools, and to have you as a guest on the show. Email us at dmmc@heavybit.com if you’re interested.

You can follow me on Twitter @sboak. I’m looking forward to a lot more conversation about DX.