Building the Developer Experience (DX) From the Ground Up

When it comes to choosing a new tool, software developers want to be able to immediately try a new product and not be bothered with the traditional sales process. Developers like open source projects because they can get up-and-running quickly — they get the option to play around and experiment on their own. With this changed model of enterprise software adoption, developer experience has become critical for the success of any product.

With the adoption of public cloud services, developers and operators are gaining more influence over the purchase decisions of technologies with which they build on and with which they integrate. The successes of Docker and Kubernetes have been driven primarily by individual software developers choosing to use these technologies, rather than by the decisions of business executives.

What is Developer Experience (DX)?

DX is not just about APIs and CLI, they are small parts of developer’s overall experience with a product or service. While designing for developer products, designers use UX methods and principles to deliver a positive experience. DX design is about understanding the context of use, understanding what developers need to complete their tasks, underlying technology, integration points, and focussing on how developers feel while using a product or services.

Developer Experience (DX) is inspired by the User Experience practice and sees developers as a special case of users. Developer Experience Design is the practice of understanding how developers get their work done, and optimizing that experience.

Defining the Developer Experience

Building a new product means trying new ideas, a lot of iterations and moving quickly. In order to be more efficient, we needed a good set of DX design principles that represent the developer needs and our product goals.

Design principles are helpful to provide teams with a way to gauge design decisions, they help teams to choose between different design options.

Design principles are the guiding light for any software application. Design principles define and communicate the key characteristics of the product to a wide variety of stakeholders and team members. They articulate the fundamental goals that all decisions can be measured against and thereby keep the pieces of a project moving toward an integrated whole.

Designing for a startup involves understanding the domain, wrangling with the ambiguity, and influencing the system-level problems. Startups never have written UX requirements or design briefs, starting with ambiguity is always fun and a challenge!

There are many ways to create a less ambiguous start to a new enterprise product; I chose to run a Developer Experience Design Workshop with the entire dev team and stakeholders where I used brand experience design methods to explore the DX attributes.

A fun, collaborative approach gave developers an opportunity to participate in the design, right from the beginning.

The DX workshop was one of the first interactive conversations we had where we started discussing the overall developer experience. It helped us start building a shared vision of how a product should feel to a user.

The output of the workshop was a set of experience attributes that matter to the developers.

We had a couple of additional sessions with the team to cherrypick the most important attributes and refine the design principles that were derived from those attributes. A week later, we unveiled the DX Principles to the entire team.

The Developer Experience (DX) Principles

Simple

• Less is more — Any element that isn’t helping the user achieve their goal is working against them.
• Give easy access to the features that most users will need most of the time.
• Use 80/20 — Keep taking things away until the design desperately needs it.
• Every element should serve an essential purpose; resist the urge to decorate.

Usable

• Understand the context — How users use something differs depending on the time of day, location, and their culture.
• Minimize choices and tasks.
• Leverage common design patterns.
• Keep users informed about what is going on.
• Use concepts familiar to the user rather than system-oriented terms.

Innovative

• Break the rules.
• Match form to function, function to form.
• Ask the bigger question — know what type of problem you’re solving.
• Design quickly, decide slowly — iterate until an idea is aligned with its purpose.

Delightful

• Always keep the target users in mind as the product is designed.
• Strive for Beautifully Functional by designing with data.
• Use good visual design to make the UI enticing and engaging.
• Use meaningful motion design.
• Focus on microcopy.

These design principles have helped us to choose the right solutions, they have helped us to focus on the meaningful problems. Right from the beginning, they helped us to think about how the user flows, interactions, visual language and motion design can reflect the experience principles.

For the Argo Project, software developer is the primary persona and we focus on every touchpoint and channel they interact with, during the development process, whether it’s Argo installer, CLI, Web UI or 3rd party integrations. We believe that great products come from developers using their favorite tools. That’s why a great developer experience has always been at the very heart of what we do.

This is the first in the blog series about our experience building the User Experience for Project Argo. In upcoming posts, I will be sharing more of our thoughts, learnings, and demonstrate specific examples using our own Argo User Experience.

Rahul Dhide is the Design and UX Leader at Applatix, provider of products and services to help developers succeed with containers and Kubernetes.