<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Ryan, <div class=""><br class=""></div><div class="">Changing the sub-header on the first run page goes a long way:</div><div class=""><br class=""></div><div class=""><a href="https://www.dropbox.com/s/0fflalrtnn85f5e/Screen%20Shot%202015-07-08%20at%202.37.06%20PM.png?dl=0" class="">https://www.dropbox.com/s/0fflalrtnn85f5e/Screen%20Shot%202015-07-08%20at%202.37.06%20PM.png?dl=0</a></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 8, 2015, at 2:26 PM, John Gruen <<a href="mailto:jgruen@mozilla.com" class="">jgruen@mozilla.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Here’s something we can definitely agree about. The demo first run page does very little to support the multi-device value prop [1]<div class=""><br class=""></div><div class="">A lot of our users have no idea that we make Android of iOS clients. For them, the term “everywhere you use firefox” currently just refers to a single machine. Why would I sync my stuff if “everywhere i use firefox” is just one place? Why would I get past this first screen if I have no idea that there is a client for my phone or tablet? Clarifying the message that Firefox not only syncs everywhere but <i class="">is available on every device</i> on this screen would go a long way toward expressing the value proposition.</div><div class=""><br class=""></div><div class="">Ryan, I realize i’m totally parachuting into this discussion, but let’s get together with engagement to work through all of this.</div><div class=""><br class=""></div><div class="">JG</div><div class=""><br class=""></div><div class="">[1] <a href="https://www.dropbox.com/s/3tc9d5ki0fvuytr/Screen%20Shot%202015-07-08%20at%202.20.20%20PM.png?dl=0" class="">https://www.dropbox.com/s/3tc9d5ki0fvuytr/Screen%20Shot%202015-07-08%20at%202.20.20%20PM.png?dl=0</a><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 8, 2015, at 2:11 PM, Ryan Feeley <<a href="mailto:rfeeley@mozilla.com" class="">rfeeley@mozilla.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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.</div><div class=""><br class=""></div><div class="">Chris asked me to absorb this article, and I have, which may be explaining my recent change in tune:</div><div class=""><a href="http://andrewchen.co/the-next-feature-fallacy-the-fallacy-that-the-next-new-feature-will-suddenly-make-people-use-your-product/" class="">http://andrewchen.co/the-next-feature-fallacy-the-fallacy-that-the-next-new-feature-will-suddenly-make-people-use-your-product/</a></div><div class=""><br class=""></div><div class=""><div class=""><br class="webkit-block-placeholder"></div><blockquote type="cite" class="">… 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.</blockquote><div class=""><br class="webkit-block-placeholder"></div><div class=""><br class=""></div></div><div class="">As far as post-verification email, we could do:</div><div class=""><a href="https://www.dropbox.com/s/dj8bkfk7855iafa/fxa-verified.png?dl=0" class="">https://www.dropbox.com/s/dj8bkfk7855iafa/fxa-verified.png?dl=0</a></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">
<div class=""><div style="orphans: 2; widows: 2;" class="">Ryan Feeley</div><div style="orphans: 2; widows: 2;" class="">UX, Cloud Services</div><div style="orphans: 2; widows: 2;" class="">Mozilla UX</div><div style="orphans: 2; widows: 2;" class="">IRC: rfeeley</div></div>
</div>
<br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 8, 2015, at 1:57 PM, John Gruen <<a href="mailto:jgruen@mozilla.com" class="">jgruen@mozilla.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">Here’s the simplest thing to do in this regard:</div><div class=""><br class=""></div><div class="">- keep the sign in form the way it is</div><div class="">- after verification send a second email advertising all the clients and enticing people to go download them</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div class=""><br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 8, 2015, at 1:48 PM, Shane Tomlinson <<a href="mailto:stomlinson@mozilla.com" class="">stomlinson@mozilla.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><div class="">Ryan and John,<br class=""></div>Can you coordinate this with the Growth team? They have similar goals to drive multi-device and are proposing other solutions.<br class=""><br class=""></div><div class="">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.<br class=""></div><div class=""><br class=""></div>Shane<br class=""><br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Jul 8, 2015 at 6:30 PM, Ryan Feeley <span dir="ltr" class=""><<a href="mailto:rfeeley@mozilla.com" target="_blank" class="">rfeeley@mozilla.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">I’ve added some comments to the slide you should be able to see in link below (green post-its).</div><div class=""><br class=""></div><div class="">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).</div><div class=""><br class=""></div><div class="">In regards to testing, we need to test the right thing, which will be hard: multiple devices added.</div><div class=""><br class=""></div><div class="">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.</div><span class=""><div class=""><br class=""></div><div class="">
<div class=""><div class="">Ryan Feeley</div><div class="">UX, Cloud Services</div><div class="">Mozilla UX</div><div class="">IRC: rfeeley</div></div>
</div>
<br class=""></span><div class=""><div class="h5"><div class=""><blockquote type="cite" class=""><div class="">On Jul 8, 2015, at 1:22 PM, Edwin Wong <<a href="mailto:edwong@mozilla.com" target="_blank" class="">edwong@mozilla.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class=""><div class="">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.<br class=""><br class=""></div>-e<br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Jul 8, 2015 at 8:33 AM, John Gruen <span dir="ltr" class=""><<a href="mailto:jgruen@mozilla.com" target="_blank" class="">jgruen@mozilla.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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?<br class="">
<br class="">
I’ve reworked the flow to hopefully address both of these concerns:<br class="">
<br class="">
<a href="https://www.lucidchart.com/documents/view/92d0ec74-a2af-40b8-b714-6db99149e39c/1" rel="noreferrer" target="_blank" class="">https://www.lucidchart.com/documents/view/92d0ec74-a2af-40b8-b714-6db99149e39c/1</a><br class="">
<br class="">
Thoughts?<br class="">
<span class=""><font color="#888888" class=""><br class="">
JG<br class="">
</font></span><div class=""><div class=""><br class="">
<br class="">
> On Jul 7, 2015, at 6:25 PM, Ryan Kelly <<a href="mailto:rkelly@mozilla.com" target="_blank" class="">rkelly@mozilla.com</a>> wrote:<br class="">
><br class="">
> On 8 July 2015 at 08:12, Ryan Feeley <<a href="mailto:rfeeley@mozilla.com" target="_blank" class="">rfeeley@mozilla.com</a>> wrote:<br class="">
>><br class="">
>> 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.<br class="">
>><br class="">
>> <a href="https://www.lucidchart.com/documents/view/92d0ec74-a2af-40b8-b714-6db99149e39c" rel="noreferrer" target="_blank" class="">https://www.lucidchart.com/documents/view/92d0ec74-a2af-40b8-b714-6db99149e39c</a><br class="">
>><br class="">
><br class="">
> I like the additional customization and linkage, but I'm not sure that<br class="">
> the registration flow is the right place for them. That's a lot of<br class="">
> screens for the user to click through before completing their setup,<br class="">
> which means a lot of opportunities for them to decide they can't be<br class="">
> bothered.<br class="">
><br class="">
> In particular, I think the download links would be more valuable if<br class="">
> surfaced after the first device is setup, rather than being a<br class="">
> potential roadblock to setting it up. (Like "ok, you're all set, now<br class="">
> sync with these other devices").<br class="">
><br class="">
> Ryan<br class="">
> _______________________________________________<br class="">
> Dev-fxacct mailing list<br class="">
> <a href="mailto:Dev-fxacct@mozilla.org" target="_blank" class="">Dev-fxacct@mozilla.org</a><br class="">
> <a href="https://mail.mozilla.org/listinfo/dev-fxacct" rel="noreferrer" target="_blank" class="">https://mail.mozilla.org/listinfo/dev-fxacct</a><br class="">
<br class="">
_______________________________________________<br class="">
Dev-fxacct mailing list<br class="">
<a href="mailto:Dev-fxacct@mozilla.org" target="_blank" class="">Dev-fxacct@mozilla.org</a><br class="">
<a href="https://mail.mozilla.org/listinfo/dev-fxacct" rel="noreferrer" target="_blank" class="">https://mail.mozilla.org/listinfo/dev-fxacct</a><br class="">
</div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></div></div><br class="">_______________________________________________<br class="">
Dev-fxacct mailing list<br class="">
<a href="mailto:Dev-fxacct@mozilla.org" class="">Dev-fxacct@mozilla.org</a><br class="">
<a href="https://mail.mozilla.org/listinfo/dev-fxacct" rel="noreferrer" target="_blank" class="">https://mail.mozilla.org/listinfo/dev-fxacct</a><br class="">
<br class=""></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></body></html>