Dear founder,
I recently came across a tweet by Nikita Bier about onboarding in software products that made me reflect on my own choices for the first touches that my customers have with my product.
It also got me thinking about the general expectations we have for software products we use for all kinds of purposes.
🎧 Listen to this on my podcast.
In his tweet, Nikita stated:
If at any point you think it’s a good idea to build a user tour in your app, stop and go for a walk. The idea is that a good application is self-explanatory. Until you are at that point, you need to rework your navigation, your hierarchy, empty states, and your copywriting.
He went on to say:
You have to assume that the average mobile app user has the intelligence of a lizard. Make it so abundantly obvious how the app works, even if it comes at the sacrifice of power users. After all, you need users before you can have power users.
This tweet garnered a lot of attention, with many experienced people both agreeing and disagreeing. I found this to be a fascinating conversation, and I want to share my personal perspective on it.
As a SaaS owner and developer, I’ve been trying to balance the need to make things easy with the need to make things good. While a user tour might be symptomatic of a lack of easy-to-use interfaces, it’s also a necessity to introduce people to a product they don’t yet know.
So, let’s look at user onboarding through guided steps and see if it’s a good idea, who it’s good for, and if it makes sense for indie hackers and solopreneurs to use it — as either a crutch or a meaningful tool to introduce prospects to their product.
First off, what is a user tour? You’ve probably clicked through several of them over the last couple of months when starting to use new tools. It’s a step-by-step onboarding process that shows you, “Here’s a button that does this,” then blurs out the screen and highlights the button, maybe putting some text next to it. You click “Next,” and it shows you another button or feature. It’s pretty much like a guided tour or tutorial within the application itself.
The question is: what’s the purpose of a user tour, and why is it needed? For a user tour, it tends to be this: a person was promised something from the product’s landing pages. They signed up because they thought this tool would help them achieve their goal. The tour then takes their hand and guides them from the entry point to receiving value for the first time in the product. It’s an idea to get people to the “aha moment,” the value moment.
Paul Graham explained this in a comment to Nikita’s tweet. He mentioned a user tour that caused users to create a small, working online store in his product. This changed the question from “Would you like to use our software to build a store?” to “Would you like to keep the store you just made?” For him, this converted way better because people saw the value activation right there.
I’m currently doing something similar with my product, Podscan. My designer, Nick, and I worked on an onboarding wizard for people coming into the product for the first time. It gets them from “Hey, you just signed up” to “Why are you here? What would you like to do?” We offer options like setting up alerts for future brand mentions or searching our database for things already said. We then take them through easy steps to create these alerts in the background, so they already have alerts the moment they first hit the actual interface of the product.
I think there’s very little that can be done to reliably communicate all of this in the default state of a dashboard. People come to your product hoping for something, and they will very likely be completely disappointed that what they thought it would be is not exactly what you implemented. The user tour is meant to massage the specificity of your product into the experience, guiding people from what they think it should be to what you actually made.
And what matters a lot here is who this is made for.
Nikita’s argument that “if you need a manual to use your product, your product is not designed well enough” is absolutely true for consumer products with a simple purpose. But do you think a nuclear power plant is supposed to work intuitively? There’s some complexity to systems like that which is required by their technical capabilities and the risks of making mistakes using them. The same goes for hospitals — many of the processes in a healthcare institution aren’t too intuitive because that’s not what matters. They’re supposed to be effective, safe, hygienic, and life-saving.
That said, there’s still a place for usability in complex systems. I remember reading about improving the labeling of medication in hospitals, which significantly improved safety by making it more intuitive for nurses to pick the right medication for the right patient. So there is a place in even complex systems for usability, but usability is not the main theme.
I think this has to do a lot with the longevity expectations of your product.
Consumer apps often are distractions, quickly discarded entertainment between other things.
But when it comes to B2B products, particularly those solving specific problems for specific people, we’re talking about expert systems. These are expertly crafted systems for experts to be used in a specific context of work.
These systems get complicated over time because they get more specific and aligned with the expressed requirements of the experts they’re supposed to serve.
These systems grow into a similar complexity as the field they are solving a problem in.
The balance here is to think about which features should be shown and which should be hidden away for special needs. You can’t account for 100% of the cases and completely avoid a user tour or onboarding process if you have an expert tool offering an expert service.
Take, for example, a translation management software company I once consulted for. This software, developed over a decade, integrated countless features to support the intricate business processes of translation-based companies. From operational tasks to financial projections, the system was necessarily complex. While we continually strived to improve its usability, completely eliminating the need for user onboarding would have been impossible without sacrificing crucial functionality.
Why?
Because existing, often decade-old, users had developed a mental map of the software by growing with it. They had mapped their own processes onto the hierarchy and topology of this complex beast of a product.
And we really couldn’t afford to confuse the users who were paying the bills. We iterated, sure, but a complete redesign to “make things better” would have made things much worse.
The reality of business is that we can’t afford to “just make it simple.”
I disagree with Nikita’s statement that you have to “make it abundantly obvious to all users how the app works and sacrifice your power users now so you can find power users later.” I don’t think that’s how it works. The people who really need your product are not necessarily the same group of people who might use your product casually. Power users have very specific needs that are not the same as everybody else’s.
By simplifying and idiot-proofing your expert tool, you’re preventing your power users from even envisioning what it could do.
Because that’s where “affordances” come in.
These design elements intuitively communicate to users how to interact with an object, making it easier and more intuitive to use without explicit instructions.
Imagine a door. A vertical handle suggests pulling. A horizontal bar suggests pushing.
And sometimes, to be abundantly clear, you put a “push” or a “pull” sign on your door.
The handles, and even the signs, are affordances to show what users can do with this object.
Software is massively more complex than a door. In your dashboard, you have dozens of things a user could do — and, most importantly, don’t yet know if or how it can be accomplished when they first log into your product.
Do you add 15 different door handles? Certainly not. You try to find the most important ones, establish hierarchy, and communicate what may happen with empty states, just as Nikita suggests. But you also have to show to your users where all those other features are.
That’s the purpose of the tour.
And that’s in the best case.
If you’re a solo software developer trying to build a product or prototype, you probably won’t have found the perfect design from day one. Design takes time to establish because it follows the path that people take through your application. With a user tour, you’re trying to intuit which path the user will take and show them that safe path. You’ll get feedback on this, don’t worry. The tour, measured and analyzed, will impact your future design decisions.
But completely omitting it is a mistake.
Ironically, Nikita argues against his own point when he says that “the average mobile user has the intelligence of a lizard.” If that’s the case, wouldn’t it make more sense to provide a guide rail to help these users find sure footing from the first time they use the product?
I think a user tour is fine.
Especially if your business is a B2B product or a product with relatively high complexity. Putting a little guide tour in there is a good idea. It’s about finding the right balance between simplicity and functionality, and sometimes, that means holding your users’ hands a little bit as they get to know your product.
I'll share a few updates about my SaaS on the pod, and if you want to track your brand mentions on podcasts, please check out podscan.fm — and tell your friends!
Thank you for reading this week’s essay edition of The Bootstrapped Founder. Did you enjoy it? If so, please spread the word and share this issue on Twitter.
If you want to reach tens of thousands of creators, makers, and dreamers, you can apply to sponsor an episode of this newsletter. Or just reply to this email!