Staged onboarding moves optional settings to the moment they are used. Each step needs three decisions: what can wait, what must remain before the first result, and what event brings the user back to the choice. Hiding fields isn't enough; people must still be able to find and fill them correctly.
Security, the meaning of data, and mandatory conditions for the current operation must remain in place before it runs. A logo can wait until external presentation, but access to applications cannot be left to an arbitrary value. Check the consequences of skipping a setting against a specific task.
Decide what must stay before work starts
Suppose a service helps publish job vacancies. A useful first draft may need a position title and duties. External publication needs correct contact details and access conditions for applications. A branded cover can wait. Inviting the whole team is only needed when other participants actually join the work.
List the settings and check three properties: does the value affect the current result, can it be corrected later, and can a wrong value cause harm? A setting that silently exposes applications to all participants doesn't become optional just because it occupies a separate screen. It needs a safe starting state and a clear access decision.
For the hypothetical vacancy service, a deferral matrix might look like this:
| Setting | Starting decision | When to bring it back | Exception |
|---|---|---|---|
| Title and duties | Keep before a usable draft | Edit from the draft itself | Label an empty practice example separately |
| Access to applications | Allow a safe draft; decide before publication | Before opening the vacancy to external people | Don't publish with undefined visibility |
| Cover and branding | Defer | When preparing the external page | Check mandatory publication requirements in advance |
| New-application notifications | Start with an acceptable baseline state | At publication or the first application | Don't silently disable critical work notifications |
| Colleague's role | Don't ask before the colleague participates | At invitation and access confirmation | A team journey may need a colleague before the first result |
The return event identifies where to offer the choice, not a forced display. If settings aren't needed, keep them available in the normal menu. Before a complete reordering of setup dependencies, check that moving one field actually changes the work sequence.
Don't confuse no choice with a safe default. If the product sets a value itself, the team must understand its consequences and show it where it matters. An empty field, a hidden assumption, and a reasonable default are three different states. Removing a question doesn't remove the decision from the system.
Check whether the choice makes sense without experience
A newcomer may not yet know which notifications they need, how to assign roles, or which team structure to choose. Answers at that point are guesses. They will need correcting later, and the person may not remember where they set them. A formally complete profile doesn't necessarily mean good data.
Connect the choice to a real action. When a manager publishes a vacancy, it is easier to understand who should see applications. The first application gives notifications a purpose. When a recruiter joins, you can explain role differences. This order makes the question clearer as long as initial data access remains safe.
NN/g's progressive disclosure principle keeps primary actions immediately available and opens complex or rare ones on request. The author also stresses that the levels must be divided correctly. Moving an important current choice deep into settings defeats the method and simply makes it harder to find.
Bring the question back at the right action
“We'll ask later” isn't a plan. Each deferred question needs a moment when it becomes useful: the first external send, a colleague's invitation, or setup of a repeat action. If there is no such moment, perhaps the question doesn't belong in training at all and can live quietly in settings. The remaining required path can be shown in a checklist with readiness criteria.
Tie the condition to state, not only days since signup. A user may have done nothing in a week or finished the whole start in one evening. Showing both the same questions on day three is convenient for a message schedule but weakly related to their readiness. Work state has more meaning.
Allow another deferral where appropriate. Branding shouldn't block an urgent publication if the service permits a standard appearance. But before granting external access, don't hide the consequences behind a small “Later” link. The difference should follow actual risk and product rules, not a desire to make all guidance identical.
Keep access through ordinary settings
If a setting disappears from the first wizard, it must still be findable in the ordinary interface. Give it a clear name and suitable location. People shouldn't have to relaunch training to change notifications. A redesigned start that makes later work harder merely moves the cost to another week.
Consider dependencies. Changing a time zone can change publication times; adding a role can affect access to old applications; connecting an integration can change notification delivery. Explain consequences before saving and preserve entered data where possible. Deferring a choice doesn't remove the need for good settings.
Check existing accounts and people who stopped midway. If they already have values, the new order mustn't silently overwrite them. If some configuration is missing, the interface must know whether work can continue. An explicit state list helps more than assuming everyone follows the wizard strictly from left to right.
Check the early result and the deferred step
Define an early result: for example, an eligible new account creates a usable vacancy draft within the chosen window. Then check external publication and work with applications. If drafts appear faster but publications fail more often because conditions were deferred, you removed a necessary step too early. In a trial, that can also prevent evaluation before payment. Evaluate the whole path.
Measurement rules are covered in time to value. Show the share reaching the result alongside the time. Don't exclude those who never finished setup: otherwise the speed of successful users creates an overly positive picture. PostHog funnels let teams inspect transitions and time separately; your report should preserve that distinction too. The tool matters less than defined events and a window.
Check deferred settings separately: can people find them, understand their consequences, save values, and avoid increased access errors? Showing a request isn't completing the setting, and completion doesn't guarantee a correct choice. Important conditions need a quality review of the result or a safe check the product can perform itself.
Define a reason to bring the step back earlier. For example, users begin publishing with incorrect conditions or repeatedly can't find the deferred setting. That criterion helps evaluate the decision against actual work instead of defending a shorter wizard just because the team spent time building it.
Start with one clearly optional question and move it to where it is used. Describe how the user returns to the choice and test both parts of the journey. Shortening the start is pleasant. Fixing incorrect publications and application access after an overly bold cut is much less pleasant, so define the boundary in advance.
