Like other people, developers appreciate when something works well, looks good, is easy to use, is reliable, and saves them time.
If a developer has the choice between two functionally equivalent options, and one of them makes life easier for the developer or has a superior design... no prizes for guessing what they’d choose.
So, if you’re building a tool that will need to be installed, configured, customized, integrated, or maintained by developers, developer experience is key to attracting new customers, onboarding new users, and retaining them.
What is developer experience?
Developer experience (DX) is all about how developers experience your tool and how easily they can use your technology within their projects. A developer will sometimes “use” software in the same way as an end user. But when it comes to DX, we’re talking about how a developer “uses” software to develop a solution.
That means they not only need to know it will solve the problem for the end user, but they also need to know it will help them solve their development problem. This means that your technology needs to be easy to install and test. Once they can test it, they can better evaluate if it’s fit for purpose, easy to integrate, maintain, and so on.
Things that help with this are clear communication and detailed docs. If it’s open source, that can help, too (so they can see the code and modify it if needed). But really, DX is relevant for all aspects of your product, from your API to the level of support provided.
Why does developer experience matter?
DX is kind of a big deal. Developers can play a huge role in the uptake of your product, especially when you consider they are likely to provide guidance on what tools their organization should invest in, even though the final decision usually happens at the executive level.
Developers are in charge of researching, testing, and implementing solutions. If they have a good experience, they’ll probably tell their colleagues about it (devs love to talk about new tech they’ve discovered), post positive reviews, and hang around for longer.
But if their experience falls flat, they’ll look for another solution. Or, if you’re lucky, they’ll provide feedback so you can make improvements. Side note: if someone goes to the effort of providing feedback if something isn’t right or working properly, it means they care enough about the work you’re doing to care about the end result - which is a good thing.
So, if your audience or users include developers, it’s critical to get a handle on DX and make sure you’re getting it right.
Building a great developer experience: 9 best practices
DX best practices have a lot in common with general UX best practices, but are tailored to developers. So the following points, while relevant to users in general, focus more heavily on technology and the specific needs of developers.
1. Understand your users
Get to know the developers who will be using your software. That means you may need to:
- Talk to them
- Survey them
- Do user testing
- Ask for feedback
- Create personas
Make sure that what you’re building fits their needs and expectations and helps them achieve their goals. Communicate this with statements like “we know that foo is a problem, and we’re looking to resolve it by doing bar.”
Having roadmaps or other details available for consumption can help manage developer expectations. It also allows consumers to provide feedback to improve the product and gives them a chance to voice their concerns in an open environment.
2. Make it stable
Something that could lead to developers abandoning your product is instability. So, focus on making it stable and reliable. You’ll need to do proper testing before each release as well as regular bug-checks. Invest in reliable hosting solutions - aim for 99%+ uptime and offer guarantees, if you can.
3. Make it fast
“I love waiting for things to load...” said no developer, ever.
It’s safe to say a significant part of your developer experience involves speed. Make sure your application runs fast and that it’s also fast to install and integrate.
4. Modern UI
Make your user interface modern and familiar both for the developers’ back-end implementation and the front-end for end users. Look at similar websites, apps, and platforms - don’t get too creative with how yours is structured (navigation, design, style). This will help users feel comfortable with the interface quickly and reduce the time it takes to learn how to use it.
Having a modern UI and design is important, but even better if it’s flexible and can be configured to fit in with other UIs. For example, we have lots of ways TinyMCE can be customized to fit the most modern and trending UIs, like with custom skins and icons.
5. Support
Provide plenty of support options, including both interactive and self-service (developers love to figure things out for themselves). Offer:
- Live chat
- A knowledgebase
- Help sections
- Training videos
- Roadmaps (for bonus points, allow feedback and contributions)
All of these support options can help developers feel more comfortable with using your product or platform from the beginning. Plus, they can feel confident that if any problems arise, you’ll be there to help resolve them. The more support you can offer, the easier it will be for new users to trust you and your product.
6. Communication
Communication relates to support, but let’s break it down further. Here are some ways good communication can improve your developer experience:
- Set up an onboarding sequence/steps - Help developers get started with your product as quickly as possible after signing up.
- Make your communication clear - Avoid extra fluff and don’t use words like “very”. Don’t talk up your product too much (show don’t tell). Your developer audience will want to make up their mind for themselves.
- Make it searchable - Make communications easily searchable so developers can find answers to their questions quickly, like “is foo deprecated yet?”
- Detailed documentation - Keep in mind that developers may have a range of experience and backgrounds, so also account for beginners by providing detailed info or links to even the basics.
Never assume that your audience are Computer Science grads or even have English as a first language.
- Detailed release notes/changelogs - Developers will look at these for info on what’s included, what’s been deprecated, any potential conflicts, bug fixes, vulnerabilities, risks, enhancements, and new features. That way, they can be confident (and motivated) to update to the next version.
- Talk in your developer audience’s language - Keep your tone frank, honest, and helpful. Use consistent terms relating to your product and documentation. Use a glossary of terms to help keep your technical writers and users on the same page.
- Be transparent - Your audience will appreciate transparency, so if there’s a problem, bug, downtime, data breach/loss, or something else, make this info visible to your developer users ASAP. Let them know what you’re doing and when you expect things to be fixed.
- Be clear - Reduce uncertainty to increase confidence in your product. Developers shouldn’t be second-guessing themselves over what will happen after they configure a setting in the back end. Add contextual information to help confirm how things work and what will happen next (e.g. documentation and code comments if it’s open source).
7. Keep it bite-sized
Information is great, and a lot of developers are detail-oriented people who like to have all the info at their fingertips. Still, it’s important to deliver information and context in a way that’s not overwhelming. For a start, avoid walls of text and use small paragraphs. Break up information with headings, images, and icons to make it easy to scan.
Aim to keep things succinct wherever possible. If more info could be useful but you don’t want to overwhelm the reader, you could link to a more comprehensive source like docs.
In your knowledgebase and documentation, break content up into logical topics and sub-topics to make it easier to find and digest specific information. The same principle applies if you have training videos or an onboarding system. Break them up into steps and allow your users to work through at their own pace.
8. Make it open source
It’s not always possible, but making your software open source is always appreciated by developers. That’s because it’s free, for a start. But it also means they can really look at what’s going on under the hood and customize it for their needs. They may even want to contribute and be part of the community around your product, in which case, make sure you provide clear contribution guidelines.
9. Don’t forget other audiences
Developers are generally involved in making decisions about what products they use, but they’ll still probably need to get final approval and buy-in from others (especially for bigger purchases). So, while developers are at the center of your DX efforts, you can help them get support for your product by making your product offer clearer to other team members (including CEOs, CTOs, and CIOs). This might look like tailoring your website and marketing content to talk to more business-focused or less technical audiences, alongside your primary developer audience.
Do you use Tiny? We’d love to know what you think
We’re always keen to hear from our users and improve our developer experiences. What areas can we improve your experience as a developer who uses (or is considering using) Tiny?
We’ve just updated our developer onboarding experience to help you get up and running with TinyMCE in 5 minutes.
Also, read more about open source WYSIWYG editors.
Send us a message and let us know what you think, or join the conversation over at @joinTiny on Twitter. We’d love to hear from you!
