With multiple trends pointing at the growth of the developers buying power in organizations, the market for developer-first products and services is under a constant growth. Companies like NewRelic (IPO in December 2014), Atlassian (IPO in December 2015), Twilio (IPO in June 2016) and other more recent successes are demonstrating that delivering a product for developers can grow to a significant business.
Product design and its value/benefits for the end-users are becoming a much bigger part in the product (and, therefore, business) success (💰💰), since it's the end-users (i.e. developers) that get to decide what to buy. In fact, a modern goto-market approach based on the Product-Led Growth principles is focusing on the importance of User Experience in the buying decision.
In this article you will find:
- General approach based on involvement phase of a user with the product
- Aspects to consider when attracting prospects' attention
- Aspects to consider when offering a product trial
- Aspects to consider for daily use of a product
- Aspects to consider allowing users to amplify the product impact
- Summary and recommendations
💡 Approach based on Interaction Phases
Based on the above, the goal of Developer Experience design is to match the needs of developers (users in our context) in the best possible way. Do these needs remain the same throughout the lifecycle of the interaction of a prospect developer with the solution or do they change? According to observations made by a number of vendors in the past, the needs / expectations of the users are very closely related to the phase of their interaction with the product.
Lets consider breaking the product interaction lifecycle into four basic stages:
- Notice / Attract - How does a prospect notice the product and gets attracted to the value it may introduce
- Try - How convenient is it to try the product and start getting the value
- Use - What is the experience provided by the product in the regular ramped-up day-to-day use
- Amplify / Grow - What amplifications does the product offer for those who want to leverage it beyond the typical use-cases
For example, functionality related to ease of onboarding and out-of-the-box settings would be attributed to the try stage, whereas advanced integrations with additional products or analytic reports would fall somewhere between use and amplify/grow. This phase-based approach is also applicable to the more traditional UX, but, when dealing with DX, it can help prioritize and delivery systematic impact on the journey that developers have with the product.
The guide below provides suggestions on particular topics to take into consideration when designing a developer-first product targeting each of the interaction stages mentioned above.
🕛 Notice / Attract
How will the developers (that are potential users of your product) learn about its existence? Where will they generally look for solutions for the kind of problem you are aiming to solve? Will your product be somehow represented there and will it stand out from the "noise"?
Web site
A web site representing a product/service targeting developers should contain fundamentally different information, when comparing it to a typical B2B product site. A lot has been said about the content and the language that developers appreciate. Clarity, brevity, being to the point, using the proper terminology - all these are among the leading factors appreciated by the target audience.
When developers are your target audience, you need to consider the state of mind involved. People who don't appreciate being sold to. People with limited time and attention span, who'd like to understand the value proposition and the "how to" as soon as possible.
Here is an example of a homepage targeted at such an audience:
Notice the very sharp difference between this and the following homepage, that is targeting an enterprise decision-makers audience:
Both the substance and the language (not to mention the look-n-feel) are very much affected by the audience being targeted.
Community presence
Developers make intensive use of various communities to look for solutions for common challenges. Depending on the domain of the problem, Stack Overflow, Dev.to, Reddit or other community information exchange platforms are often serving as the first place where one would expect to find some sort of information about potential solutions to use.
Here is a sample search result for finding an API to send SMS on StackOverflow. Naturally, developers facing this problem will be inclined to try solutions / approaches suggested by their colleagues.
Open Source presence
Releasing useful open source projects is always a huge contributor to building the developer-facing presence. Even when your product is not an open source, having open source repositories for your SDK, samples and additional resources can be considered a huge plus.
Here's an example of an open source module representing an SDK for a proprietary service. Note the amount of stars on the Github repository.
Integrations / marketplace
Will your solution be used by its target users (developers) in integration with another developer solution that is already in their stack? Is that other solution extensible? If so, one of the ways to improve the overall experience is to publish a plugin.
An example of Service Providers publishing HashiCorp Terraform Plugins.
Documentation
While nobody is reading the documentation thoroughly during this stage, checking that it exists and that it conforms with expectations / best practices can definitely overcome certain concerns.
Stripe API documentation, is an example of a very professionally built developer-facing documentation.
🕑 Try
Let's say that we 'aced' the first step and managed to attract the attention of a potential user. What does it take to try our product (remember: developers like to get their hands 'dirty' and try things)?
Trial of the product can be done in a number of phases. Some people would be so convinced by the product value (from the previous stage),that they'd be looking for trying out the product in their environment. Others - would like to take a more conservative approach and would be looking for some playground not linked to their environment.
Online playgrounds
Online playgrounds, gaining traction recently, are solutions, integrated in the product/service website, that allow trying it out (getting a hands-on experience) without deploying anything on one's laptop/cloud.
One of possible implementations of the online playground is via integration into a tutorial / documentation, similarly to how it is done in the Golang Tutorial. Another great example is a Kotlin Playground by JetBrains.
Playgrounds can cover either a single process/tool, or represent a whole virtualized environment, such as ones created with Katakoda.
Delivering an effective online playground may reduces the upfront costs required for trying out your solution, and, if the solution itself provides the relevant/expected benefits, heavily increases the chances of progressing ahead from the trial stage.
Containerized trial
If your product requires deploying any agents or servers in the customers' environments, providing a containerized trial (even if it is not a fully production-grade supported deployment) will ease on the initial deployment and will reduce the friction. Using Dockerhub for publishing such container images with easy documentation on how to deploy them makes the trial deployment much more user-friendly.
For some of the examples (that may also be used for production-grade containerized deployment), reference the MySQL Server, TeamCity Server or NetData Dockerhub postings.
Free / Trial Service Account
When your product/service contains a service (either SaaS Management or a full service) offering, it is 100% imperative to offer either free or trial service accounts.
Time-limited trials used to be more acceptable option in the past for both consumer and enterprise services. In modern developer-first products, this approach is a bit more problematic, and functionality/scale-restricted or even freemium offerings seem to gain more traction.
Almost every time developers will prefer the free/freemium offers, due to the following:
- There is no immediate "sales" motion behind them. Free/freemium versions are there to be used as real tools, as long as your demands fit the constraints.
- Using (and benefitting from) the free version increases the "stickiness" of the solution, as it can be used in production. This, in turn, increases the chances of converting the account to a paid one, as it is difficult to do a meaningful trial with strict time limits. (Even psychologically, investing in such a trial, knowing that it might be a complete throw-away is something that is less optimal)
- Depending on the value your solution provides, it can be used for personal/open source projects in its free mode, increasing the loyalty and the possibility that it will become adopted in work environments.
Defining the conversion point for freemium accounts to become paid is a science (or, some will say 'art') by its own and deserves a dedicated discussion / guide. Some of the most prominent approaches are:
- Consumption based (size of storage, amount of events)
- Users based (limited amount of users in free/freemium accounts)
- Functionality based (collaboration features, enterprise features, etc... are only available on paid accounts).
CLI / API Samples
When developers interact with products/services, some of the user flows rely on Command-Line Interfaces (CLIs) and Application Programming Interfaces (APIs) rather than User Interfaces. This dictates that both CLIs and APIs should be treated as the face of your product and should be designed, tested and documented with the same attention to details as UI.
This approach can be extended to things, such as, but not limited to, Chatbot interface, if your product is offering one.
Providing a documentation in a developer-friendly format, or even providing open-source samples of usage of your CLI/API on Github can go a long way in terms of encouraging the adoption of your technology and making its frictionless.
Out of the box settings
Last, but definitely not least, on the trial stage is the ability of the product to function and to provide actual value without someone needing to spend time and other resources to configure it. In fact, as mundane as this point may sound, it is a real difference maker when it comes to the trial stage.
The faster the product starts showing real value, the more likely the probability that its prospect (the person trying it out) will consider adopting it.
In recent years, the industry has even come up with the measurement of this, adopting a term of Time to Value. The investment, in the trial stage, is that of our prospects' time and the value the product shows is the expected return on that investment.
🕒 Use
This is a critical stage: our potential users arrive with the maximal 'inflated expectations' to this point, based on their successful trial, and are starting to use the product in their environment. The ability to be as good in 'real life' as in demonstration/trial is crucial in successful product adoption and in achieving customer loyalty.
User Interface
If the User Interface plays a significant role in the interaction of various users with the product, its design is a very important aspect of the overall product work.
There are various approaches to designing user interfaces and a lot has been said and written about this.
When dealing with developer audiences, it is important to remember that the UI will serve as a tool for completing tasks (more than in any other enterprise product). Special emphasis should be made on what is the role of the user interacting with the system, which tasks the user is looking to accomplish and which data/information exists in the system to help them accomplish the tasks.
CLI / Scripting
Automating interactions with developer-first solutions is a significant portion of user-flows for developers.
Similarly to the importance of CLI in trying out the product, its importance in adopting the product for everyday use is also very significant.
When designing the CLI syntax, it is always recommended to stick to standards (such as POSIX CLI Syntax or Microsoft's), reducing the adoption friction.
Documenting how to do this, providing samples and knowledge base article around automation via CLI will be of a great value to the user audiences.
API
Just as with CLI automation, providing integration and automation capabilities via APIs increases the value your users will extract from the product. Even more so, it can have a positive effect on the stickiness of the solution - once it is integrated into automation processes, the extent of its usage grows without a dependency on human users and their availability.
Designing an API, much like designing a User Interface, has its own methodologies and best practices that should be studied closely and applied, in order to increase the chances of success.
Customization of Settings
It is very likely that during the usage stage of your product its users will want to customize its behavior. Out-of-the-box settings are only useful for a handful of common scenarios, and the ability of the product to provide a flexible configuration is a big plus.
In fact, the experience learnt from years of designing Enterprise Security Products have delivered a methodology of Policy Model. In these products (the methodology can be extended to other products as well), the main value is the ability to enforce an organizational security policy using the capabilities of the product. The policy, in turn, can be customized either for different networks, different users, different hosts, etc...
The level of customization (on a scale of flexibility=complexity and lack of flexibility=constrains) should differ per product. It is very difficult to come up with rules of thumb in this department, except for a very clear need to do a meticulous system analysis in this case.
Configuration Management
Regardless to complexity vs simplicity of the chosen configuration/policy model, the question of a management lifecycle for configuration (Configuration Management) is always important, especially to developers. Every change in the product configuration that can affect production environment could/should undergo stages of review, delivery and monitoring.
Once upon a time, many mature/advanced products offered some sort of a configuration management lifecycle built-in. Some products had a two-phase commit of changes, others added versioning and approval flow.
Developers don't need any of it. They already have configuration management flows centered around software versions repositories (such as, for example, GitOps.
Automating configuration management in your product via CLI or API, as mentioned above, allows developers to use their existing configuration management lifecycle and just to a the configuration of your product to it.
Providing integration with configuration automation tools (CAPS - Chef, Ansible, Puppet, SaltStack), or, for more cloud-native-adopting users - HashiCorp Terraform Infrastructure-as-Code could make your product fit very seamlessly into existing configuration lifecycle. (There are significant differences between mostly imperative configuration management offered by CAPS tools vs declarative one by Terraform, but this is a subject for another article.
Documentation
Developers expect the product they are using to be documented in a form that looks familiar, provides answers to expected questions, and doesn't overburden with unnecessary formalities.
Certain types of documentation have best practices or even a golden standard (sometimes, even tools that help creating it). For example, when documenting REST APIs / Swagger files, consider using ReDoc. As the industry providing the APIs has undergone a significant maturity growth in recent years, best practices have been developed and should be adopted.
Similarly, when considering documenting CLIs, best practices by Google or Microsoft, as well as open source standards, like docopt, can provide a good direction.
Being standard, looking familiar - will eventually contribute to reducing the friction of adoption.
🕔 Amplify / Grow
While every product / solution is targeting solving a specific set of problem(s), exceptional solutions can deliver a longer-lasting (and, therefore, much more "sticky") value to their users.
Developers will benefit from long-lasting value, allowing deeper integration into their stack, ability to handle a more diverse set of use-cases, providing insights and data beyond what was previously available, etc...
SDKs
SDKs are the next step of ensuring that your users "stick" to your solution for a longer term, after automation via CLIs and APIs. SDKs usually allow a richer experience of interacting with your product and ensure closer ties between the developers and the "platform".
When providing SDKs, it is important to ensure that they are available for all the relevant programming languages (depending on the type of the audience), have a great developer-friendly documentation and come with usage samples.
One critical thing is to have them always up-to-date. This is among the things that ensure the trust of the developer using the SDK in the platform. If the SDK is not up-to-date and there is a functionality drift between the product capabilities and what is available / accessible through the SDK, the willingness to trust it and to use it will inevitably go down.
Integration with additional solutions
In the environment that desires to automate everything that can be automated and gain maximal possible value from collected information, the most important currency is the ability to integrate with other elements of existing pipelines/workflows.
While having an open and well-documented API allows integration with practically anything, it also requires effort to implement. Providing out-of-the-box integrations (sometimes also called "single-click integrations") with products/solutions that are frequently used by the same people that use your product, is a clear win. Contributes to user satisfaction, provides value beyond the core values of your product and increases its stickiness.
☑ Summary
The above guide was built in an effort to drive the attention of individuals building developer-first products to various product aspects and to try and map the importance of each, as the user progresses in product adoption.
As developers are becoming a more significant force in choosing the organization's technological stack, the amount of possible options will continue growing. Feel free to add your experiences in designing developer-first products as comments.
Top comments (0)