كيفية تقليل احتكاك UX في تطوير المنتج الآمن

في تطوير المنتج ، غالبًا ما ينتهي الأمر بالمظهر الذي يحظى بكل الاهتمام. تعد واجهة المستخدم الممتعة أمرًا مهمًا ، ولكن UX هو ما يصنع منتجك أو يكسره.

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

ومع ذلك ، لا يمكن أن يأتي الاحتكاك المنخفض على حساب الأمن للمؤسسات التي تحتفظ ببيانات العملاء الحساسة ، مثل المؤسسات المالية وشركات التأمين.

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

المعركة القديمة بين الأمن والراحة

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

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

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

احتيال أقل لا يعني دائمًا ربحًا أكبر

في البرامج والتطبيقات الأكثر أمانًا ، هناك مجموعتان من العملاء يجب على مديري المنتجات خدمتهم:

1. المنظمة التي تعطي الأولوية لأعلى حماية ممكنة.
2. المستخدم النهائي الذي يريد تجربة مستخدم سلسة للمنتج.

البنك ، على سبيل المثال ، يفضل الحماية بنسبة 100٪ ضد الاحتيال لأسباب عديدة ، منها:

• رضا العملاء.
• الحد من فقدان الاحتيال.
• سمعة العلامة التجارية.
• تقليل الهجمات الإلكترونية.

من ناحية أخرى ، لدى المستخدم النهائي متطلبات تنافسية: فهو يريد وصولاً سهلاً وسريعًا إلى حسابه. لن يحدث هذا إذا تم تصميم UX الخاص بالبنك لحماية 100٪ من الاحتيال.

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

لتعقيد الأمور ، قد يكون لدى المستخدمين النهائيين المختلفين عتبات مختلفة لمقدار الاحتكاك الذي سيتحملونه قبل البحث عن مزود خدمة آخر.

أغلق أهداف العميل وتكاليفه وتحمله للمخاطر

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

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

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

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

حدد البيانات التي يجب جمعها من المستخدمين النهائيين

تتحقق البرامج والتطبيقات الآمنة من:

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

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

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

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

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

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

شارك مع العملاء لفحص مؤشراتك

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

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

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

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

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

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

اجمع بياناتك

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

فكيف يعمل هذا في تطبيقات الأمان؟

• متصفحات الويب: في كل مرة ينتقل فيها المستخدم إلى موقع محمي في مستعرض ، يقوم "جامعو" JavaScript المضمّنون بجمع معلومات التعريف. يمكن أن يشمل ذلك نقاط البيانات مثل الموقع وتفاصيل الجهاز وحركات الماوس.
• التطبيقات الأصلية: تم تصميم التطبيقات الأصلية لنظام أساسي لجهاز معين ، مثل iOS أو Android. عند الوصول إلى خدمة من جهاز محمول ، تستخدم هذه التطبيقات مجموعات تطوير البرامج (SDKs) لجمع معلومات التعريف ، والتي قد تتضمن نقرات بالأصابع والتمريرات السريعة بدلاً من حركات الماوس.

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

استمر في تقليل احتكاك المستخدم النهائي

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

بالنسبة للشركات المبنية على التجارة الإلكترونية ، فإن تكاليف هذه التباطؤات واضحة للعيان. في عام 2022 ، قدر معهد Baymard أن 17٪ من حالات التخلي عن العربات التي كان من الممكن تجنبها كانت بسبب عملية دفع طويلة جدًا أو معقدة ؛ ألقى 18٪ من المشاركين باللوم على عدم الثقة في أمن معلومات بطاقات الائتمان الخاصة بهم. يقدر Baymard أن بطء تسجيل الخروج وانعدام الثقة في أمان الموقع كان من بين مجموعة من العوامل التي ساهمت في خسارة 260 مليار دولار في المبيعات عبر الولايات المتحدة والاتحاد الأوروبي. يقدم ذلك فرصة رائعة لمديري منتجات التجارة الإلكترونية لإعادة التفكير في حلول نقاط البيع الخاصة بهم. ولكن بغض النظر عن مجال عملك ، يجب أن يكون الحد من احتكاك المستخدم وضمان الثقة في حماية بياناتك ممارسة مستمرة يمكن أن تسفر عن عملاء أكثر سعادة وابتكارات تجارية كبرى.

فيما يلي مثالان على الحد من الاحتكاك الناجح في تطوير المنتج الآمن:

3DS

في أواخر التسعينيات ، تعاونت Visa و Mastercard لإنشاء بروتوكول أمان للمدفوعات الآمنة ثلاثية الأبعاد (3DS). تم إصدار البروتوكول الأصلي في عام 2001 ، حيث طلب البروتوكول الأصلي من جميع المستخدمين تسجيل بطاقاتهم باستخدام 3DS وتسجيل الدخول في كل عملية دفع باستخدام كلمة مرور مخصصة لـ 3DS. إذا لم يتمكن المستخدم من تذكر كلمة مرور 3DS الخاصة به ، فقد طُلب منه استردادها أو إعادة تعيينها قبل إتمام عملية الشراء. في إصدار لاحق ، كان لدى مصدري البطاقات خيار استبدال كلمة المرور الثابتة التي غالبًا ما يتم نسيانها بكلمة مرور ديناميكية لمرة واحدة (OTP). ومع ذلك ، استمرت خطوة تسجيل الدخول الإضافية في إعاقة عملية السداد.

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

اوبر

يعد برنامج 3DS 2.0 مثالاً على تقليل احتكاك المنتج من خلال التكرار. ولكن يمكنك أيضًا تقليل الاحتكاك على مستوى الصناعة من خلال تقديم منتجات تخريبية.

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

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

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

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

أفضل صيانة هي جريمة جيدة

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

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

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