Onboarding users can be complex and diverse or so I found in my time with *SimplyHers a super-app* with various user segments and goals.

So what are the options out there?

Because of privacy concerns, less than half of all app audiences allows their activity to be tracked on third-party services. As a result, we often lack information about new users installing the app, such as

1. their age, goals, health conditions, etc.
2. Is it a new user or a user with previous experience of using the app?

So many questions to ask, and all these user segments react and convert differently given the same series of onboarding screens.

As a result, App onboarding can have a lot of branches, depending on the main user goal and subgoals. Additionally, the product team is constantly experimenting which adds even more complexity to the onboarding content and logic.

Traditionally, app onboarding flows are hardcoded based on user attributes such as platform (Android vs iOs), Location (with experiments tested in major markets before localisation and further testing), and customer acquisition channels. The simplicity of this approach comes at the cost of slow iteration and limited experimentation.

Domain-Specific Language For Onboarding Screens.

DSL is a specialised language tailored to define and configure the onboarding screens to various customer segments. DSL provides constructs and syntax to specify the Text, Images/Media, Navigation, Input Fields, animations/transitions and conditional logic based on user input/behaviour.

This embedded solution effectively addresses templated screen creation enabling designers and developers to quickly iterate on onboarding flows without delving into complex programming code. Developers add new code and configurations to mobile repositories to deliver a new onboarding screen, experiment, or branch. Each sprint, a new app version containing all these onboarding changes is released. BUT….

1. Experiments and fixes in onboarding are Release-dependent. The mobile release cycle is too long, and product needs to be able to react quickly (e.g., verify a fresh hypothesis, fix wording because of localisation or legal issues, etc.)
2. Long time to detect errors in experiments. Analytical systems are not real-time, new build reviews and rollouts can take days, and in cases of misconfiguration, you can only figure out that users are not attributed to all experiment groups the next day or even later.
3. Engineers are bored by editing huge JSON configs. Mobile engineers wanted to solve interesting problems and build new experiences, not spend every sprint configuring flows with template steps.
4. Cognitive complexity to visualise & understand onboarding graphs for PMs, QA Engineers, and developers.

Backend/Server Driven Onboarding

A product team can craft a framework for creating UI Elements (views/nodes) from JSON objects. This allows us to create UI for two mobile platforms on the bank end and negates a sprint-ly wait for updates.

The JSON files can hold information about different step types (such as questions, feature cards, authentication, age input, etc.), step layout, and transition logic. The elements are capable invoking call-back functions and reporting analytics data back to the server.

To establish an agreement between server and client (native mobile apps), we have a repository with UI constructor contracts. Based on these, the backend generates a JSON object describing what needs to be drawn (and how), and the clients (native mobile apps) draw a UI according to these contracts.