One of the things I love about being the design leader for IBM’s Cloud portfolio is the diversity of products, and of target users that we get to design for. We design products aimed at system integration experts (App Connect), data scientists (Data Science Experience), business analysts (Cognos Analytics), DevOps engineers (Cloud Event Management), and many other user groups.
However, we also design several IBM products that are specifically aimed at developers, and we know that developers often have somewhat different requirements and expectations compared to business users and everyday consumers. So, I thought it would be interesting to write about some of the nuances around designing for developers.
A couple of my fantastic Design Leads who work on developer products collaborated with me on this article, so a big thank you to them:
Jay Cagle is the Design Manager for our IBM Cloud App Platform. Previously, Jay spent many years working on IBM’s influential WebSphere Application Server and related tools.
John Murray is the Design Lead for Microclimate, an end-to-end development environment for modern cloud-based applications. Before this, John also worked on the [email protected] developer tools.
So, without further ado, here are 7 significant things we’ve learned over the years with regard to designing products for developers.
1. Develop a thorough understanding of the domain
As with any other design brief, for your dev product to be successful, you absolutely must gain a solid understanding of the problem space and of your target users.
Many designers are not themselves developers, and so can find working on dev products to be intimidating. Certainly within IBM, many of the talented young designers who join the company can initially be taken aback by the amount of technical knowledge needed when designing some of our products. But 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.
To be clear: when designing for a developer product, you don’t need to be knee-deep in code yourself, but you do need to understand the dev world. Yes, it takes investment if you don’t already come from that field, but it’s crucial. There are no shortcuts.
“It’s a bit like when you’re traveling in a foreign country. The locals don’t generally expect you to be fluent in their language, but they do like you to at least have a go.” (John Murray)
Thorough research will help you understand what tools, technologies, concepts, and interaction paradigms your target audience is already using, and this will hugely help you as you seek to design solutions that meet your users’ needs. A good place to start can be to work through existing online tutorials aimed at your target users, as this will help you familiarize yourself with key terms, concepts, and workflows.
- Know your target user’s favorite tools
Following on from the previous point, the tooling picture is particularly important to understand when it comes to designing a product aimed at developers.
Developers already tend to use a very large number of tools, so in some ways, the last thing they need is yet another tool to learn. If you’re smart, you’ll use this knowledge and won’t try to re-invent the wheel. If there are existing tools that perform a certain function really well, see if your new offering can support an integration (or plugin) for such tools.
There is also a human, emotional element to this picture: many developers will have certain favorite tools that they like to use. This could well include a favorite IDE, editor, code repo, as well as various build tools, etc. While some of these choices will simply come down to the personal tastes of individual developers, if you carry out enough research, you will probably find that common tooling patterns emerge. This information can be crucial to the success of your product as, in reality, it’s likely that your product team will only be able to offer support for one or two IDEs, editors, repos, and build tools, so it’s well worth doing your research and delivering support for the most commonly used tools amongst your target audience.
3. Devs typically want lots of control
Modern designers are constantly told that good design is simple and minimal and that offering fewer options, bells, and whistles is the way to go. However, when you are designing for developers, there are some other important factors to consider.
Firstly, many developer specific products need to cater for inherently complex user goals. While many consumer apps help people achieve one fairly simple task (e.g. send an email, book a taxi, add a filter to your cat photos, etc.) dev products often need to support a plethora of technologies, languages, and standards, and to integrate with many other components.
Secondly, many developers actively want fine-grained control over various areas of their technology stack. Unlike many consumers, developers don’t always want the software vendor to just set sensible generic defaults; they want to be able to tweak low-level settings themselves to optimize performance, security, and interoperability for their specific contexts.
So 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.
- Don’t assume that a GUI is necessarily what’s needed
Designing software applications and mobile apps pretty much means designing graphical user interfaces (GUIs), right?
Well, when it comes to working on a developer product, not necessarily. Or, at least, not solely. Non-graphical user interfaces are often a crucial part of a developer’s toolkit.
Many developers spend a lot of their time working in an IDE and in the terminal, so forcing them to use a web browser GUI to perform all of your product’s tasks can be frustrating. Also, developers often have repetitive tasks to perform and, understandably, want the quickest route possible to perform such actions. In many cases, this will be running commands in a terminal.