Again, if Pocket has 98% acceptance of the email permission screen, we can assume a similar screen will have similar success. We don’t need to rush people into registering for something they don’t understand. There may be benefits to introducing this before verification, and I agree, we should measure.
Chris asked me to absorb this article, and I have, which may be explaining my recent change in tune: http://andrewchen.co/the-next-feature-fallacy-the-fallacy-that-the-next-new-feature-will-suddenly-make-people-use-your-product/ <http://andrewchen.co/the-next-feature-fallacy-the-fallacy-that-the-next-new-feature-will-suddenly-make-people-use-your-product/> > … a product’s onboarding experience can be weak if there isn’t a strong > opinion on the right way to use (and setup) the product. In the early Twitter > days, you’d sign up and immediately be dropped onto a blank feed, and a text > box to type in your status. While this might let you explore the product and > do anything, ultimately this is a weaker design then asking you to follow a > bunch of accounts, which is the current design. Understanding that Twitter is > meant to be mostly used as a reader, potentially without tweeting much, is a > deep insight and a strong opinion that has paid dividends for the product. > As far as post-verification email, we could do: https://www.dropbox.com/s/dj8bkfk7855iafa/fxa-verified.png?dl=0 <https://www.dropbox.com/s/dj8bkfk7855iafa/fxa-verified.png?dl=0> Ryan Feeley UX, Cloud Services Mozilla UX IRC: rfeeley > On Jul 8, 2015, at 1:57 PM, John Gruen <[email protected]> wrote: > > I’m definitely in agreement that multi device signup is the right thing but > by lengthening the pre-verified flow by 400% we’re going to heavily increase > exit/bounce and lose the relationship altogether. It feels like we’d be > cutting off our nose to spite our collective faces. Without an account, we > lose the email address and without the email address we lose the ability to > follow up with users as new clients come online. > > Here’s the simplest thing to do in this regard: > > - keep the sign in form the way it is > - after verification send a second email advertising all the clients and > enticing people to go download them > > > > > >> On Jul 8, 2015, at 1:48 PM, Shane Tomlinson <[email protected] >> <mailto:[email protected]>> wrote: >> >> Ryan and John, >> Can you coordinate this with the Growth team? They have similar goals to >> drive multi-device and are proposing other solutions. >> >> FWIW, even asking for the "Make Firefox Yours" info pre-verification makes >> me somewhat nervous about how that'll affect signup. It's testable though. >> >> Shane >> >> >> On Wed, Jul 8, 2015 at 6:30 PM, Ryan Feeley <[email protected] >> <mailto:[email protected]>> wrote: >> I’ve added some comments to the slide you should be able to see in link >> below (green post-its). >> >> I’m more interested in engagement than adoption. I think we need to consider >> single-device syncers as a failure of UX because sync is not a good back up >> solution (until we make it one, which I support). >> >> In regards to testing, we need to test the right thing, which will be hard: >> multiple devices added. >> >> By letting users know about other platforms up front, we will hopefully >> drive other platform downloads, leading to syncing, but have fewer >> single-device syncers. If successful, this means fewer accounts overall, but >> of a higher quality. >> >> Ryan Feeley >> UX, Cloud Services >> Mozilla UX >> IRC: rfeeley >> >>> On Jul 8, 2015, at 1:22 PM, Edwin Wong <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> I'd like to see an A/B test where we put 'make fx yours' screen >>> before/after verified email screen. Our users will tell us if increased >>> friction vs early customization gets users through the flow. >>> >>> -e >>> >>> On Wed, Jul 8, 2015 at 8:33 AM, John Gruen <[email protected] >>> <mailto:[email protected]>> wrote: >>> Agree with Mark and Ryan K. on the problem of overloading the funnel before >>> registration. It seems like there are two competing interests coming into >>> play here: increasing signups vs increasing engagement. Is there a middle >>> path where we can do both? >>> >>> I’ve reworked the flow to hopefully address both of these concerns: >>> >>> https://www.lucidchart.com/documents/view/92d0ec74-a2af-40b8-b714-6db99149e39c/1 >>> >>> <https://www.lucidchart.com/documents/view/92d0ec74-a2af-40b8-b714-6db99149e39c/1> >>> >>> Thoughts? >>> >>> JG >>> >>> >>> > On Jul 7, 2015, at 6:25 PM, Ryan Kelly <[email protected] >>> > <mailto:[email protected]>> wrote: >>> > >>> > On 8 July 2015 at 08:12, Ryan Feeley <[email protected] >>> > <mailto:[email protected]>> wrote: >>> >> >>> >> In the spirit of increasing engagement, I’m proposing we add some steps >>> >> to registration to help users understand what sync is, and what devices >>> >> support it. >>> >> >>> >> https://www.lucidchart.com/documents/view/92d0ec74-a2af-40b8-b714-6db99149e39c >>> >> >>> >> <https://www.lucidchart.com/documents/view/92d0ec74-a2af-40b8-b714-6db99149e39c> >>> >> >>> > >>> > I like the additional customization and linkage, but I'm not sure that >>> > the registration flow is the right place for them. That's a lot of >>> > screens for the user to click through before completing their setup, >>> > which means a lot of opportunities for them to decide they can't be >>> > bothered. >>> > >>> > In particular, I think the download links would be more valuable if >>> > surfaced after the first device is setup, rather than being a >>> > potential roadblock to setting it up. (Like "ok, you're all set, now >>> > sync with these other devices"). >>> > >>> > Ryan >>> > _______________________________________________ >>> > Dev-fxacct mailing list >>> > [email protected] <mailto:[email protected]> >>> > https://mail.mozilla.org/listinfo/dev-fxacct >>> > <https://mail.mozilla.org/listinfo/dev-fxacct> >>> >>> _______________________________________________ >>> Dev-fxacct mailing list >>> [email protected] <mailto:[email protected]> >>> https://mail.mozilla.org/listinfo/dev-fxacct >>> <https://mail.mozilla.org/listinfo/dev-fxacct> >>> >> >> >> _______________________________________________ >> Dev-fxacct mailing list >> [email protected] <mailto:[email protected]> >> https://mail.mozilla.org/listinfo/dev-fxacct >> <https://mail.mozilla.org/listinfo/dev-fxacct> >> >> >
_______________________________________________ Dev-fxacct mailing list [email protected] https://mail.mozilla.org/listinfo/dev-fxacct
