Guide people through necessary setup to a first useful result without unnecessary interruption.
Onboarding connects a person's intent to the first task they can complete. Ask for the information needed now, explain why it matters, and defer optional configuration until it becomes useful.
Choose a concrete outcome, such as creating a named workspace and opening its first empty collection. Separate required setup from optional instruction. An introductory tour is not a substitute for making the first task understandable.
Where the product permits it, let people explore before requiring an account. If authentication is necessary, explain the reason and use the methods actually available in the application. See Login for the boundary between interface controls and authentication services.
Figure in preparation
From setup to first use
A setup request moves from required input to creation and a confirmed result, with a return to preserved input if it fails.
Let people skip optional instruction and return to it later. Ask for permissions when the relevant task needs them and explain the benefit. Browser permissions, account creation, and storage are application integrations; Liquidify does not provide those services.
Use TextField for supported text input, Button for actions, and Link with an href for navigation. Use a native <form> when submitting input. Liquidify Form is a visual grouping component and does not submit or validate data.
For example, name a required field “Workspace name” and the submit action “Create workspace.” Display confirmation only after the application receives a successful result. Keep optional preferences available after setup instead of making them prerequisites.
Preserve valid input when a request fails. Explain the field or operation that needs attention and allow correction or retry. If the flow can resume after a reload, the application must store and restore its progress; do not promise resume behavior until it exists.
Avoid putting a long setup flow into a sequence of dialogs. Use a dedicated page for a task that needs sustained attention. An enabled Dialog action requests closure without awaiting a save. If a controlled dialog must remain open during validation or failure, application code must decide when to accept that request. See Dialogs.
Test successful setup, missing input, rejected requests, repeated activation, and returning after an interruption. Confirm that focus reaches useful content after each transition and that long labels and errors remain visible in both themes and narrow layouts. Completion should lead to Use, with Get help available when needed.