Onboarding #23
Replies: 6 comments 3 replies
-
Users are already able to login so I don't think this is necessarily a user story for this project. For the open questions:
I can see us prompting them to fill out some of their profile. There's research that shows that giving them multiple steps makes it more likely that they'll fill it out (vs asking them to fill out a longer form). I think we can split it up into "tell us a bit about yourself" page (bio) and "what are your social links?" (social links).
All onboarding should be skip-able, though maybe we should have some kind of progress bar when they log in so they're encouraged to finish?
No need for email, I think, partially because we don't want to pay for an emailing service :P
Given we don't have mentor/mentee filters yet, I think we can do without them -
See above - multiple pages with smaller, manageable pieces results in higher engagement vs not.
Ideally this app is self explanatory, but I also think that teaching users how to use the app is outside the scope of this project. For the other forms, I think we can exclude them, as we just want to onboard them with the user fields we have right now - though we can certainly do it later as we add more user fields! |
Beta Was this translation helpful? Give feedback.
-
I'd redirect the user directly to the directory itself. Let them get right into using the product.
Agreed with @timmyichen if the user doesn't want to answer something, just let them skip. We should have all the necessary information on login from Discord.
Works for me!
What would this accomplish? My thought would be to have a question like: Are you interested in mentoring on being a mentee?
forms should be broken up into categories. Makes it more manageable for the user.
I'd like to make it as intuitive as possible. Video can come later if we have the user base and complexity to be valuable. |
Beta Was this translation helpful? Give feedback.
-
if this costs money than we can trash it!
so what directory page? I guess what is our main page called?
I also agree the skippable aspect of the onbaording seems good
I agree I think a prompt early would be best
yes multiple pages does seem more manageable by users |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for making those edits! The additional open questions:
I think it makes sense to do user login -> if not onboarded, user gets greeted -> goes to the relevant onboarding step -> goes to browse profiles page
I think this would be nice to have! |
Beta Was this translation helpful? Give feedback.
-
|
I updated the spec to include open questions regarding some of the tickets I created. Let me know what you think, or if we need to discuss this further during a meeting. Happy to make adjustments either way/whenever we figure this out. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for making the additions! My opinions are: I like the idea of a progress bar! Pages over modals. People dismiss modals instinctively and we want people to finish onboarding. Multiple pages over a single page. Makes it more likely for people to fill out, and more likely that people will partially fill out before stopping. It will also be easier to chain a bunch of pages together over a bunch of modals, and is better ux too. What are the benefits of using a modal? Re: how to tell if something has finished onboarding, we can use a few flags table as described in one of the closed tickets (I'm on mobile, forgot which one). Can include flags for each of the steps, or a single flag for the entire thing. Benefits of multiple are we can add onboarding steps and still put people through the new flow. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Summary:
This spec goes into the idea of the best way to onboard users.
Ideally, we want to provide a friendly welcome for new users and help them to pair with other programmers/users for collaboration. It also includes signing in process and features exploration.
Scope:
Out of Scope:
Data model: N/A
User Stories:
Features:
New pages/views:
Forms to Include:
APIs:
This is the route we will use to update user fields.
Security: N/A
Testing:
Open Questions:
Deployment:
Beta Was this translation helpful? Give feedback.
All reactions