The Bootstrapped Founder

The thing is people come to your product hoping for something. They have a vision of what it should be. Hey, I'm Arvid and you're listening to the Bootstrap founder. I recently came across a tweet by Nikita Bir about onboarding software products that made me reflect on my own choices for these first touches that my customers have with my own product. It also got me thinking about the general expectations that we have for software products that we use for all kinds of purposes, for all kinds of goals.

And in his tweet, Nikita stated this, if at any point you think it's a good idea to build a user tour into your app, stop and go for a walk. The idea here is that a good application is self explanatory. Until you are at that point, he said, you need to rework your navigation, your hierarchy, your layout, empty states, and your copywriting. And you have to assume that the average mobile 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. So that's most of the tweet. And this tweet garnered a lot of attention with many experienced people both agreeing and vehemently disagreeing with Nikita. And I found this to be a fascinating conversation, and I wanna share my personal perspective on it. As a SaaS owner and a developer, I've always been trying to balance this need to make things easy with the need to make things good and usable.

And while a user tour might be symptomatic of a lack of easy to use interfaces, it's also a necessity often to introduce people to a product that they don't yet know. So let's look at user onboarding through guided steps and see if it's a good idea or not. Who is it good for and if it makes sense for indie hackers and solopreneurs to use it. Maybe either as a crutch or as a meaningful tool to introduce prospects to a product. First off, what is a user tour?

Well, you've probably clicked through several of them over the last couple of months when you started using new tools, new products, right? It's this step by step onboarding process that shows you here is a button that does this and then blurs out the screen and then highlights the button and maybe there's a little piece of text next to it and you click next and it shows you another button or if you click on the button, it goes to that. It's pretty much a guided tour or a tutorial within the application itself. The question is, what's the purpose of this 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. It excited them so much. They thought this is for me, this is gonna solve my problem that they signed up because they thought this tool would help them achieve this goal. A goal that you may or may not understand, right, as a software as a service operator, you think you know the goals of your customers and you hope that this is what they have, but you don't really know exactly what it is. The tour then takes their hand and guides them from this entry point where you don't know anything about them and they don't know anything about you to the point where they can receive value in this product for the first time and hopefully align that with their goal.

It's an idea to get people to the moment, to this value moment. Paul Graham actually explained this in a comment to Nikita's tweet. He mentioned a user tour that he had built in the nineties for his product that caused users to not just see a couple of things, but to actually create a small working online store in this product. And for him or, I guess, for his users, 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 built? And I think that converted way better, at least that's what Paul says, because people saw the value activation right there.

They saw the moment. They experienced it, and they had something already. They bought in. They put investment into the product just through the tour. Now you could argue that this is just the product and not a tour, but I think it's very reductive to think that a tour is just like showing a couple buttons.

A tour can be way more integrated into the product, and that's something that I'm currently doing in a very similar way with my product, PodScan. My designer, Nick, and I, we worked on this onboarding wizard for people coming into the product for the very first time. It gets them from, hey, you just signed up to, well, why are you here? What would you like to do? And how can we help you do it?

We kinda ask them what their main purpose is and then we offer them options depending on this for setting up alerts, for future brand mentions, or for starting to search our database for things that had already been said. And then we take them when they choose alerts, for example, we take them through these easy steps to create a couple alerts in the background, so they already have something set up the moment they first hit the actual interface of the product when the wizard closes. And this has been really positive, like people have been using it a lot, and they have created way more alerts for things that we put in there and that they thought of than before. It's been a better activation of the customer. And I think there's very little that can be done in terms of design to reliably communicate all of this in the default state of a dashboard.

Like you would have to really overload it and that would make it super complicated. The thing is people come to your product hoping for something. They have a vision of what it should be and they will very likely be somewhat if not completely disappointed that what they thought it would be is not exactly what you implemented. And the user tour is meant to massage your specificity, the specificity of your product into this initial experience, Guiding people from what they think it should be to what you actually made and still aligned with their interests and their goals. What matters a lot here is who they are, who you made this for.

I think Nikita's argument that if you need a manual to use your product, your product is not designed well enough, that is absolutely true for consumer products, for products with a simple purpose. If you get a vacuum, you want the button on the vacuum to start the vacuum, and then it starts vacuuming, and then you hit the button again, and then it turns off. It's a very simple clear purpose. But do you think a nuclear power plant is supposed to work this intuitively? I don't think so.

There's some complexity there's a lot of complexity to systems like that, which is required by the technical capabilities or the risks of making mistakes using them. You need a complex interface for a complex system like this. I think the same goes for, let's let's say hospitals. Many of the processes in the healthcare institution aren't too intuitive because that's not what matters. These processes are supposed to be effective and safe and hygienic and lifesaving.

I used to work for a hospital, for a couple of months in my earlier years, and I didn't understand why things had to be so complicated. But over time, I heard stories about what happened that made these processes have these checks and balances and these complicated documentation features and all of this. There is more than easy to use in hospitals. But that said, there is also still a place for usability in these complex systems Because I remember reading about improving or somebody improving the labeling of medication in hospitals and they did some field testing with this. Like, they they changed the way medication was assigned to particular patients, and this change significantly improved safety by making it more intuitive for nurses to pick the right medication for the right patients.

Because usually, it's quite stressful to deal with all these patients particularly if you have a lot in your wing or something, and then you might give the wrong medication to the wrong person and that can be super dangerous. So there is a place in even complex systems like this for usability, but usability tends not to be the main theme in these systems. And I think this has a lot to do with the longevity expectations of the product or the system itself. Because in a way hospitals and, nuclear power plants, all of this is kind of b to b, right, there's a lot of, complexity and expertise involved. And consumer apps, which I think is what Nikita was talking about in the tweet, well, they are different.

