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