Physical places have a collection of characteristics that make your experience. There are visual and audio cues that make up an ambiance. There are signs and design elements that point you to a particular way of using the space. The same is true, but in a virtual sense, with web and software. When those tools are made for a technical audience, everything that surrounds it is the developer experience.
Sure, usability, design, and product decisions all are inputs into developer experience. But within each of those, and everything that comes before and after, is content. Some of the biggest strides you can make with developers is through the written word.
This post will cover four areas where content provides a better developer experience:
- The portal home page
- The way a developer finds you
- The first experience using your dev tool
- The way you solicit and encourage feedback
How you approach developer content will greatly influence the experience your technical audience has with an API, a developer tool, and your company itself.
A great developer experience requires a web presence focused on developers. The best API documentation has a dev portal that is easy to discover and navigate. Even better, it answers all the questions a new developer brings:
- What is the service this supports?
- How can I use this API or dev tool?
- Why would I want to use it?
- What is the quickest way to try it out?
On the other side of these questions, and many others like them, is content. You’ll need to write words that help someone determine whether their problem can be solved by your tool.
For example, Typeform greets developers with answers to all these questions in a minimal landing page. You can see that you’d use the API alongside their conversational data collection platform. You can create forms, retrieve responses, and even get real-time notifications. Each of these options gives a description of how it is used, along with the option to learn more.
Finally, the primary call to action is to get started with the Typeform API. This initial guide serves as a jumping off point for Typeform devs and provides some contextual information. It’s not simply a reference of what’s possible, it helps developers figure out what to do next.
Content that welcomes developers will help them get a frame of reference for how they’d use your tool. But first they need to notice that you’re even an option.
Your developer experience starts with the initial impression. Where do they find you in the first place? Whether at a conference, on a forum, or your website, it’s content that will catch their attention.
If you were a developer wandering the halls of a two track conference, which talk would you attend?
- Demo of Gremlin’s Chaos Engineering Product
- How to Build Resilient Infrastructure
If you’d never heard of Gremlin, you’d probably choose the second talk. In one it sounds like a pitch and in the other, you might learn something. Gremlin would prefer to teach their audience, which is why they’d never give the first talk. In fact, the second talk could even include their demo in a way that would still keep developers in their chairs.
Gremlin’s Chaos Monkey Guide is a great example of first impression developer content. It’s more than 18,000 words that educates and inspires. It doesn’t need to promote Gremlin, because it instead shines a light on the company’s reason for existing. Outside of the tools and resources pages of the guide, Gremlin is mentioned only six times.
Because Gremlin created something useful for developers, the company now outranks Netflix (creators of the Chaos Monkey concept) on many pages:
Great content is the best way to help developers discover you. Epic guides aren’t the only solution. In fact, regular developer-focused blog posts can give you more opportunities to see what works for your audience.
You also can look beyond your own site. Go directly to developers to help them solve their problems. For example, you can answer questions on Stackoverflow or Quora. Look on Twitter for devs struggling with the issues your API or tool solves. Participate in relevant communities, showing up with helpful responses.
This sort of helpful content in all its varieties, helps start great developer experiences.
Now that you’ve attracted developers with your supportive content, it’s time to help them be successful. Once they’ve decided to use your API or dev tool, you want to help them see a win as soon as possible. Sometimes called the “time to hello world,” this is often where people start thinking about developer experience.
The developer portal can play a role here, with content like a Getting Started Guide. However, it can be useful to include educational content alongside your product itself. Sometimes you’ll see this implemented as “tooltips” to introduce an interface. Even better is to make it part of the entire experience.
When you create a Begin app, you have a choice of runtimes, frameworks, and example apps to get started. Here the content might be better described as code, and the user interface and minimal copy guides you through your first experience.
Next comes giving your project a name (the hardest part!) and then Begin deploys it for me. Because they use GitHub for login, they have the necessary permissions to push the sample code to my own repository. Now I can make edits myself outside of their onboarding experience—or follow their recommendations to tweak the app and see the changes live.
When you walk developers through their initial experience, they’re more likely to reach a moment of success. A positive first experience means they’re more likely to return.
Developer onboarding is a combination of problem, process, and product education. You keep that outward focus on the reason you got their attention in the first place, while introducing your company’s point of view and solution.
How can you better support developers for their first experience? From walk-through tutorials to micro-copy in their dashboard, you need clear, approachable content.
Once you’ve attracted the developer and given them some initial success, don’t end the conversation. Look for ways to continue to engage these developers, so they have an ongoing experience. Even better, see what you can learn to improve your content for current and future developers.
At its simplest, you can look at your website analytics. What pages are attracting the most developers? Where in a multi-step tutorial are developers leaving the site? When given a choice, which are they making?
I call this process finding your dev portal’s invisible audience. When I was at Zapier, we discovered that our “developers” surprisingly weren’t the sort that wanted to write a lot of code. Similarly, dev-focused Twilio has built programming-like tools on top of its foundational APIs. These sorts of insights aren’t possible if you stop the conversation with developers who make it through your initial experience.
You can also ask for feedback directly in documentation. Developers will click those “was this helpful” widgets. They’ll write a comment. All you have to do is provide the opportunity and—here’s the hardest part that most people don’t do—actually read and react to what’s written.
There are plenty of other ways to get developer feedback. You can solicit it via email, ask on Twitter, review GitHub issues, and talk to developers at events, just to name a few. All of these require some content to engage the developer’s feedback.
Feedback helps you understand your current developer experience, which you can then use to make improvements. Your developer experience upgrades are likely to include some kind of content: more problem-focused articles to attract initial attention, a revamped developer home, or a more streamlined onboarding.