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