The Design Void of the Developer World

The challenge of effectively designing for continuous delivery.

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.

“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.

Let's look at continuous delivery: the art of releasing better software in shorter cycles. It's the amalgam of time management, planning, and iterating. It would make sense that developing a product for continuous delivery would be cognizant of this interplay.

At LaunchDarkly, we could have taken two approaches with our continuous delivery tool.

1. Functional Model: “Let's just make the product work.”
2. Empowerment Model: “Let's make sure our product saves time, mitigates aggravation, and allows for better decision making.”

Let's assume that both models have equivalent functionality and backend logic. Truly harnessing the entire functional suite requires intuitive access. This is where design comes in. Design is about access and empowerment. It is about empowering the user through access to features, knowledge, and informed decision-making.

Developer tools do not have to be barren and sparse. They can be fun, interactive, and powerful without sacrificing efficiency. While designing for developers is different than designing for consumers, those differences manifest in information delivery and should not sacrifice empowerment.