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 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.
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
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.
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).
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 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.
Leave a Reply