First run experiences for developer tools

Even if you are building for technical users, the first run experience still matters. In fact, it matters more. There's nothing like a poor initial experience to make developers give up and find (or write their own) alternative.

We have just published a review of the best load testing tools for developers and I was surprised at how many bad first run experiences the older tools had, almost all because of Java.

There is nothing inherently wrong with building a tool in Java. Indeed, some of the most popular code editors/IDEs from JetBrains are written in Java, work well across multiple platforms, and provide a highly polished experience.

However, in trying some of the older load testing frameworks, I was thrown back into the early 2000s with zip archives of .jar files packaged into unusual directory structures and forced to run .sh scripts to spawn Java processes. And macOS blocked them as unsigned processes.

This kind of experience might have been the norm last decade, but in 2021 the user and developer experience quality bar is now much higher.

What first run experience do developers expect?

• Packaging that is native to the platform. This might be an install wizard, but it's now more common to integrate into the system packages or native app store.
• Files installed into the "correct" location. On Windows this is "Program Files". On macOS it's a single .app file in "Applications". If it's a CLI then install the binary into my PATH (or at least give me the option automatically append to my PATH) so I can immediately start using the program. Installing weird binaries inside folders anywhere else is not a good idea. Don't make me run weird shell scripts or bat files.
• Launching the app should consist of double clicking the application binary / icon or running the terminal command. For desktop apps it must also show up in whatever quicklauncher I'm use e.g. Spotlight, Alfred or uLauncher. On macOS I use Raycast. Don't install system services without my permission.
• When first launching, the app should start up quickly and present a first run dialog window of some sort. This can give me the option to have a quick product tour, but I should also be able to skip it. Every good SaaS app does this, so desktop apps should as well. Don't dump me into an unfamiliar interface.
• Alternatively, provide a quick launch view that offers some tutorial options but also lets me start new projects or open recent files. If I know what I'm doing I can ignore the tutorials. This can also serve as a good dashboard for highlighting future updates and improvements without getting in the way. Don't reposition things lightly - it's annoying to develop muscle-memory only to have the UI change some months later.
• CLIs are different, but if there is some init or login action I need to perform after a fresh install, warn me when I first run a command. The best CLIs will also inherit my shell colors.

A bad first run experience is likely to be indicative of the overall quality of the application. This is often the benefit of using libraries that do a lot of the work for the developer, especially when it comes to newer CLIs, but there are so many alternative options for most developer tools that age is no longer an excuse.