Designing a Mobile App for Maximum Growth

Sure, but I'd still argue that 95% of the time you're still negotiating the degree of failure.

Honestly, the times I've been able to exert enough force on a project, we have always come out with a better, more refined, and clearer design that required no tutorials whatsoever.

5% of the time, user confusion comes from the fact that you're doing something truly new and groundbreaking and that the user will simply have to learn it somehow.

95% of the time, your design simply isn't good enough and you haven't iterated enough on it, or you have a tolerance for convention-breaking that is poorly-justified in the context of your app.

Mobile devs (me sometimes, too) have an annoying tendency to think they are in the 5% category all the time. My challenge to people is to accept that almost all of the time when users can't figure out your app, the solution isn't user education, it's to un-fuck your design.

[edit] I just read your post more carefully...

> "It's great to design the experience at the outset to not need the tutorial screens. And then test into the possibility of including them anyways."

Wait what. That seems entirely unreasonable. If you've designed an experience that is intuitive and requires no tutorial screens, you want to include them anyways?

Am I reading your post wrong?

Tutorial screens and mechanisms are never a good thing. They can (rarely) be justified as a necessary evil, but at no point are they actually good, and at no point do they make your UX better. A well-designed tutorial is simply less awful than a poorly-designed tutorial. Both scenarios are categorically worse than simply not needing a tutorial.

Note that I'm drawing a distinction between onboarding and tutorials - one introduces the user to the product, the other introduces the user to the UI. Onboarding (like, say, an online dating app helping you import your first photo so your account is even marginally useful) is entirely legit, tutorials aren't. The screenshots provided in the original article are tutorials, not onboarding.

What's your definition of a "good thing" or "actually good"? If it's quantifiable as higher engagement and retention then these mechanisms are far from "never a good thing". They're a good thing quite often - when done correctly. This is why you see them in many products that have growth teams dedicated to the task.

Agreed that the screenshots do not do a great implementation justice.

Note that when I'm talking about onboarding, I am talking about combining introducing users to the UI with introducing them to the product.

Sure introducing the user to UI by itself is not great.

> "If you've designed an experience that is intuitive and requires no tutorial screens, you want to include them anyways? Am I reading your post wrong?"

Slightly yeah. It should be read as: "If you've designed an experience that is intuitive and requires no tutorial screens, you want to test them anyways."

Because we've seen their inclusion improve engagement and conversion even in experiences that are intuitive. Sometimes that's not the case, but the possibility is strong enough to justify testing them out.

The hamburger button is common, but it is not any clearer to the user today than it was when it first started popping up - and for good reason, because the hamburger button was never a well-defined piece of UI.

The hamburger button is literally the Everything Button(tm), and as such it's unlearnable, because "Everything" is different for every single app, and "Everything" is far too broad for users to develop expectations around.

So maybe we're arguing over semantics about what's a convention and what isn't - the hamburger button is an incredibly common UI element, but the users never learned any conventions around its use, because there were never any.

And this isn't just idle complaining - in every single app I've ever done, and in all the apps where I've had visibility into user patterns, and with all of the mobile devs I've been able to ask this question to, the answer has been unanimous - when subject to quantitative testing, the hamburger button falls apart.

Screens placed in hamburger button menus receive way fewer clickthroughs (1-2 orders of magnitude) than screens that are clearly labeled by buttons or tab bars. When placed in situations where the user is unsure how to proceed, the hamburger button is literally the least touched UI - users will touch just about anything before they touch the hamburger button.

Putting features behind hamburger menus is quantitively a death sentence. It's a great way to guarantee it gets minimal (if any) exposure to users at all.

So I guess I'm being a bit roundabout - but the distinction I'm trying to make is that while developers seem to think the hamburger button is well-established convention, this does not bear out when observing user behavior. "Users know what the hamburger button does" is a faulty assumption.