https://linen.dev logo
Join Slack
Powered by
Porting onboarding discussion thread here
# general
o
Porting onboarding discussion thread here
Luca: Changes as I see them needed from yesterday's discussion: Directly affects the waitlist site • Skip-waitlist mechanism design: if the product supports code input, link params, or admin pre-create, the waitlist site may need to know when to route around the normal waitlist flow. • State transitions across nodes: because the mapping explicitly includes waitlist as one of the nodes, that work will necessarily define behavior on the waitlist site. • Entitlement gate / onboarding order: if some onboarding steps move into-app, that changes what the waitlist site must collect vs. what it can defer. Probably affects the waitlist site indirectly • Conditional onboarding screens reduce pressure on the waitlist site to collect everything up front. • Known friendly flows imply the waitlist site is no longer the only intended entry point, which changes its role from “required path” to “one funnel among several.”
Oliver: Perfect ty Luca from my side, my questions/asks are • Where can I find the "you need to apply for membership" screen ◦ Can you add a slot in that screen for them to bypass with code • Is the name collection screen in the parent onboarding in the prototyper still what we want ◦ If so, that screen only asks for first name. We'll need on that asks for last name or family name • Can you please add / bring back a screen for directing them to text the agent for the first time • Can you please add a screen that directs them to subscribe before continuing and has a button that you can assume will outlink to a web page • Can we get a COPPA screen in-app
Luca: ok 1. it's in there, i'll add that extra bypass code button 2. if they're submitting their info on the application site then no we don't even need that 3. yes where does that live as a full page splash? 4. yes - so we're assuming they can get in past membership without card down?
Oliver: 1. How do I see it 2. yes but I'm designing for the flow where it's a known friendly going app-first (they never hit the membership) 3. This would be a step in the onboarding flow - so yes a full page. Same as above this step will only be necessary if they haven't gone through membership 4. Yes same as above
Luca: oh got u
Mike: my understanding the standard flow for web will be 1. user signs up to be on waitlist 2. user can fill out their family information, but doesn't have to 3. we will "accept" a user 4. user will "activate" their account, by putting their card down or getting a promotional trial 5. after activating they will receive the number to text 6. they text the number 7. the number tells them to download the app 8. they download and start onboarding (if they do this before texting we will tell them to text during onboarding) Aside from that flow we will have the ability to allow users to skip straight to 8 and be "auto activated" in the app
(Verbal discussion ensues - granola here)
l
@royce confirming essentials for waitlist submission are; How many children do you have? How old are they? Are your children using their own devices? What devices do your children use? Where should we send your decision? (name + Email + phone number intake) Also @oliver at this point we would be making them an account for the member portal, right now their way of logging in is 2FA that is correct right? like no web portal password, all attached to phone number + 2FA (just confirming)
👍 1
o
Confirmed
l
ok @Michael Landolfi so everythings cleaned up and simple looking good main callouts: • Step 1 "Waitlist" -> Step 2 "Set up Family Profile" (not Family Check-In) • Email copy updated • Optimized to single column flow for mobile friendly • Few pending items for site like the quotes and CEO quote (need both from @royce) and need to purchase stock images and video (i'll do that today and send over) • Scrapped member video with royce for now • Member portal updated to login with phone number (you can use mine 646-775-0708) - reccomend going through the membership waitlist funnel first Links: Waitlist site: claude.ai/design/p/15d96331-c245-41f4-8c20-7437c3e1a7f4?file=Clearspace+Cream.htm…&via=share Email Marketing: claude.ai/design/p/cfb99d29-b832-4e6e-8899-aaae2617655f?file=email-4-activation.h…&via=share
💙 1
lmk if you have any issues
@oliver gonna get started on app notes in meantime
m
awesome thank you
o
Perfect ty
l
@oliver New users with code - are we giving them their agent # in the beginning once they submit the code? We have the agent helping guide users through the rest of onboarding. Alt flow could be we log invited people's numbers with the agent, agent gives them link to app + their special code + then they have agent and go through onboarding
o
Yes - if their code is valid, next step (or at least at some point in onboarding) we need them to text the agent. You can assume agent will be smart enough to know that they are already in the app so it will just say, "got it you can always reach me here" or similar. It won't direct them to download the app. And no need to simulate the imessage experience once they click that button
Can you also include an invalid code state
l
ok so flow is like: login with code -> enter info -> card down -> get number -> set up family?
kind of messy back and forth
o
No imo it should be login -> apply for waitlist (small button at bottom for "already have an access code?") -> text agent -> set up family -> last step - subscribe
Like this is all the flow where we don't recognize you but you just proved to us we were a friendly. I think we should do text-the-agent first, then normal setup, then card down last
And in practice, in all likelihood we actaully won't require card down for these people because they are friendlies but we should have it
l
ok
so are they "setting up family" in ios or with agent? -i.e: kids + devices etc
o
in iOS
l
ok previously they did that with the chat agent
i.e: who are your kids what are their names and ages etc etc
if we're gonna bring it back in to an interactive ios experience, i'd probably design it to match the site - cool?
o
wym match the site
Like similar text boxes?
like a form?
l
yeah
o
Yeah
l
ok wait i might need to update the web form for the initial intake - we probably want to get specific kids names + their devices on first waitlist sign up right? otherwise we're pushing everyone through this child name + device selection flow all over again in app or is that fine? @royce @oliver
👍 1
o
aren't we already doing that?
the app can be smart enough to skip the child names and devices if we've already gotten that info from waitlist application
l
currently doing for initial waitlist: How many children do you have? How old are they? Are your children using their own devices? What devices do your children use? Where should we send your decision? (name + Email + phone number intake) (for broadness + simplicity for assessing membership)
but we can change those questions to be specifically the necessary info for app
o
@royce wyt. I'd say yes we could make a cleaner mapping to the data we need for the app. like • Enter child's name ◦ set their age ◦ set their device(s) • Where should we send your decision?
If there's a way to get the parent to say all the details in natural language that's fine too. We can have a simple AI that extracts what we need from it This is what we did with the humans in the loop demo agent, it asked what are your childrens ages and what devices do they have and drew its best conclusion
r
i think we should keep it simpler for the initial intake and then layer clarifying questions that more precisely map to our onboarding in the follow up information step
when they "set up the rest of their profile"
o
one downside there is that if they don't actually do the "set up rest of profile" step we can't have much set up for them that feels nice and welcoming when they arrive in the app
👍 1
and I do think that experience feels great at the moment, arriving and seeing everything all set up for you (kids names and devices)
r
yeah the tradeoff is just waitlist joining friction vs delightfulness of arrival
o
agreed
but we reduce total amount of start-to-finish friction if we don't ask them twice
I think if I was asked to fill in which kids have which devices a few days after describing it, it'd be ok, but if we're ever in open-throttle mode where want to let people off the waitlist more quickly filling that out back to back would be annoying
r
yeah let's see how it feels - we should try to make it as painless as possible
l
see how which feels? asking during app onboarding?
r
no asking each childs name, age and devices during initial waitlist
l
oh ok
so @Michael Landolfi i need to update intake questions on site
o
Royce you're agreeing try this in initial page right?
• Enter child's name
◦ set their age
◦ set their device(s)
• Where should we send your decision?
So we ask once and that's it
l
we still are gonna need to ask for friendlies
r
i don't think we'll need to will we?
the app should still be able to pick up without it
l
i thought we locked those in as necessary to use app
r
necessary to use app yes, but not necessary to get to the onboarding stage of app
is my understanding
l
Ok so just trying to say it back so we can all get aligned: • Web: "Waitlist" collects: ◦ Child name(s) ◦ Child age(s) ◦ Child device(s) ◦ E-mail + Phone Number • Web: "Family Profile" collects ◦ Nice to haves like specific apps, schedules, desires/frustrations • iOS App: ◦ Onboarding for accepted users: ▪︎ Pre-filled family -> Device setup ◦ Friendlies: ▪︎ ______? @royce
👍 1
o
I agree with this ^ Friendlies fill that info out in-app since we don't know it yet.
👍 1
r
yep lgmt
lgtm
l
ok deal
no email or phone number needed for friendlies though correct
o
email not needed, phone is needed but we have it because absolute first step is logging in with it
l
ok so @Michael Landolfi hang tight i need to update site
site intake updated @Michael Landolfi
m
thank you, finally getting started on it 😁
r
🍻🏇
l
for device information collection in-app, since we wont be able to support certain devices should we take them out as options (previously we had bunch of diff devices to understand potential device support needs)
m
wdym in app? like in the add device screen?
l
like listing the devices your kids have
previously on web because it was earlier in the funnel we had stuff like TV, game console, etc
so we could omit those people
m
aren't we still doing it in web?
l
we are also now doing it in app for friendlies that come in w a code
Screenshot 2026-07-16 at 5.29.48 PM.png
referencing the "waitlist collects" at top, and oli's message of "friendlies fill out that info in-app since we don't know it yet"
m
for in app they will just be adding the devices they want to track specifically so yes it should only be ones we support
l
ok so im taking out stuff like tv/game console etc
m
yeah
🔥 1
just to clarify, we only need to "collect" that information as a part of device setup, we don't need to ask what devices in addition to them adding devices fore their children, does that make sense?
l
yup
just trying to figure out where we're deviating from 1:1
2 Views
Open in Slack
PreviousNext
Powered by