The UX of Dev Kits
- Colin Bay
- May 7
- 3 min read
One much-neglected cause of technology pain is the ease of use of hardware and software development kits. For years, software and hardware manufacturers have released frustrating dev kits in hopes of getting market share for their platforms. Many companies find that developers trying to make it through the kit's getting started tutorial have failure rates well above 50% (we’ve seen close to 100% before)—and that’s just getting the point of running a sample project, not writing actual code! Imagine how unlikely the developers are to adopt the platform after an introduction like that. Software and hardware companies leave a lot on the table by not optimizing the kit experience.
Concrete has been helping manufacturers of developer kits to figure out how to redesign them. We’ve observed hundreds of developers struggling to use these kits that contain both hardware and software. Through hands-on analysis and user insights we’ve helped our customers optimize their kits to successfully increase adoption. Here's a sampling of the many things we’ve learned.
1. Developers put up with a lot.
It wouldn't be surprising if developers never stopped swearing (and in fact some of them don't stop). Judging from what we see, there's a big contingent of manufacturers and SDK developers whose attitude seems to be, "Ah, who cares? They're developers, they'll figure it out."
But such companies should remember that they have competitors. There are always alternatives. We've heard developers say, after an especially frustrating trip through a getting started guide, "Okay, that's enough. At this point I would go get a different product."
2. Empathy is hard.
Creators of dev kits are developers, so they definitely understand their customers and will make sure it's easy for them to use, right? Not right. Wrong, in fact. It turns out that it's really, really hard to set aside what you already know and imagine yourself inside the mind of someone who hasn't been working on this kit for the last two years and doesn't know that a fubar and a foobar sound similar but are used in completely different situations. It's hard to remember that in the beginning it wasn't obvious to you, either, how the components of this kit work together.
If it makes sense to you as an author of a dev kit, that doesn't mean it'll make sense to your developer customer.
3. The out-of-box experience is key.
You probably have some sort of getting started guide that covers hardware setup, installation, and a first-use tutorial that shows what the kit can do. (If you don't have such a guide, by the way, it's time you wrote one. Your adoption rate will go way up.)
In our testing and analysis, we see lots of implicit purposes in these getting started guides: serving as an encyclopedia to the kit's capabilities, teaching customers all the ins and outs and exceptions, blinking an LED as if that were impressive achievement, or even (apparently) causing fits of rage. All fails. These are not proper purposes of the out-of-box experience.
The most successful getting started sequences persuade by creating a good developer experience. What do they persuade the customer of? Three things:
I CAN: It didn't take me all day to do the getting started tutorial, so I believe it will be easy for me to develop with this kit.
IT CAN: This kit does useful things. It will be worth a reasonable amount of effort.
I SEE: There's clearly a set of useful next steps (more tutorials, well-written API documentation, etc.) for progressing towards creating my own solution with this kit.
4. Connective tissue is often missing.
Way too many dev kits assume you'll happily build a chair from atoms. After all, you've explained each element and its atomic weight, haven't you? Bzzzt. Sorry, that doesn't work.
You need to also give mid-level and high-level explanations about how the atoms (the hardware components or API calls) fit together or need to be used in a certain sequence. Good documentation provides this kind of connective tissue between low-level details and high-level functionality.
We're with Yogi
"You can observe a lot just by watching," Yogi Berra pointed out. Well, we've watched, and he was right: we've learned dozens of specific best practices that enable companies to create great developer kits that encourage mass adoption. What's more, if you improve your developer kit, then you can distribute 100x more kits without having to hire 100x more engineers to support the new customers. Tech support doesn't scale. But a well-designed dev kit scales very nicely—and so does revenue.
You can read more about the ROI of Dev Kit experience in this article, The ROI of Dev Kit Experience.
