صمّم Onboarding حول أول لحظة قيمة

تسمّي منتجات كثيرة سلسلة Tooltips باسم Onboarding. يضغط المستخدم «التالي» خمس مرات، ويتجاوز شاشة احتفال، ثم يصل إلى Workspace فارغة من دون أن ينجز شيئًا. علّمه المنتج خريطة الواجهة، لكنه لم يثبت له أي قيمة.

التعريف الأقوى عملي: Onboarding هو أقصر مسار آمن ينقل المستخدم من هدفه إلى نتيجة مفيدة يستطيع فهمها والاحتفاظ بها والبناء عليها. في أداة للتجار قد تكون النتيجة طلبًا واحدًا جرت مزامنته مع حالة مطابقة واضحة. وفي منتج Analytics قد تكون Event حقيقية وصلت إلى تقرير مفيد. وفي أداة تعاون قد تكون Artifact فعلية شاركها المستخدم مع زميل.

توضح إرشادات Nielsen Norman Group حول الجولات التعليمية والمساعدة السياقية أن الناس لا يريدون عادة دراسة التطبيق قبل استخدامه، وتقترح إظهار المساعدة داخل سياق النشاط الحالي. كما تتعامل إرشادات الحالات الفارغة مع السطح الخالي كفرصة لشرح الحالة وإعطاء طريق مباشر إلى مهمة أساسية. لذلك ليست مشكلة التصميم «كيف نشرح كل ميزة؟»، بل «ماذا يجب أن يفعل المستخدم ويفهم ليحصل على أول نتيجة موثوقة؟».

عرّف أول قيمة كنتيجة يمكن ملاحظتها

لا تبدأ بالشاشات. ابدأ بجملة: «حصل المستخدم على أول قيمة عندما…»، وأكملها بنتيجة خارج واجهة Onboarding. إنهاء Checklist ليس قيمة، وإنشاء Project قد يكون مجرد إعداد. أما استيراد سجل حقيقي واحد والتحقق من ظهوره بصورة صحيحة فهو أقرب، لأن المستخدم يستطيع فحص النتيجة.

اختر Activation Event تجمع بين الفعل والدليل. مشاهدة Dashboard وحدها ضعيفة لأن المستخدم قد يكون محتارًا، وضغطة الزر ضعيفة لأن العملية قد تفشل. فضّل حالة مثل `report_created` مع `source_connected` و`result_viewed`، أو `invite_sent` مع `teammate_joined` عندما يكون التعاون هو الوعد. وإذا تعذر إثبات القيمة في جلسة واحدة، فافصل بين Leading Indicator فوري ونتيجة مؤكدة لاحقًا.

اكتب الشروط المسبقة بوضوح: هل يحتاج المستخدم بيانات أو صلاحية أو زميلًا أو وسيلة دفع أو بيانات تكامل؟ إذا كان الشرط بيد شخص آخر، يجب أن يعرض Onboarding هذه التبعية ويقدم حالة انتظار مفيدة. لا تصف المستخدم بأنه غير نشط بينما النظام ينتظر Administrator.

اكتب First-Value Contract صغيرًا: نوع المستخدم أو هدفه، نقطة البداية، المدخلات المطلوبة، المخرج المفيد، الدليل، الزمن المتوقع، الخروج الآمن ومسار التعافي. عندها يراجع Product وDesign وEngineering الرحلة نفسها بدل أن يحسّن كل فريق شاشاته منفصلة.

اسأل فقط عما يغيّر المسار

يجب أن يكسب كل سؤال مبكر مكانه بتغيير الخطوة التالية. سؤال الدور مفيد فقط إذا اختار مهمة أو Default أو شرحًا مختلفًا. أما حجم الشركة ومصدر التعرف إلى المنتج وتفاصيل الملف الاختيارية فقد تفيد Sales أوSegmentation، لكنها لا يجب أن تعطل نتيجة المنتج إن لم تكن ضرورية فعلًا.

استخدم التفرع بحذر. سؤال قوي واحد مثل «ماذا تريد أن تنجز أولًا؟» يمكنه اختيار Template أوWorkflow مناسب. عشرة أسئلة تفضيلات تخلق عملًا قبل أن تتكون الثقة. أعطِ Default موصى به واسمح بتعديله لاحقًا؛ لا تطلب من المستخدم توقع إعدادات متقدمة قبل أن يرى المنتج يعمل.

توصي صفحات الأسئلة في GOV.UK Design System بسؤال واحد لكل صفحة عندما يساعد ذلك الناس على فهم السؤال والتركيز في الإجابة. هذا لا يعني تحويل كل Onboarding إلى Wizard طويلة. اجمع المدخلات البسيطة المرتبطة، وافصل القرارات التي تختلف نتائجها أوValidation الخاص بها. ويجب أن يعكس Progress Indicator مراحل حقيقية، لا أن يضخم إعدادًا لثلاث دقائق إلى اثنتي عشرة خطوة احتفالية.

