تجربة التسجيل OnboardingOnboarding UX

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

تبدأ رحلة التسجيل قبل أول حقل، حين يقرر العميل أن المخاطرة ببياناته تستحق النتيجة.

ليش التسجيل في تطبيق مالي أصعب من أي تطبيق ثاني؟

وهذا سؤال يسمعه كل فريق منتج من الإدارة: لماذا تطبيق التوصيل يفتح في عشرين ثانية وتطبيقنا يحتاج دقائق وفحوصاً؟

والجواب أن الاثنين يخاطران بشيء مختلف تماماً.

فأسوأ ما يحدث لتطبيق التوصيل من حساب مزيّف هو طلب وهمي وخسارة قيمة وجبة. وأسوأ ما يحدث لتطبيق مالي من حساب مزيّف أن يصير قناة لغسل أموال، فتُغلق الشركة كلها.

فالاحتكاك في التسجيل ليس سوء تصميم، بل هو المكان الذي يُدفع فيه ثمن الثقة. والسؤال الصحيح ليس «كيف أزيله؟» بل «أين أضعه؟».

وهنا تظهر المهارة الحقيقية. فبدل أن تطلب كل شيء عند الباب، اسأل: ما أقل ما أحتاجه ليرى العميل قيمة أولى؟ فقد يكفي رقم جوال ليتصفّح ويجرّب. ثم تُطلب الهوية عند أول تحويل. ثم يُطلب إثبات الدخل عند طلب حدّ أعلى.

فالعميل الذي رأى قيمة يتحمّل خطوة إضافية. والعميل الذي لم يرَ شيئاً بعد يغادر عند أول طلب مستند.

ارسم الطريق إلى أول قيمة

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

وارسم الخطوات كما يراها العميل لا كما تقسمها فرق الشركة. فقد تكون الهوية عند فريق الامتثال، وربط البنك عند الهندسة، وقبول الشروط عند القانون. ولكن العميل يرى سبع شاشات متتالية فقط. ولذلك يجب أن يملك شخص واحد الرحلة كاملة ونتيجتها.

وحدد أصغر حالة نافعة يمكن الوصول إليها بأمان. فقد يستطيع العميل استكشاف التطبيق قبل رفع الوثيقة. وقد يستطيع التاجر إعداد الكتالوج قبل اكتمال فحص الحساب. ولا تمنحه حركة مال قبل السماح، لكن لا تجعل الانتظار يمنعه من كل تقدم.

اطلب المعلومة عند الحاجة

ويعني «الكشف التدريجي» Progressive disclosure طلب المعلومة حين تصبح لازمة فعلاً. وليس معناه إخفاء المتطلبات أو تجاوز الفحص. فهو يضع رقم الهاتف عند إنشاء الحساب، والهوية قبل فتح الرصيد، ومصدر المال عند بلوغ نشاط يتطلبه.

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

واشرح سبب الطلب في جملة مرتبطة بالفعل. فقل إن الهوية لازمة قبل الاحتفاظ بالمال، وإن العنوان مطلوب لإرسال البطاقة، وإن الإقامة الضريبية تحدد التقرير النظامي. ولا تقل إن المعلومات مطلوبة لأسباب أمنية عامة، لأن العبارة لا تساعد العميل على القرار.

قس كل انتقال

ويُسمى من يبدأ الرحلة ثم يتركها «التسرّب» Drop-off. ولا يكفي قياس عدد من أكملوا وعدد من بدأوا. فقد تخسر نسبة كبيرة عند تصوير الهوية، أو عند انتظار الرمز، أو عند قراءة سعر غير متوقع. ولكل موضع علاج مختلف.

وسجل دخول الشاشة ونجاحها وفشلها ووقت إكمالها. واربط الأحداث بمعرّف رحلة لا بصورة الوثيقة ولا برقم الهوية. وافصل بين من غادر طوعاً ومن واجه خطأ تقنياً ومن ينتظر مراجعة بشرية. فجمع الحالات في رقم واحد يجعل القرار عشوائياً.

وانظر إلى الأفواج لا المتوسط وحده. فقد يتحسن التسجيل لمستخدمي iPhone ويتعطل على هاتف أندرويد قديم. وقد يكمل الموظف صاحب الراتب الثابت أسرع من صاحب العمل الحر لأن وثائقه أبسط. ويكشف الفصل أين صنع التصميم حاجزاً غير مقصود.

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

صمم الفشل مثل النجاح

وقد ترفض الشركة شخصاً لأن الوثيقة غير مقروءة، أو لأن بياناتها لا تتطابق، أو لأن سياستها لا تقبل الحالة. ولا ينبغي أن تعرض الحالات الثلاث رسالة واحدة. فالأولى تحتاج إعادة تصوير، والثانية تحتاج تصحيحاً أو مراجعة، والثالثة تحتاج تفسيراً وطريق اعتراض حيث يوجبه النظام.

واكتب الرسالة دون كشف قواعد يستطيع المحتال اختبارها. فيمكنك قول إن المعلومات لم تتطابق وطلب مستند بديل. ولا يلزمك ذكر الحد الدقيق الذي أطلق قاعدة المخاطر. ويوازن النص بين حق العميل وسلامة الضابط.

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

اجعل الرحلة قابلة للوصول

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

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

واكتب بلغة يفهمها الشخص لا فريق الامتثال. فعبارة تحققنا من هويتك أوضح من اكتملت العناية الواجبة. وعبارة لم نتمكن من قراءة تاريخ الميلاد أوضح من خطأ KYC-104. ويمكن أن يبقى الرمز في سجل الدعم دون ظهوره وحده للعميل.

رتب الامتثال داخل التجربة

ولا يعني التصميم الجيد تقليل الفحوص في كل مرة. فقد يكون طلب إثبات قوي مبكراً أرحم من السماح للعميل بإعداد كل شيء ثم رفضه. ويعتمد الموضع الصحيح على ثمن الخطوة واحتمال الرفض والقيمة التي سبقتها.

واشرك موظف العمليات في مشاهدة تسجيل حقيقي. فهو يعرف أسباب الرفض التي لا تظهر في نموذج التصميم. وأشرك فريق الدعم في صياغة الرسائل، لأنه يسمع ما يسيء الناس فهمه. وأشرك الامتثال قبل البناء كي لا يتحول النص القانوني إلى نافذة مفاجئة في النهاية.

راجع الرحلة كمنتج مالي

وابن لوحة بسيطة لكل خطوة: الداخلون، والناجحون، والفاشلون، والمنتظرون، والوقت. ثم اقرأ عينات من الحالات مع الأرقام. فقد يخبرك القياس بمكان المشكلة، لكن تسجيل جلسة منقحاً أو مكالمة دعم يشرح السبب.

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