
Designing a Mobile App for Maximum Growth - sethbannon
http://firstround.com/review/this-is-how-you-design-your-app-for-maximum-growth/
======
potatolicious
There seems to be something being missed in this thread with the back and
forth of effective tutorial screens:

What if we created UX that didn't require explicit hand-holding?

I'm sounding snarky I'm sure, and maybe that's because this is kind of a
snarky comment, but as someone who makes mobile apps for a living it's a
position that is surprisingly infrequently considered.

Yes, I know it will look really cool, but do you _really_ need to break
platform conventions (that users have already spent _a lot_ of time learning)
just for your one thing?

Maybe instead of pointing an arrow at a hamburger button and telling the user
what's under that button, we should consider something less _insanely vague
and useless as the hamburger button_?

Having built a pretty large number of apps so far, my position right now is:
if you find yourself building a tutorial screen/mechanism, _you have already
failed_ , and the only good you're doing for your UX now is controlling the
degree of failure between "mild" and "utter".

My experience with tutorial screens - not just on the implementation and UX
side, but also where they seem to come up during the product development
process - suggests that they are at least a bit cargo-cult-y. People suggest
them because other apps have them and it's at least a superficially sensible
thing to do.

A lot of projects start with the fundamental premise that tutorial screens
will be necessary, and when these projects inevitably run into
conversion/completion barriers because of the tutorial screens, attempts to
mitigate rarely involve _completely removing_ the screens. It's as if the
presence of tutorial screens is fundamentally non-negotiable.

~~~
kamobit
Completely agree here. I think the main theme of that section being "Don't
over-educate users" if you can reach for high engagement and conversion rate
without overlays, arrows, etc. then that's the way to go.

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.

One "in-between" possibility would be to have something similar to Slack's old
onboarding experience where you'd see some elements that gently pulsed
prompting the more curious users to click on them and learn more. And everyone
else to safely ignore them and move on.

Interestingly Slack has moved on to more explicit explanations during their
most recent onboarding iteration. But I am sure that they'll also try
something without any tool-tips at all.

The larger point is that many apps have sliding screens that force users to
read in order to learn about their app. And that users did not install and
open the app to _read about_ it. They're there to use it.

We've seen massive increases in conversion rate and engagement by replacing
these screens with "learning by doing" interactions.

If that "learning by doing" step can be accomplished without tutorials then
even better!

~~~
potatolicious
> _" If that "learning by doing" step can be accomplished without tutorials
> then even better!"_

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.

~~~
kamobit
> "Tutorial screens and mechanisms are never a good thing."

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.

------
dv_says
Not a fan of screen overlay tooltips as in [1]. My first instinct as a user is
to get them out of my way, and I do that every time, feeling guilty. And
adding a "next" button and going through tooltips one-by-one doesn't make this
any better, just more annoying.

Actual games (such as GTA or Cut the Rope) do a great job with onboarding, and
apps tend to take the simpler show-everything-in-the-beginning way.

Two alternatives I've tried as an indie dev:

\- Gamification, where you ask the user to perform one task, such as "drag X
to Y." Only after they performed the action move on to the next prompt, and
perhaps not even immediately.

\- Utilizing badge counts or "bouncing" animations to indicate some action
that needs to be performed. The benefit is that the user can try it on their
own time, and you're not rushing them. The downside, though, is that some
users may never actually click.

On the flip side, these approaches can add complexity in both code and how you
structure your UI.

[1] [http://s3.amazonaws.com/marquee-test-
akiaisur2rgicbmpehea/R9...](http://s3.amazonaws.com/marquee-test-
akiaisur2rgicbmpehea/R9Z7wKsTTDepaxHpZ8NU_Usability_Post.jpg)

~~~
nostrademons
I like the tooltips better than either of the approaches you've suggested. If
I'm confused, I glance at them and then am less confused. If I'm not confused,
I just dismiss them, not feeling guilty.

I hate "help" mechanisms that keep popping up in normal operation, because
usually I know exactly what I'm doing in normal operation.

~~~
dv_says
You're on point, these help mechanisms should be rare and few, or they would
be a nuisance as well.

The problem with forced screen of tooltips in the very beginning is that you
haven't had a chance to explore the app yet, and so it's hard to mentally
assign importance to them. And later, they're gone.

~~~
wlesieutre
This is my issue with them. Maybe I _do_ need a tooltip to figure some feature
out. But I certainly don't know which one I need yet.

If you bombard me with "Hit the + button to make a new document!" on first
launch, of course I'm going to dismiss the tips. It's 2015. Figured that one
out on my own.

Better to design an app where functions aren't hidden in secret menus and I
can explore without accidentally screwing things up. Is that too much to ask?

------
davidamarquis
Assuming that users who installed the app already understood the need to
provide their location data. This allowed them to axe out the long-winded
welcome flow and make the permissions request the second screen. The text was
changed to say that users needed to “Enable Location Permissions”

Just so wrong.

~~~
akramhussein
Yup - I wonder if the article misrepresented the actual change because it
seems a bit odd?

This article has a lot of good points but some are really debatable. Not long
ago, Hopper (app for flight price monitoring) published their experience in
re-doing their onboarding [0]. Some take aways from that go against what this
one says.

Ultimately you have to see what works for you and what doesn't. Copy & paste
(just like the Social links paragraph funnily) will never just work without
some thought.

[0] [https://medium.com/@hopper_travel/the-notification-
problem-5...](https://medium.com/@hopper_travel/the-notification-
problem-50267cbabad2#.9anehkja7)

------
physcab
It should be no surprise that decreasing the tutorial from 6 pages to 2 will
increase number of users "registered" from 40% to 80% (or more). In my
experience, tutorial dropoff follows a power law, that is, every new hurdle
you place before the user can use your app gives them one more chance to bail.
You can try all the fancy design tricks you want, but the end result is still
the same...you're creating friction points.

In reality there's a delicate balance. Train users to use your app early and
take the hit in registrations. You should end up with more engaged users who
retain better. Or let everyone in and teach them as they use your app and risk
retaining them because they don't understand what the hell they're doing.
There is no silver bullet.

------
fleaflicker
_When you look at user tests, no one pauses to read this text. And the very
few who do immediately forget what they read..._

Even though some of the technologies discussed are hillariously obsolete,
nearly everything published on joelonsoftware.com 10+ years ago remains
surprisingly relevant:

 _You could explain things in the manual, but everybody knows that users don
't read manuals, and they probably shouldn't have to._
[http://www.joelonsoftware.com/uibook/chapters/fog0000000058....](http://www.joelonsoftware.com/uibook/chapters/fog0000000058.html)

~~~
firasd
I wrote a response to your comment: [https://medium.com/@firasd/things-i-read-
on-joel-on-software...](https://medium.com/@firasd/things-i-read-on-joel-on-
software-that-came-true-cd201c03cf58)

------
ceekay
Completely agree with this: if the user doesn't see value within 5 seconds
(and is wow'ed by it), game over... wrote a piece on it: "Onboarding is
Everything" [https://blog.orangecaffeine.com/onboarding-is-
everything-327...](https://blog.orangecaffeine.com/onboarding-is-
everything-327dddb8b1d0#.3iq1vwhvr)

------
dlu
I love this article and it is a pretty great handbook on a variety of tactics
you normally don't get much depth about. But I wish the whole thing was
prefaced with, this mostly matters after you've found an audience. (Or
product/market fit if you're pmarca)

------
kamobit
Hi all, I'm the person cited the article. (Kamo from Primer)

Happy to answer any questions or elaborate on anything in there.

------
kookiekrak
awesome article. really nice to see a guide on how to build effective
onboarding from an experts view