أخرج أسئلة Analytics من Critical Path قدر الإمكان. إذا احتاج المنتج سؤال Marketing Attribution، فاجمعه بعد أول قيمة أو اجعله اختياريًا وواضحًا. انتباه المستخدم في Onboarding مستعار؛ أنفقه على نتيجته.

استبدل الجولة بمهمة حقيقية

تعرض الجولة الإجبارية Controls قبل وجود سبب يجعل المستخدم يتذكرها. أما المهمة الحقيقية فتصنع السياق. ابدأ داخل سطح المنتج الفعلي بهدف ضيق وDefaults واقعية ونتيجة مرئية. يجب أن يستطيع المستخدم الإكمال من دون حفظ Labels ظهرت في Overlay سابق.

استخدم Pull Help والمساعدة السياقية. أبرز Control عندما تصل المهمة إليه فقط، واشرح أثر القرار بجانبه، واترك المساعدة الدائمة قابلة للوصول لاحقًا. توصي إرشادات NN/G للتهيئة بـProgressive Disclosure: اجعل المساعدة موجودة من دون عرض كل التفاصيل دفعة واحدة. وتوضح إرشادات Progressive Disclosure أن إظهار الخيارات الأهم أولًا يساعد المبتدئ على التركيز وتجنب أخطاء لا يحتاج إليها.

تقلل Templates والبيانات التجريبية رهبة الصفحة الفارغة، لكن سمّها بصدق. Demo Project ليست مشروع المستخدم. وفّر انتقالًا واضحًا من المثال إلى البيانات الحقيقية، ولا تخلط Metrics تجريبية مع Production. وإذا كانت البيانات الحقيقية حساسة أو صعبة، استخدم Sandbox تمر بالقرارات نفسها وتنتهي بـHandoff صريح.

اجعل التخطي آمنًا. قد يفهم المستخدم المجال مسبقًا، أو يحتاج دعوة زميل قبل المتابعة. يجب أن يحفظ Skip إمكانية العودة، لا أن يحذف المساعدة إلى الأبد. وإذا كانت الجولة ضرورية لتفاعل جديد فعلًا، فلتكن قصيرة واختيارية ومرتبطة بتجربة داخل الواجهة.

اجعل التقدم دائمًا وقابلًا للتفسير

Onboarding متعددة الخطوات Product Flow لها State، وليست Animation في الواجهة. خزّن كل مهمة مفيدة بحالة `not_started` أو`in_progress` أو`blocked` أو`complete` أو`needs_review`، مع الدليل الذي يبرر الحالة. لا تستنتج الإكمال من زيارة الصفحة. خطوة الاتصال تكتمل عندما يجري التحقق من البيانات وتنجح أول قراءة، لا عندما يفتح المستخدم Form.

احفظ بعد كل قرار صالح. وعند العودة، اعرض المكتمل والمتبقي وسبب التعطيل وما يمكن عمله الآن. توصي إرشادات Task List في GOV.UK باستخدام القائمة عندما يثبت البحث أن المستخدم يحتاج التحكم في خدمة طويلة ومعقدة أو إنجازها عبر جلسات أو اختيار ترتيبها. كما تطلب تبسيط الخدمة قبل إضافة Task List؛ قائمة من ست خطوات ليست أفضل تلقائيًا من حذف أربع منها.

اجعل عمل النظام مرئيًا. إذا استغرق Import عشر دقائق، فميّز بين accepted وprocessing وfailed وready. اسمح للمستخدم بالخروج بأمان وأبلغه عندما تصبح الخطوة التالية ممكنة. لا تحرّك Progress Bar وهمية بينما لا يملك Backend حالة Job دائمة.

ضع Version للرحلة. عندما تتغير متطلبات Onboarding، لا تعِد مستخدمًا قديمًا إلى الخلف بسبب مهمة اختيارية جديدة. خزّن إصدار العقد الذي بدأ به، ورحّل State عمدًا، وحافظ على النتيجة التي حققها.

ضمّن الوصول والتعافي في المسار

قد تجعل Spotlight Modal التي تنقل Focus عشوائيًا الجولة غير قابلة للاستخدام بلوحة المفاتيح أوالتقنيات المساعدة. تطلب إرشادات Focus Order في W3C أن يحافظ الترتيب المتسلسل للتركيز على المعنى وقابلية التشغيل. اجعل ترتيب DOM متوافقًا مع المهمة المرئية، ولا تنقل Focus إلا بعد تغيير بدأه المستخدم، ووفّر خروجًا من Overlays المؤقتة.

لا تطلب المعلومات نفسها مرتين. تغطي إرشادات Redundant Entry في W3C المعلومات التي قدمها المستخدم في العملية نفسها: املأها تلقائيًا أو اسمح له باختيارها، إلا عندما تكون الإعادة ضرورية أو مطلوبة للأمان. يهم هذا عندما يمر Onboarding بإعداد المؤسسة والفوترة والملف الشخصي.

