Key learnings from years of designing for developers — navigating complexity, fostering community, and enhancing developer experience.
Illustration by the author (Sara Kaandorp)
Every piece of software we use today is the result of countless hours of hard work by developers. Behind every sleek user interface and seamless functionality lies an often invisible world: the developer tools that make it all possible.
Over the past few years, I have been serving as Head of Design at Appwrite, where I had the opportunity to design UX for hundreds of thousands of developers. I am excited to share insights about the unique challenges of designing for developers and how they differ from traditional UX design.
A distributed developer experience
Unlike apps where users interact within a controlled interface such as a website or mobile app, developers use a wide array of tools, from terminals and code editors to external documentation and community forums. This means the UX is not confined to a single product; it stretches across multiple platforms and ecosystems. The developer journey map from the book Developer Relations — How to Build and Grow a Successful Developer Program by James Parton and Caroline Lewko illustrates this distributed experience well.
Developer Journey Map (Developer Relations — How to Build and Grow a Successful Developer Program)
It’s important to minimize the friction between these touchpoints in the developer journey. It is crucial to meet developers where they’re at without disrupting their flow. It’s less about controlling the entire experience and more about being a seamless part of the ecosystem.
Building software is like having a giant house of cards in our brains — Tiny distractions can knock it over in an instant. Developer experience is ultimately about how we contend with that house of cards. — Idan Gazit, senior director of research at GitHub. Developer experience: What is it and why should you care? (2023)
To minimize friction in your developer journey, it can be helpful to have your team use the product they are building internally— also known as ‘dogfooding’ — and maintain a friction log, a practice made popular by Stripe. We’ve made this a regular practice at Appwrite, and it has been instrumental in uncovering friction points while increasing empathy and knowledge of the developer journey across the team.
The distributed user experience and context switching can have unforeseen consequences. For example, when building and testing the application, developers will often resize the screen to accommodate a terminal window, coding tutorials, and documentation. Therefore, it’s important to make sure your app works properly at smaller breakpoints, even though you might not expect developers to necessarily use your app on an iPad or mobile format. The article Devs in mind: how to design interfaces for developer tools by Anton Lovchikov and Travis Turner from Evil Martians illustrates this phenomenon well.
From Devs in mind: how to design interfaces for developer tools by Anton Lovchikov and Travis Turner from Evil Martians.
Another method of dealing with context switching is eliminating it as much as possible. For example, identify opportunities to embed interactive, tailored documentation inside the app. This way, developers don’t have to constantly switch between the two and can focus on integrating with the product, which ultimately increases activation.
PostHog includes code examples within the product, as well as a view of their docs directly in the product.
Flexibility and integration
Flexibility is key when it comes to developer tools. Developers want to use the tools and coding languages they’re familiar with alongside your product, so ease of integration is crucial. Too many tools or “tool fatigue”, is a real thing that developers face every day. The Stack Overflow 2024 survey lists the number of software tools in use as the seventh most common frustration for developers. If a developer feels like they can keep using their preferred tools and your product just “fits”, you’ve already won half the battle. Provide quickstarts with different tech stacks, integration templates, and demos to remove as much friction as possible.
Highlight quickstarts on your website and in your product. Example from Vercel.
Balancing complexity with usability
Some developers using your tool will be seasoned professionals, while others are just beginning their development journey. Therefore, it is important to find the right balance between deep functionality and simplicity when building for developers. Power users appreciate maximum flexibility and don’t mind complexity; they love tinkering with technical details and are more forgiving of a cluttered interface, as long as it gives them control. On the other hand, beginners can easily feel overwhelmed by too much complexity.
“It’s worth remembering that many developers can handle more complexity in their products than other users we might be used to designing for. Now, of course, there is a balance to be struck here: what you want is to make things as simple as possible for new users, but also provide experienced users with the power and control that they require.” — Designing for Developers, Arin Bhowmick (2018)
This is where progressive disclosure comes in. Make the initial interface simple, but provide access to advanced functionality for those who need it. For example, a simple set of filters might satisfy beginners, but power users will appreciate the ability to dive into more advanced query filters.
Example of quick actions vs. features for power users with filters in Appwrite
Community: the heart of developer experience
Developers rely on active communities to get answers to their questions, share feedback, and explore best practices. The size and activity of a community often serves as a deciding factor for developers evaluating whether to adopt a new tool or to advocate for it. According to the Stack Overflow 2024 survey, an embedded community serves as one of the top 5 reasons to advocate for a technology or tool.
One thing that I love about working in the open-source developer tooling industry is having a vibrant community to work with. It’s a powerful thing to have instant feedback from your end users at your fingertips. Sharing designs and participating in discussions with users in real-time can shape product decisions. Even the most critical community members become the biggest advocates for your product if you show them you care about their opinion, and by doing so, you’re making them a part of the journey.
“The true measure of a community’s success is not the size of its membership, but the depth of its relationships and the strength of its shared purpose.” — The Art of Community: Seven Principles for Belonging, Charles Vogl (2016)
However, with great power comes great responsibility. An active and engaging community means a lot of data points. It gets hard to identify value from noise. To help tackle this, make sure you know your community members and the personas they fit into. Doing so helps filter to best align with your intended user base. While it’s important to listen to your community, it’s crucial to digest the most valuable feedback that aligns with your business goals. Grace Vorreuter, Principal Researcher at GitHub, shares some excellent examples of questions to ask developers to prevent bias in your research in the article A guide to designing and shipping AI developer tools.
Bridging the gap between UX and developers
Most designers do not have a strong technical background. Working for a developer tooling company requires you to understand deeply technical elements of the user journey. This can be hard at times.
In my experience, a valuable approach is to get the developers in your team acquainted with user research and design thinking methods. This is a valuable practice in any team, but maybe even more so in a developer tooling company, where there is often a wide gap to bridge between developers and non-developers.
“Designers must open up the design process. The team — not the individual — must own the product design.” — Lean UX, Josh Seiden and Jeff Gothelf (2021)
Encourage developers to join you in usability studies and user interviews. Having developers participate not only gives them insights into how users interact with the tools they build but also uncovers nuances in the journey that may otherwise be overlooked, leading to a more holistic design process. For example, at Appwrite we started doing usability tests on highly technical parts of the user journey that involve a non-traditional UI, such as Command Line Interfaces (CLI).
The importance of asking silly questions
One of the most valuable characteristics a designer can have is the courage to ask questions that may seem silly at first. In the highly technical world of developers, it’s easy to feel out of your depth. But the successful designers are the ones who move past the fear of asking silly questions.
The successful designers are the ones who get over their fear of looking stupid or asking ‘silly questions’, and who just keep researching and asking questions until they understand the domain.” — Arin Bhowmick, Designing for developers (2018)
Designing for the future of developer tools
Designing for developers requires understanding the entire developer journey, the needs of power users and beginners, integrating seamlessly, and leveraging the power of community feedback to drive decisions.
We are far past the days when software was delivered “just to get the job done”. In today’s day and age, good developer tooling serves as a force multiplier, enhancing developer productivity and resulting in better end-products.
As the space of developer tooling evolves, I am truly excited to see more designers embarking on the journey and sharing their valuable learnings towards better software for all.
The user experience of developer tools was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.
