Guided Onboarding و Progressive Disclosure

1) مسئله: onboarding کوتاه‌تر، اما نه مبهم‌تر

یک onboarding بد معمولاً در یکی از دو افراط می‌افتد: یا از همان صفحهٔ اول هر داده‌ای را که شاید روزی لازم شود می‌پرسد، یا برای «تمیز و مینیمال» دیده‌شدن، اطلاعات مهم را پشت بخش‌های اختیاری پنهان می‌کند. اولی بار شناختی و حریم خصوصی را بالا می‌برد؛ دومی باعث می‌شود کاربر نفهمد چه چیزی لازم است، چه چیزی اختیاری است و چه چیزی برای consent، پرداخت یا approval اهمیت حیاتی دارد.

هدف این درس ساخت Guided Onboarding Progressive Disclosure Contract v1 است؛ قراردادی که جمع‌آوری داده را بر اساس purpose و role محدود کند، مراحل را منطقی بچیند، required/optional و progress را آشکار نگه دارد و فقط انتخاب‌های ثانویه یا وابسته به context را به‌صورت progressive reveal نشان دهد.

قاعدهٔ مرکزی: Progressive disclosure برای کاهش شلوغی است، نه برای پنهان‌کردن الزام، رضایت، پرداخت، approval یا وضعیت ناقص کار.

2) مرز درس

COM-020 مالک قرارداد onboarding و disclosure است. COM-019 به Safe Workflow Lab مربوط است و COM-021 به Talent Profile و Capability Evidence. این درس نه live signup اجرا می‌کند، نه مبنای حقوقی را اختراع می‌کند و نه conformance کامل accessibility را صرفاً از روی چند الگوی UI ادعا می‌کند.

3) مدل ذهنی: Purpose + Role → Minimum Needed → Guided Steps → Conditional Disclosure → Review

برای هر onboarding flow این ترتیب را حفظ کن:

1. Purpose — دقیقاً این flow برای چه هدفی است؟
2. Role — این persona چه کاری واقعاً باید انجام دهد؟
3. Minimum required data — فقط چه داده‌ای برای همان هدف لازم است؟
4. Logical step — فیلدها در چه گروه منطقی قرار می‌گیرند؟
5. Required / Optional visibility — وضعیت هر ورودی برای کاربر واضح است؟
6. Progress + instructions — کاربر می‌داند کجاست، چه مانده و فرمت ورودی چیست؟
7. Disclosure trigger — بخش پیشرفته دقیقاً چه زمانی relevance پیدا می‌کند؟
8. Validation + recovery — خطا چطور اصلاح می‌شود بدون پاک‌شدن دادهٔ سالم؟
9. Notice / consent / approval boundary — اطلاعات حیاتی همیشه آشکار و قابل‌ردیابی است؟
10. Review summary + completion — قبل از اتمام، کاربر چه چیزی را می‌تواند بازبینی کند؟

4) Required با «هر چیزی که شاید مفید باشد» فرق دارد

یک فیلد زمانی required است که برای purpose فعلی لازم باشد، نه اینکه صرفاً برای تیم محصول جالب باشد. اگر integration هنوز انتخاب نشده، credential آن نباید از قبل خواسته شود. اگر reviewer فقط approval انجام می‌دهد، تنظیمات analytics و publishing نباید به او تحمیل شود.

برای هر فیلد حداقل این سه سؤال را جواب بده:

• این داده برای چه purposeای لازم است؟
• اگر جمع نشود، کدام outcome واقعی غیرممکن می‌شود؟
• آیا همان outcome با دادهٔ کمتر یا در مرحلهٔ دیرتر قابل‌دستیابی است؟

5) progressive disclosure چه چیزی را می‌تواند پنهان کند؟

معمولاً فقط secondary یا context-dependent choices را. مثال: تنظیمات پیشرفتهٔ یک integration بعد از اینکه خود integration انتخاب شد. در مقابل، این موارد نباید پشت accordion اختیاری یا «More details» گم شوند:

• required task information؛
• material notices؛
• consent یا approval boundary؛
• payment-critical information؛
• completion state و هر چیزی که مانع اتمام معتبر می‌شود.

اگر کاربر بدون دیدن یک notice حیاتی بتواند به completion برسد، طراحی شکست خورده است حتی اگر UI ظاهراً ساده باشد.

6) راهنمای W3C برای فرم چندمرحله‌ای

W3C WAI توصیه می‌کند فرم‌های طولانی به مراحل کوچک و منطقی تقسیم شوند، مراحل اختیاری قابل‌شناسایی و قابل‌skip باشند و کاربر از progress آگاه بماند. همچنین instructions باید required/optional بودن و فرمت‌های مرتبط را روشن کنند و labels برای controlها قابل‌دسترسی باشند.