يجب أن يحافظ Validation على القيم المدخلة، ويضع رسالة محددة بجانب الحقل مع Summary عند الحاجة. وبعد Submit انقل Focus إلى موضع خطأ مفهوم من دون إخفاء السياق الأصلي. فشل الشبكة لا يجب أن يعيد الرحلة من البداية؛ احتفظ Draft محليًا عندما يناسب، وثبّت الحقول التي قبلها Server، وبيّن بالضبط أي فعل يحتاج Retry.

احترم Zoom وReduced Motion وإعلانات Status لقارئات الشاشة وحجم Touch Targets. يمكن للAnimation الزخرفية دعم الإحساس بالتقدم، لكن الإكمال لا يعتمد على مشاهدتها. اختبر مسار أول قيمة كاملًا بلوحة المفاتيح وشبكة بطيئة وجلسة منتهية وSubmit مكرر وشاشة صغيرة، لا Happy Path على Desktop فقط.

قِس انتقالات الحالة لا مشاهدات الصفحات

سجّل الرحلة كـState Transitions. تشمل الأحداث المفيدة: اختيار الهدف، غياب شرط مسبق، بدء المهمة الأولى، حفظ أول Input صالح، فتح المساعدة، فشل Validation، الاستكمال بعد المغادرة، إنشاء المخرج المفيد، مشاهدة المخرج، التحقق من النتيجة واختيار الخطوة التالية. أضف إصدار Flow والهدف، ولا تنسخ قيم الحقول الحساسة إلى Analytics.

قس Median وتوزيع Time to First Value، لا Completion Rate فقط. افصل العمل النشط عن انتظار النظام أو شخص آخر. وتابع الخروج حسب الشرط المفقود ونوع الخطأ والخطوة. الزمن الأقصر ليس أفضل تلقائيًا إذا كان المستخدمون يتراجعون عن النتيجة أو يتواصلون مع الدعم. اربط السرعة بجودة المخرج وإعادة الاستخدام خلال سبعة أيام ونجاح الفعل التالي وإشارات الدعم.

قسّم Funnel حسب Starting State. الحساب الفارغ، والزميل المدعو، والعميل المهاجر، والعائد بعد محاولة ناقصة ليست حالات واحدة. قارن معدل النتائج المتحققة، لا معدل إغلاق الجولة.

استخدم الدليل النوعي بجانب Events. راقب مستخدمين ممثلين وهم يحاولون المهمة بعقليتهم الخاصة. اسألهم ماذا يتوقعون قبل Click مؤثرة، وماذا يعتقدون أنه حدث بعدها. سوء الفهم الواثق قد يبدو Funnel نظيفة.

اختبر المسار قبل تلميعه

ابنِ Prototype لعقد أول قيمة بأصغر بيانات واستجابة نظام واقعية. اختبر فهم الوعد الأول، وهل يختار المستخدم الطريق الصحيح، وأين يتردد، وهل يلاحظ حفظ التقدم، وهل يستطيع شرح الحالة الناتجة. افعل ذلك قبل إضافة Illustrations وBadges واحتفال.

اختبر نسخًا تحذف خطوات، لا نسخًا تعيد تصميمها فقط. قارن الجولة بالمساعدة السياقية، وWorkspace فارغة بـEmpty State موجهة، وأسئلة Profile المطلوبة بالمؤجلة، وتسلسلًا ثابتًا بـTask List قابلة للاستكمال. حدّد القرار المتوقع وGuardrail قبل التجربة.

أدخل جلسات الفشل في البحث. أعطِ المشارك Invitation منتهية أوملفًا فيه صف غير صالح أوImport بطيئة أوصلاحية غير كافية. تجربة التعافي جزء من Onboarding لأن الفشل المبكر يحدد هل يكسب المنتج الثقة.

قبل الإطلاق تحقق من أربعة حدود: تبقى State بعد Refresh وإعادة Authentication، وتعد Analytics النتيجة المتحققة مرة واحدة، ويعمل الوصول من دون الجولة المرئية، ويستطيع المستخدم المغادرة من دون فقد عمل صالح.

القرار العملي

Product Tour محتوى فوق الواجهة، أما Onboarding فهي انتقال في حالة المنتج. الفرق مهم لأن الناس لا تتبنى المنتج برؤية Controls، بل عندما يساعدها على صنع نتيجة تفهمها وتستخدمها.

عرّف النتيجة، واحذف الأسئلة التي لا تغيّر الطريق، وابدأ بمهمة حقيقية واحدة، وأظهر المساعدة داخل السياق، واحفظ كل قرار مفيد، وتحقق من المخرج قبل اعتبار Onboarding مكتملة. ثم قِس هل عاد المستخدم ليستعمل القيمة، لا هل ضغط «التالي».

أفضل Onboarding تبدو غالبًا أصغر من المنتج. تعرض القرارات المطلوبة الآن فقط، وتثبت وعدًا واحدًا، وتترك المستخدم في حالة موثوقة مع خطوة تالية واضحة.

إعداد: Noor Yasser