Guided Onboarding and Progressive Disclosure

1) The problem: shorter onboarding must not become ambiguous

Bad onboarding usually fails in one of two directions: it asks every possibly useful question up front, or it hides important requirements behind “clean” progressive UI. The first raises cognitive and privacy burden. The second makes users unsure about what is required, optional, consent-related, payment-critical, approval-critical, or still incomplete.

This lesson builds Guided Onboarding Progressive Disclosure Contract v1. The contract limits collection by purpose and role, groups steps logically, makes required/optional status and progress visible, and reveals secondary choices only when their context actually applies.

Core rule: progressive disclosure reduces clutter; it must not hide obligations, consent, payment, approval, or incomplete state.

2) Lesson boundary

COM-020 owns onboarding and disclosure rules. COM-019 owns the Safe Workflow Lab, and COM-021 owns Talent Profile and Capability Evidence. This lesson does not execute a live signup, invent lawful basis, or claim complete accessibility conformance from a UI pattern.

3) Mental model: Purpose + Role → Minimum Needed → Guided Steps → Conditional Disclosure → Review

For every onboarding flow, preserve this sequence:

1. purpose;
2. persona or role;
3. minimum required data;
4. logical step grouping;
5. visible required/optional status;
6. progress and instructions;
7. context-specific disclosure trigger;
8. validation and error recovery;
9. visible notice/consent/approval boundary;
10. review summary and auditable completion.

4) Required does not mean “might be useful later”

A field is required only when the current purpose actually needs it. If an integration has not been selected, its credential should not be collected yet. If a reviewer only needs approval access, analytics and publishing configuration should not be forced into that path.

For each field, ask: what purpose needs it, what real outcome fails without it, and whether the same outcome can be achieved with less data or later collection.

5) What progressive disclosure may hide

It may defer secondary or context-dependent choices, such as advanced integration settings after an integration is selected. It must not hide required task information, material notices, consent or approval boundaries, payment-critical information, or the completion state.

If a user can reach “complete” without seeing a critical notice, the design is invalid even if the interface looks simpler.

6) W3C guidance for multi-step forms

W3C WAI guidance recommends splitting long forms into logical smaller stages, making optional stages recognizable and skippable, and communicating progress. Form instructions should clearly explain required/optional input and relevant formats, and controls need accessible labels.

This is usability/accessibility guidance; it does not by itself decide legal necessity or lawful basis for data collection.

7) Data minimisation and privacy by design

The EDPB lists data minimisation alongside purpose limitation and accountability as basic data-protection principles. Its privacy-by-design/default guidance describes data protection as something built into systems from the start and reviewed continuously.

The practical lesson boundary is: the default onboarding path should not collect data that the selected purpose does not need. Specific legal applicability remains context-dependent and may require qualified review.

8) Baseline redesign: the 42-field setup page

The current setup page asks for company profile, publishing preferences, analytics access, optional integrations, billing, and team permissions before anything can be saved. Optional fields look mandatory, and integration credentials are requested even when the integration is not selected.

A stronger sequence is:

1. Purpose & role;
2. Core company profile;
3. Publishing only when relevant;
4. Integration selection, then reveal settings for the selected integration;
5. Billing/material notices with clear status;
6. Review summary with Back/edit before completion.

Every step keeps progress, instructions, validation, and recovery visible.

9) Invalid shortcuts

Collect optional credentials early is invalid when the trigger is absent. Hide consent under Advanced is invalid when the boundary is required for completion. Remove progress from a multi-step flow weakens orientation. Mark everything required destroys the distinction between necessary and nice-to-have data.

10) Evidence contract and states

The artifact uses 22 dimensions: onboarding_flow_id, persona_or_role, purpose, step_id, step_order, step_title, required_fields, optional_fields, data_purpose_map, disclosure_trigger, advanced_section_id, skip_allowed, back_allowed, progress_indicator, instruction_ref, accessibility_label_ref, validation_rule, error_recovery, consent_or_notice_ref, completion_state, review_summary_ref, and evidence_ref.

Nineteen are critical to the bounded decision. Missing decisive evidence must remain HOLD, UNKNOWN, PARTIAL, or BLOCKED rather than being converted to success.

11) Lab

The offline lab uses eight synthetic fixtures and no network or production data. Mutations request optional credentials before a trigger, hide a consent/approval boundary, remove progress, over-require data without purpose, remove an accessible label, and switch to a reviewer-only persona. The evaluator runs 48 deterministic assertions from visible evidence.

12) Transfer challenge: a second persona

A second persona only needs review/approval access. Recompute the path so analytics and publishing configuration are not exposed, approval-critical notices remain visible, completion evidence fits the role, and the baseline admin path is not copied blindly.

13) Summary

Guided onboarding means asking less, grouping better, and never hiding decisive obligations. Start with purpose and role, collect only what is needed, keep progress and instructions explicit, reveal advanced choices only after their trigger, preserve recovery and review paths, and mark completion only when critical evidence is complete.

References and freshness

• W3C WAI, Forms Tutorial — rechecked 2026-09-15.
• W3C WAI, Multi-page Forms — rechecked 2026-09-15.
• W3C WAI, Form Instructions — rechecked 2026-09-15.
• EDPB, Privacy by design and by default + Basic principles — rechecked 2026-09-15.
• EDPB Guidelines 4/2019 and the 2026 business-owner summary are supporting context; specific legal applicability remains context-dependent.