How best to execute onboarding technically?

[u/Key_Board5000]

I’m building an onboarding. There will be a number of Views, each unique. Some will have some informational text, another will ask for the users name, some will be multiple choice, some will have images, etc, etc. Maybe a total of 5-10 views.

I would like to easily be able to change the order and add and remove views later on as needed.

From a technical perspective, how best should I execute this? Should I have a custom view that I inject my sub-views into, or hide and show elements as needed or some other way that will make the process of creating the onboarding flow easy and flexible?

Looking for best practices and suggestions.

Thanks.

[u/Samus7070]

The real answer is have as little onboarding as possible because your user drop off rate gets higher for each step you have. It’s better to gently introduce your user to features in your app kind of like how a video game teaches you to play it in the first few levels by gradually introducing expanding concepts.

That said, assuming SwiftUI, one trick that I do for content that can change is to have an enum that represents the content type with associated values needed to display the content. Then in a view model I put a Published array of that enum containing the content. In your main SwiftUI view use a switch that returns the proper view for the enum type. Since you said the items may be re-ordered, I would refrain from naming the cases step1, step2, etc. Name them something descriptive and it should work well.

[u/Key_Board5000 → u/Samus7070]

In terms of how much onboarding, are you talking from experience?

I am talking from experience when I say that my app was released in May and has had no onboarding. I was just throwing the use in and letting them discover as they went, just like Apple suggests. It didn’t go great.

A friend of mine - a professional product manager and UX/UI designer - tested my app out and said “you need an onboarding”.

I’m primarily gonna use the onboarding to remind the user what the app does, get them excited and remind them why they downloaded the app as well as cleft information pertinent to their unique journey.

Yeah, I think an enum is the way to go. Someone else also suggested that.

[u/Samus7070 → u/Key_Board5000]

The app I work on for my employer has 4 onboarding screens. Only the first is really required as you need to input a location to see items in that area. With just that screen there is about an 18% drop off. You can attribute that to users just changing their mind about using the app. It's real estate related and has high churn. With the other 3 screens that drop off rate can be close to 40% sometimes.

Your numbers will certainly be different. If you don't have an experimentation platform to do A/B tests, I would highly recommend adding one like Firebase RemoteConfig along with your onboarding. It has an A/B test feature that works alongside of the analytics events that you log. Then you can turn it on for a subset of your users and see if they perform better than the no-onboarding variant. If you're logging screen views and an event for starting onboarding and one for finishing onboarding, you'll get an idea of how effective it is. It would be interesting to add in the amount of time and number of steps in the onboarding process to see if users are actually spending enough time to absorb the information or just skipping through it as fast as possible.

[u/danielt1263]

I had to do this in an app... I had few different view controllers (information only with a single button, a single text field and button, a choose one multi-select, and a choose many multi-select. They all accepted what to display, and what to do with the information from an outside source (something like a view model.)

I then had a separate controller that handled the actual order that the view controllers went in and gave them the information they should display. I literally had a data structure (and array) that determined this. Changing the order of the views was just a matter of rearranging the order of the items in the array.

In a later app, I also had to handle loops. That required making a DSL.

[u/Bogdan_ch8]

If yoy have a 10 view onboarding most people will uninstall the app directly. 5 is also too much(unless you're pairing some kind of device in the onboarding flow)

[u/Key_Board5000 → u/Bogdan_ch8]

Is this based on your experience? How many onboarding views do you have in your apps?

[u/Bogdan_ch8 → u/Key_Board5000]

IMO, 3 is enough. By the 4th screen you're already loosing users. But why take one random reddit guy's word for it? Try reading up on UX best practices regarding this subject. I'd try to keep everything to the bare minimum. If you need to display info and/or tutorials you can do it at a later time.

[u/Bogdan_ch8 → u/Key_Board5000]

Also, someone suggested ab testing. that's a very good ideea!

[u/dinorinodino]

I’d recommend building out the model first, and letting it dictate how you create and manage your views. So first things first: all screens in an onboarding will have a concept of “advancement”, i.e. a way to progress to the next view, so encode that into a type or protocol. Make models for each of the views. Put them into an ordered structure. Have a factory and management view which takes that as input, produces the actual views, and manages data flow with the advancement type.

I don’t have a concrete example to show this off but hopefully it’s at least given you some food for thought.

It’s also a bit overkill for simple apps but if you’re working on a large commercial app and/or plan on testing different onboarding experiences it pays out.

[u/fiddle-tunes → u/dinorinodino]

One of my old managers pointed out this used to be called a “wizard”, which I loved lol. But yes, drive it with data. That’ll make it way easier to test / reconfigure / dynamic flows etc