They perceive differently, they use differently. They often are distractions, Quickly used, but also quickly discarded and just entertainment between other things. So, yeah, of course, you want people to be able to use it quickly if you look at mobile games. They have to be super intuitive because otherwise people switch over to the next mobile game. They're quite fungible in that sense.

Right? They can be easily exchanged for something like it. But when it comes to b to b products, particularly those solving specific problems for specific people, we're talking about almost non fungible expert systems, systems that cannot be easily funged and cannot be easily exchanged for another system. These are expertly crafted things, crafted systems to be used by experts, to be used in a specific context of work. And these systems get complicated over time because they get more specific, and they align more with the expressed requirements of the experts that they are serving.

Might these systems grow into similar complexity as the fields that they are solving a problem in. Like the hospital world, the medical system is extremely complicated because there are so many things that can be done, so many technologies, so many just approaches or nuclear fusion or fission or whatever thing you were kind of looking into. Right? These complicated physical systems require equally complicated, like, you would even call it like a mirror system of software that maps these processes from thoughts, from just real world processes into digital processes as well. And the balance here is to think about which features in your product should be shown and which should be hidden away for special needs.

I don't think you can account for a 100% of the use cases of your customers and then completely avoid a user tour or an onboarding process, particularly if you have an expert tool offering an expert service in a specific industry. I have an example here. I consulted for a translation management company many years ago for quite a while, so I followed them along several years of of the journey. And the software that they made that was developed over over a decade integrated countless features and integrations to support this intricate business process setup of translation based companies. Let's, for example, maybe to make it clear who they were serving, let's take a company like Siemens that has so many different products and they they have to make manuals for these products.

So they find systems like the company that I was serving to get freelancers onboarded to translate a manual from, I don't know, German to Japanese, right, and still make it technically accurate, And then they had to pay them, and then they had to schedule them, and then they had to have financial projections and reporting and operations and all of this. The system was necessarily complex because it was mapping onto a complex business process underneath. And while we, as a team building the software, continually strive to improve its usability, completely eliminating the need for user onboarding, that would have been impossible without sacrificing something crucial. What and why? Well, often decade old users had then they were already paying for this product.

They had developed a mental map of the software by growing with it. But they had suggested the features that went into it that they needed for their business to work. They had mapped their own internal very critical business processes onto the hierarchy and topology of this complex beast of a software product. And we really couldn't afford to confuse them, because they were paying the bills. We iterated, sure.

But a complete redesign to just make things better, whatever that might mean, well that would have made things much worse. The reality of business is that we can't afford to just make it simple. And that's why I disagree with Nikita's statement that you have to make it abundantly obvious to all users how the app works and then sacrifice your power users now so that you can find power users later, I don't think that's how it works. The people who really need your product, well, they're not And by simplifying and idiot proofing your expert tool, you're And by simplifying and idiot proofing your expert tool, you're preventing your power users from even envisioning what they could do because that's where affordances come in. These design elements and just to explain what it is, they intuitively hopefully communicate to users how to interact with an object, making it easier to use or more intuitive to use without explicit instructions.

A vertical handle on a door, that suggests pulling. A horizontal bar suggests pushing. And sometimes, to be abundantly clear, you put a push or a pull sign on your door as well. That's what affordances are. Right?

Showing people how a thing can be used. But software is massively more complex than a door. In your dashboard, you have dozens of things when that people can do when they log in. And most importantly, they don't yet know if or how it can be accomplished when they first log in to your product. Do you add 15 different door handles to your product there?

Certainly not. You try to find the most important ones. You establish hierarchy and communicate what may happen with empty states or with little hints just as Nikita suggests. But you also have to show your users where all those other features are. And that's the purpose of the tour.

That's really just happening in the best case even. If you're a solo software developer, you're trying to build a product or a prototype, you probably won't have found the perfect design from day 1 just yet. Design takes time to establish because it follows the path that people take through your application. Design follows the function that people needed to, right, needed to provide. And with a user tour, you're kinda trying to intuit which path the users might take and show them the safe path there to get to that result.

And don't worry, you'll get feedback on this for sure. People will talk to you about the tour if they find it confusing, if they find it helpful, as long as they have a channel for people to talk to once they use your product. And the tour, when measured and analyzed, will then impact your future design decisions because you will see do people even complete this step or are they already done here? Is everybody stopping the tour here because they thought something else would happen? You have you you can communicate with people.

It's really useful. But completely omitting the tour just to make things simple, that's really, I think, a mistake, a big mistake too. And ironically, Nikita argues against his own point here when he says that the average mobile user has the intelligence of a lizard. I think that's very insulting because if that's the average then 50% of users are even dumber than that supposedly, but even if it's the case, wouldn't it make more sense to provide a guide rail to help these people to find their sure footing from the very first time they use your product, why would you then hope to make it kinda simpler and hope that they get it intuitively when you can help them along the way. I don't really understand this.

So I think a user tour is fine, especially if your business is a b to b product or a product with relatively high complexity. Putting a little guide tour in there is a good idea. It will help more than it hinders. It's about finding the right balance between simplicity and functionality. And sometimes, that means holding the user's hands a little as they go and get to know your product.

Because that's what you want them to become. Users of your product. So help them along the way. And that's it for today. Thank you for listening to the Bootstrap founder.

You can find me on Twitter at avidkahl, a r v I d k a h l. And you find my books on my Twitter course there too. If you wanna support me in the show, please tell everyone you know about podscan dot f m and leave a rating and a review by going to rate this podcast dot com slash founder. It makes a massive difference if you show up there because then the podcast will show up in other people's feeds and any of this will really help the show. Thank you so much for listening.

Have a wonderful day and bye bye.