این guidance به ما الگوی usability/accessibility می‌دهد؛ اما به‌تنهایی تعیین نمی‌کند یک داده از نظر حقوقی لازم است یا چه lawful basisی دارد.

7) data minimisation و privacy by design

EDPB data minimisation را در کنار purpose limitation و accountability از اصول پایهٔ پردازش داده می‌داند. در راهنمای Data Protection by Design and by Default نیز تأکید می‌شود که حفاظت از داده باید از ابتدا در طراحی وارد شود و به‌صورت مستمر بازبینی شود.

برای این درس نتیجهٔ عملی این است: پیش‌فرض onboarding نباید از کاربر داده‌ای بگیرد که برای purpose انتخاب‌شده لازم نیست. بااین‌حال، تشخیص حقوقی نهایی همیشه به context و بررسی متخصص وابسته است.

8) مثال پایه: صفحهٔ 42 فیلدی را بازطراحی کن

فرض کن onboarding فعلی از client جدید، در یک صفحه company profile، publishing preferences، analytics access، optional integrations، billing و team permissions را می‌خواهد. چند فیلد optional شبیه mandatory دیده می‌شوند و credential مربوط به integration حتی وقتی integration انتخاب نشده درخواست می‌شود.

بازطراحی بهتر:

1. Step 1 — Purpose & role: هدف و نقش را مشخص کن.
2. Step 2 — Core company profile: فقط دادهٔ لازم برای ایجاد workspace.
3. Step 3 — Publishing: فقط اگر role و purpose به publishing نیاز دارد.
4. Step 4 — Integrations: ابتدا انتخاب integration؛ سپس تنظیمات همان integration reveal شود.
5. Step 5 — Billing / notice: هر اطلاعات payment/notice لازم آشکار و غیرقابل‌ابهام.
6. Step 6 — Review: summary، امکان Back و اصلاح قبل از completion.

در هر step، progress، instructions، validation و recovery باید صریح باشند.

9) shortcutهای خطرناک

Shortcut A — credential اختیاری را زودتر بگیر

غلط است. اگر trigger هنوز فعال نشده، این جمع‌آوری premature و بدون purpose فعلی است.

Shortcut B — consent را داخل «Advanced» بگذار

غلط است. اگر consent یا approval برای completion لازم است، نباید optional به نظر برسد یا پشت disclosure ثانویه پنهان شود.

Shortcut C — progress را حذف کن چون flow «کوتاه» است

اگر flow چندمرحله‌ای است، نبودن progress orientation را ضعیف می‌کند و می‌تواند کاربر را دربارهٔ مقدار باقی‌مانده سردرگم کند.

Shortcut D — همهٔ فیلدها را required کن

این کار مسئله را حل نمی‌کند؛ فقط distinction بین minimum necessary و nice-to-have را نابود می‌کند.

10) Evidence Contract و stateها

Artifact این درس 22 بُعد دارد: 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, evidence_ref.

19 فیلد از این‌ها برای تصمیم بحرانی‌اند. اگر evidence حیاتی ناقص باشد، نتیجه باید HOLD / UNKNOWN / PARTIAL / BLOCKED بماند؛ نباید completion موفق ساخته شود.

11) آزمایش عملی

Lab آفلاین 8 fixture دارد و هیچ API یا دادهٔ واقعی استفاده نمی‌کند. mutationها شامل این مواردند:

• credential اختیاری قبل از trigger درخواست شود؛
• consent/approval boundary داخل بخش اختیاری پنهان شود؛
• progress از flow چندمرحله‌ای حذف شود؛
• همهٔ فیلدها بدون purpose روشن required شوند؛
• accessible label حذف شود؛
• persona به reviewer-only تغییر کند و flow باید دوباره محاسبه شود.

Evaluator فقط از evidence قابل‌مشاهده استفاده می‌کند و 48 assertion قطعی اجرا می‌شود.

12) تمرین انتقال: persona دوم

Persona دوم فقط review/approval می‌خواهد. او نباید analytics یا publishing را configure کند. flow را طوری بازسازی کن که:

• contract همان contract بماند؛
• fieldهای نامرتبط expose نشوند؛
• approval-critical notice همچنان visible باشد؛
• completion evidence با role جدید سازگار شود؛
• baseline client-admin path کورکورانه کپی نشود.

13) جمع‌بندی

Guided onboarding یعنی کمتر پرسیدن، بهتر گروه‌بندی‌کردن و هیچ الزام مهمی را پنهان نکردن. Purpose و role را اول مشخص کن، minimum necessary data را جدا کن، progress و instructions را روشن نگه دار، advanced choice را فقط با trigger مناسب reveal کن، recovery و review را حفظ کن و completion را فقط زمانی ثبت کن که evidence بحرانی کامل باشد.

منابع و تازگی

• 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 2026 business-owner summary used as supporting context; specific legal applicability remains context-dependent.