5 ms·

Designing a Mobile App for Maximum Growth

100 points by sethbannon 11y ago

fear007 11y ago
+1
davidamarquis 11y ago
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 11y ago
  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-50267cbabad2#.9anehkja7 https://medium.com/@hopper_travel/the-notification-problem-5...
kookiekrak 11y ago
awesome article. really nice to see a guide on how to build effective onboarding from an experts view
dv_says 11y ago
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/R9Z7wKsTTDepaxHpZ8NU_Usability_Post.jpg http://s3.amazonaws.com/marquee-test-akiaisur2rgicbmpehea/R9...
- nostrademons 11y ago
  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 11y ago
    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.
    - nostrademons 11y ago
      Offer a "Help" action that brings them back for whatever screen you're currently on.
    - wlesieutre 11y ago
      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?
fleaflicker 11y ago
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.html http://www.joelonsoftware.com/uibook/chapters/fog0000000058....
- firasd 11y ago
  I wrote a response to your comment: https://medium.com/@firasd/things-i-read-on-joel-on-software-that-came-true-cd201c03cf58 https://medium.com/@firasd/things-i-read-on-joel-on-software...
physcab 11y ago
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.
potatolicious 11y ago
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.
- lotyrin 11y ago
  As much as planning for failure is dumber than regular planning, sometimes failure really is inevitable and you have no choice but to accept and mitigate it.
- gdubs 11y ago
  http://www.asktog.com/papers/raskinintuit.html http://www.asktog.com/papers/raskinintuit.html ^ I really like Raskin's piece on intuitive UI. By all means we should leverage the conventions that users have worked so hard to learn, but sometimes 'intuitive' isn't going to provide the best long-term experience. His quote about the mouse, which we today assume needs no introduction, is illuminating: "My subject was an intelligent, computer-literate, university-trained teacher visiting from Finland who had not seen a mouse or any advertising or literature about it. With the program running, I pointed to the mouse, said it was "a mouse", and that one used it to operate the program. Her first act was to lift the mouse and move it about in the air. She discovered the ball on the bottom, held the mouse upside down, and proceeded to turn the ball. However, in this position the ball is not riding on the position pick-offs and it does nothing. After shaking it, and making a number of other attempts at finding a way to use it, she gave up and asked me how it worked. She had never seen anything where you moved the whole object rather than some part of it (like the joysticks she had previously used with computers): it was not intuitive. She also did not intuit that the large raised area on top was a button."
deleted 11y ago
[deleted]
kamobit 11y ago
Hi all, I'm the person cited the article. (Kamo from Primer) Happy to answer any questions or elaborate on anything in there.
ceekay 11y ago
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-327dddb8b1d0#.3iq1vwhvr https://blog.orangecaffeine.com/onboarding-is-everything-327...
dlu 11y ago
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)

100 points by sethbannon 11y ago

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 11y ago
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-50267cbabad2#.9anehkja7 https://medium.com/@hopper_travel/the-notification-problem-5...

kookiekrak 11y ago

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

dv_says 11y ago

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/R9Z7wKsTTDepaxHpZ8NU_Usability_Post.jpg http://s3.amazonaws.com/marquee-test-akiaisur2rgicbmpehea/R9...

nostrademons 11y ago
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 11y ago
  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.
  - nostrademons 11y ago
    Offer a "Help" action that brings them back for whatever screen you're currently on.
  - wlesieutre 11y ago
    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?

fleaflicker 11y ago

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.html http://www.joelonsoftware.com/uibook/chapters/fog0000000058....

firasd 11y ago
I wrote a response to your comment: https://medium.com/@firasd/things-i-read-on-joel-on-software-that-came-true-cd201c03cf58 https://medium.com/@firasd/things-i-read-on-joel-on-software...

physcab 11y ago

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.

potatolicious 11y ago

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.

lotyrin 11y ago
As much as planning for failure is dumber than regular planning, sometimes failure really is inevitable and you have no choice but to accept and mitigate it.
gdubs 11y ago
http://www.asktog.com/papers/raskinintuit.html http://www.asktog.com/papers/raskinintuit.html ^ I really like Raskin's piece on intuitive UI. By all means we should leverage the conventions that users have worked so hard to learn, but sometimes 'intuitive' isn't going to provide the best long-term experience. His quote about the mouse, which we today assume needs no introduction, is illuminating: "My subject was an intelligent, computer-literate, university-trained teacher visiting from Finland who had not seen a mouse or any advertising or literature about it. With the program running, I pointed to the mouse, said it was "a mouse", and that one used it to operate the program. Her first act was to lift the mouse and move it about in the air. She discovered the ball on the bottom, held the mouse upside down, and proceeded to turn the ball. However, in this position the ball is not riding on the position pick-offs and it does nothing. After shaking it, and making a number of other attempts at finding a way to use it, she gave up and asked me how it worked. She had never seen anything where you moved the whole object rather than some part of it (like the joysticks she had previously used with computers): it was not intuitive. She also did not intuit that the large raised area on top was a button."

deleted 11y ago

[deleted]

kamobit 11y ago

Hi all, I'm the person cited the article. (Kamo from Primer) Happy to answer any questions or elaborate on anything in there.

ceekay 11y ago

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-327dddb8b1d0#.3iq1vwhvr https://blog.orangecaffeine.com/onboarding-is-everything-327...

dlu 11y ago

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)