Over the course of my design career, I’ve seen firsthand the kinds of clunky, painful tools software developers use.

Many have overwhelming interfaces or don’t integrate well, making UX for developers often seem like an afterthought.

That’s why I was excited to take on the challenge of leading UX at DigitalOcean, a cloud provider focused on developers and their teams. As the developer community grows and their tools evolve, more design teams will be tackling this unique challenge.

So how can you and your team create a tailored design approach for developers? Here are some of the best practices we’ve learned.

Remember that developers are users, too

While developers are the people building new technologies, they also have specific needs as users.

Developers can be professionals, hobbyists, or both, and the tools they use at home or at work should be just as user-friendly as consumer products. In this way, our approach to understanding the user is the same as when designing for a non-developer. They are the end-users of the tools we design.

At DigitalOcean, we used this approach to improve our user onboarding experience. We launched a discovery initiative to understand what developers look for in a cloud vendor. After many customer interviews, we created a mental model to outline their pain points, opinions, and desires. During this process, we were careful not to assume anything about their technical knowledge.

Get into the developer mindset

One of the most important things I’ve learned in my career is that interface design is only one aspect of a deeper process.

Design combines all the research, information architecture exercises, style iterations, and validation work we do. And it all starts with listening to your users.

[Insert Usability Study Image]

At DigitalOcean, we spend much of our time working to understand the developer mindset. We gather insights from community feedback, support tickets, user research, and usage data. New tools and technologies are constantly changing how developers work, so keeping tabs on how they think allows us to continuously iterate and design products that fit into their evolving workflows.

We’re big fans of using methodologies like Jobs-to-Be-Done or Mental Models to understand user needs. Other tools like InVision, Fullstory, and Lookback help us test how they interact with our existing or future products.

Some questions to help put yourself in your developer’s shoes:

• What are they trying to do at this moment? Or with this tool?
• How do user needs vary based on their infrastructure knowledge?
• When in their process might developers need guidance, and how can we provide it?
• How can we design our offerings so they fit into their development process and ecosystem?
• Besides our UI, what other interfaces are they using to interact with our products?

Your web UI is just one of many interfaces

As designers, we usually only have to worry about different screen sizes for the interfaces we work with.

When designing for developers, you also have to consider other interfaces they use to interact with your tools, like Application Program Interfaces (APIs) and Command Line Interfaces (CLIs).

One of the most important principles for a good user experience is consistency. Whatever our users can do in our web UI, they should be able to do in our other interfaces—and vice-versa.

We also have to design for those other interaction points, working with our developer teams to create consistent and learnable APIs. My team continues to grow in this area by partnering closely with product management and engineering.

This is a critical challenge with our larger customers. Since they’re managing thousands of resources at a time, our web user interface can be limiting. To handle the capacity needs for their applications, they mainly interact with DigitalOcean through our API. Designing for this interface should be no different than designing for a UI.

[Insert API Documentation Image]

[Caption] Detail of our API documentation

Take advantage of your (very close) subject matter experts (SMEs)

It’s usually rare to have access to your potential users during the design process. But when you’re designing for developers, you likely work with an entire team of engineers who will build what you design.

We always check in with our peers to help deepen our understanding of a concept or validate an idea. It’s helpful to combine these conversations with other methods, as your company’s needs might be very different from your users’ needs.

During the discovery phase for our new Kubernetes solution, we spoke to internal teams that currently use Kubernetes. This “meta study” gave our design team a firsthand understanding of what it’s like to use competing products—and saved the team countless hours of research planning and logistics.

Documentation is one of your products: Treat it as such

A crucial piece of creating a pleasant user experience is the help and guidance you provide your users.

Unfortunately, product documentation tends to be an afterthought of the development process. In reality, it should be considered as carefully as any of your other products. And the process is even more important when designing for developers, as they tend to prefer a self-guided experience.

At DigitalOcean, we’ve worked hard to make our tutorials, FAQs, and documentation part of the Product Development Life Cycle (PDLC). We strive to understand our users’ needs, test the effectiveness of what we write, and evaluate the reading experience within the context of using the products themselves.

[Insert Droplet Documentation Image]

[Caption] Screenshot of our documentation website. We strive to provide detailed information regarding our products and guidance on industry best practices.

While developers may be considered power users, the process to design for them is as important as with any other type of user. In fact, we need to pay even more attention to avoid making incorrect assumptions.

Understanding developers’ specific needs, workflows, and other tools is key to delivering the best experience for them. In turn, they can do the same for their own users.