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 Swift@IBM 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.
2. 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.
4. 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.
“Many a developer has cursed software that has forced them to use a pretty GUI to perform certain common tasks when a good set of terminal commands would have enabled them to get things done much quicker.” (Jay Cagle)
As a designer, you can still add lots of value to the non-GUI components of the product. For example, even with command line tools, you can help by ensuring that the terminology and syntax structure used match what you observed your target users use when you carried out your user research. Similarly, if your product has a config.xml file or other similar configuration files, you can ensure that the structure and help comments within these files are as usable as possible.
5. Devs typically don’t want to be tied into one vendor or tool
Another thing that we’ve learned over the years is that quite a few developers have a strong preference for open-source tools over propriety ones whenever there is a like-for-like choice available. Now, as designers working for IBM, this might seem like it would pose a huge problem, but it doesn’t necessarily have to. For a start, IBM is a major contributor to many key open-source technologies, such as OpenJ9 (an open-source Java runtime), MicroProfile (an open-source framework for developing microservices), and Open Liberty (arguably the most flexible server runtime available to Java developers today).
Plus, whenever we initiate new IBM software projects, we have to be very aware of what good tools already exist, what preferences our target developers already have, and then be very clear about what specific value we (IBM) can add to the target domain space.
An example of how our designers have worked through such factors can be seen in the Microclimate project. With Microclimate, IBM wanted to offer modern app developers a really great end-to-end developer environment that would let users create, edit, and deploy their applications into the cloud. From research, we knew that our target developers typically wrote their apps in Java, Node, and Swift; that they tended to use certain existing IDEs and source repos; that they liked to deploy their apps in Kubernetes containers; and that many were already using Jenkins build tools. So, with Microclimate, we didn’t seek to disrupt any of these individual components, but rather focused on bringing additional value to our users by providing an integrated environment that brought these things together and that offered new capabilities on top of these existing pieces.
Another thing to be aware of is that devs typically don’t like it when they have to rely on a load of generated code from a vendor’s product that they don’t understand. So, it’s best to be as transparent as possible about what additional code is being generated by your product, and to allow your developer users to be able to view and edit this code if desired.
6. Increasingly, devs are key influencers in purchasing decisions
These days, developers have more influencing power in terms of which tools and services their companies adopt. There are various implications here for software vendors. Firstly, you need to ensure that you have product marketing that is aimed at developers, not just at CTOs and senior technology strategists. But over and above whatever marketing you put out, it’s also essential that you provide developers with a quick and easy way to try out your product.
Devs typically try out lots of products, so a good dev product has to have minimal friction in terms of getting started, otherwise many devs will simply give up and move on to try an alternative and you will have lost them. (Jay Cagle)
IBM has been on a learning curve in this regard over recent years, and our designers are often now involved in improving the first use and early adoption experiences for our products. A good example of this can be seen with the Open Liberty interactive guides. Unlike traditional software docs, which simply provide static information about how to use the product, the Open Liberty guides are interactive, offering the user relevant code snippets which they can run from within the guide itself. This has led to a much more engaging experience for developers new to the Open Liberty platform.
7. Remember: all the usual design best practices still apply
While there are certain things unique to designing for developers (see above), it’s also important to remember that developers are just people at the end of the day — and therefore all of the fundamental design principles still apply.
So, before you start designing anything, remember the vital role of user research; know that failing fast and using feedback loops is the way to go; understand the 80/20 rule in user experience; remind yourself that you should build experiences not features; that the design’s in the details; and that using the IBM Enterprise Design Thinking framework really will help you achieve the best outcomes.
With thanks to John and Jay for sharing their experiences — and to Danny Skinner for the original artwork used in this article.
Arin Bhowmick (@arinbhowmick) is Vice President, Design at IBM based in San Francisco, California. The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions.
Note: Thanks to Arin for the contribution. Originally published on Medium