Getting to the point is essential for a smooth developer onboarding. Within seconds, you need to answer your product or project's what, why, and how.
But it can be hard to put ourselves in the shoes of a developer who knows nothing of what we do. That's why it's essential that we test and improve the onboarding path we give developers.
One way to do that is the 10-3-10 test. It's quick to perform, requires no special tools, and pretty much anyone can do it. Here's how.
From zero to Hello World in ten minutes
The idea behind the 10-3-10 test is pretty simple. A developer should land on your site without any context and achieve the Hello World state within 10 minutes.
Before a developer can get to that point, they need to know what the product does and then register to get a developer account.
Within all three of those milestones -- understanding, registration, and first product use -- lurks danger. At each stage, you're asking the developer to give you something on trust. At first, it's their time, then a small amount of information about themselves, and finally, it's both their time and their mental energy. It might sound over the top, but you need to reward the developer for each of those. Get the reward wrong, and the danger becomes apparent: the developer will lose trust and look elsewhere.
Drop-off is real
Work by Microsoft Research shows that typical web users decide whether to stay or go within 10 seconds of arriving at a web page. There is even an old study that suggests web page visitors form an opinion within 50 milliseconds of landing.
Keeping someone on the page long enough to explain the offering is just the start, though. Research on conversion rates by product analytics firm Heap suggests that 63% of SaaS users fail to complete product sign-up.
We are operating in a world of spam, clickbait, unregulated advertising, and other underhanded attempts to grab our attention. People have trained themselves to apply harsh relevance criteria to the information they find on the web.
Arguably, developers are not typical web users. Whether that makes them more or less patient will depend on their level of motivation, among other factors. What is clear, though, is that you have very little time in which to capture a developer's attention and then turn that into an interest in your product.
Three questions
There are multiple pressures on your developer onboarding flow. Product marketing might have a particular wording they want you to use. Someone in the growth team wants to try an experiment they read about recently. The VP of Sales is pushing for more data collection to assign new developer sign-ups to the appropriate salesperson.
Whether good or bad, the reality of these demands is that they can lead to a loss of focus. And in most companies, the demand for such change never really stops.
The 10-3-10 test is simple, repeatable, and quick, helping you measure whether you're continuing to serve developers. It asks three questions:
- 10 (understanding): Can a developer get a solid idea of what your product does within ten seconds of arriving on a developer-targeted landing page?
- 3 (registration): Can that person register for a developer account within three minutes of landing?
- 10 (first use): Can they get to Hello World ten minutes after first landing on the site? Whether you perform each test informally yourself or set up an ethnographic research session, it's worth diving into some of the factors that influence each stage first.
Understanding
How often have you been to a product website and come away none the wiser about what it does?
Competing demands too often lead to product pages that say a lot but communicate nothing. A common scenario is messaging that attempts to address too many different audiences at once. If a vendor compromises its message to serve both developers and, say, procurement managers, it'll serve neither well.
Sometimes, it's just that companies overthink how they talk about their products. As someone writing about a product, it can be hard to extract yourself from the context you have. It's tempting to build every comment, every meeting about the Chief Marketing Officer's vocab preferences, every barb thrown by the competition into that one very clever headline. But does that serve someone who just wants to know what problem your product solves and how?
The first step to passing the understanding test is to make sure you have a dedicated space to speak primarily to developers.
Next, stay specific and tell developers what your product does for them. Consider CodeSee's own home page. The headline and sub-head get straight to the action:
Visualize codebases faster
Map an entire codebase in just a few clicks.
The short follow-up paragraph then expands on that in a way that sticks entirely to the facts of how the product benefits developers.
Avoid the temptation to over-egg how you describe your offering. "SMS API," rather than "customer engagement solution." That kind of messaging has its place for certain audiences, and it makes product marketers feel good, but for developers, it's just another hurdle in the way of understanding whether that thing solves a problem that they have.
To pass the first test, a typical developer should understand the practical purpose of your product within ten seconds of landing on your developer home page.
Registration
Registration is a chasm in your developer onboarding. This is where developers must put the most trust in you by providing personal information without a clear idea of the pay-off. Provide them with guide ropes, way finding, and a hint of the reward that is to come.
First, how do you get a developer from the landing page to sign-up? The button or link you provide needs to be immediately obvious, not so wordy that people are tempted to skip it, and yet still communicate what's to come. Oh, and the copy must avoid scaring people off.
"Get started" and "Start now" are common choices. However, at least one study has shown that "Get started" attracts clicks, but not all are from people who are ready to try, download, or buy your product.
The Miro API's "Start building" is clearer. Click that, and you know you're about to get hands-on with the API.
CodeSee's "Try Maps now" communicates a lot in three words. "Try" tells you that you're going to be hands-on with the product while making it feel casual rather than intimidating. Naming the product enforces what's coming next, and "now" adds a sense that clicking will lead to a fast pay-off.
That's a lot for a button.
The registration process itself must stick to the principle of "minimum viable information". Sales and marketing colleagues might push to capture more and more information during registration, but your primary aim here is not to add another lead to the CRM. Instead, registration is about enabling access and then allowing the rest of the experience and product to win over the developer.
That doesn't mean you can't ask for more than just an email address and password. Most people have some tolerance for providing extra information. However, you should aim to frame at least some of those additional questions in terms of how they'll benefit the developer. Twilio's registration process is great for this. It asks some questions that might help their sales funnel but also collects information, such as your preferred programming language, that makes the developer dashboard more helpful.
To pass the second test, a typical developer should be able to get a developer account within three minutes of landing on your developer home page.
Hello World
Providing a smooth path through registration is good, but it's only a staging post. The developer's goal is to see for themselves whether your product solves their problem and whether they like the idea of working with your company.
There is enormous scope for ways to improve the path to Hello World, so let's focus on one thing. When the developer first logs into your dashboard, take them by the hand through the steps they need to achieve something worthwhile.
Such a first use experience is more than flashing up a quick-start guide or a click-through signposting of the dashboard's UI. It is a highly focused path that takes the developer from no knowledge of your product to that Hello World interaction. It builds on the supplemental information you've gathered during sign-up. Are they a Ruby developer? Great, get them to download your SDK's gem. They told you they work for a large company? Suggest they link their new account with Okta or other SSO providers to simplify integration with corporate sign-on.
That highly focused first use experience should contain everything the developer needs to get a feel for your solution and what it's like to develop with, in as efficient a way as possible.
If a typical developer can get to Hello World within ten minutes of the first landing on your developer pages, you've passed the 10-3-10 test.
And there's more
The 3-10-3 test is a blunt instrument, but it's useful as a way to keep us honest about whether our onboarding serves developers. It works well for commercial products, and there's plenty of scope to adapt it to onboarding a developer onto a team building a product or a developer joining an open source project.
Microscope picture by Public Domain Pictures
Top comments (0)