Check onboarding prerequisites before users invest in setup
Check essential capabilities before lengthy setup, distinguish fixable conditions from hard limits, and offer honest alternatives without unnecessary permissions.
In this article
Check prerequisites before asking people to do work that depends on them. If the first useful task requires a supported capability, an enabled account feature or access to a device, surface that condition early and explain the next action. Keep optional enhancements out of the critical path.
A readiness check should answer a specific question: can this person perform the task they selected in the environment they are using now? A green badge that only confirms the page loaded says little about recording audio, importing a file or joining a meeting.
It should also avoid becoming another long setup form. Check what the product can establish directly, request access only when justified and ask the user for information that changes a real decision.
Separate three kinds of readiness
Consider an illustrative meeting-notes product. Its first useful task is to capture a short microphone recording and create a draft note. A separate feature can import an existing audio file, and calendar connection is optional.
That product could classify its checks like this:
| Condition | What it means for this task | Useful action |
|---|---|---|
| Required recording capability is absent | This browser environment cannot perform live recording through the supported implementation | Offer a supported environment or the available file-import route |
| Microphone access has not been granted | The capability may work after the person chooses to grant access | Explain the purpose and offer a deliberate microphone check |
| No usable input is found after access | The current recording path cannot proceed | Help select or connect an input and check again |
| Account lacks the recording entitlement | The current account cannot use this feature | Explain access requirements or let the person choose an available task |
| Calendar is not connected | Recording can still work | Continue and offer calendar setup later |
These are proposed product states, not claims about Google Meet or any particular recorder. The key is that each result changes the available action.
“Something is missing” is too vague. “Connect your calendar to continue” is incorrect if the selected task does not require calendar access. “Your device is unsupported” is premature when the real issue is a permission the user has not yet considered.
Check the requirement for the selected task
A product can have different requirements for basic and enhanced use. Google Meet’s published requirements distinguish supported environments, account and administrator conditions, device access and hardware recommendations for more demanding features.
The design lesson is to identify which requirement belongs to the user’s immediate goal. A recommendation for better video effects should not quietly become a barrier to a simpler supported activity.
For the illustrative recorder, choose the first task before evaluating readiness. If someone wants to upload existing audio, a microphone prompt is irrelevant. If they want a live recording, file-import readiness alone should not produce an “All set” result.
Account entitlement deserves a separate check from device capability. A browser change cannot fix an account without access. Show the correct remedy, including an administrator route when permission belongs to someone else. Explain unavailable access before asking the customer to configure the rest of a workflow they cannot use.
Check capabilities without guessing from a browser name
MDN’s feature-detection guidance distinguishes testing for a needed feature from identifying the browser by its name. The former can help decide whether to run a feature or offer an alternative.
For the proposed recorder, this means checking the capabilities its implementation actually requires. A browser-name allowlist can exclude a workable environment or admit one where the relevant capability is unavailable.
A capability’s presence is still narrower than a successful task. Finding an API does not establish that permission will be granted, a working input exists or an upload will finish. Progressively establish those conditions through the supported workflow, with honest status wording at each step.
Avoid collecting a detailed device profile merely to display a readiness badge. Retain diagnostic details only when they have a defined purpose. The user usually needs an explanation of the failed condition and the next action, not an inventory of their environment.
Published support policy still matters. A product can explain that an environment falls outside its tested support scope even when a capability appears available. Keep that statement distinct from a claim that the task is technically impossible.
Ask for permission at a meaningful moment
Place the microphone request after the person chooses a task that needs it and understands what the request enables. A button such as Check microphone makes the action more legible than an unexpected browser prompt immediately after signup.
Android’s runtime-permission guidance illustrates the same contextual principle for native apps: explain why a feature needs access, respond to the user’s decision and keep applicable remaining functionality available. The platform mechanisms differ from the web; the design principle does not require copying Android’s implementation.
In the recorder example, declining access should return to a stable screen. Explain that live recording needs microphone access and offer the available import path. Do not repeatedly reopen the prompt or imply that denial means the whole account is broken.
If the user chooses to test recording, state whether the sample stays local or is uploaded, according to the actual implementation. Show a visible recording state and a way to stop. A readiness check should not quietly become a recording session.
Make the check small and repeatable
Run the cheapest relevant checks before lengthy configuration. Delay sensitive or disruptive checks until the person reaches the point where they are needed. Preserve earlier choices if the environment needs repair.
After the user connects an input or switches accounts, offer Check again. Show which condition changed instead of replaying the entire introduction. If a result can become stale, recheck it when the task begins.
Treat “could not check” as a distinct state. A network interruption while verifying entitlement does not prove the account lacks access. Offer a retry or appropriate fallback without presenting an unverified failure as a permanent limitation.
For what information to ask before this point, see what to ask at signup. The wider accessible onboarding guide helps ensure the check and its recovery actions are usable.
Review the result as a promise
Walk through the selected first task after every supposedly successful check. Confirm that the status describes what was established: capability available, permission granted, input working or account access confirmed. Keep those statements separate until the full task has succeeded.
Then review the blocked and uncertain paths. Each should name the affected activity, preserve useful progress and offer a real next step. The value of an early readiness check is the decision it enables before the person invests more work.
Sources
- Google: Learn what requirements you need to use Google Meet
- MDN: Implementing feature detection
- Android Developers: Request runtime permissions
