لا يكسب المنتج الثقة لمجرد مظهره الجيد. تساعد الألوان والتصميمات الجميلة بالطبع، لكن المستخدمين يبدأون في الاسترخاء فقط عندما تصبح الخطوة التالية واضحة. وهذا هو أحد الأسباب التي تجعل فرق العمل التي تقوم ببناء بوابات عامة وأدوات التكنولوجيا المالية وغيرها من المنتجات الجادة تعمل معها مطورو البرمجيات في أوروبا الشرقية، خاصة عندما يحتاجون إلى محترفين معتادين على النماذج والفحوصات والقواعد وكل التفاصيل الصغيرة التي يمكن أن تؤدي إلى نجاح التجربة أو فشلها.
هذا مهم أكثر في المنتجات عالية الاحتكاك. تطلب بوابة الضرائب أو التطبيق المصرفي أو نموذج مطالبة التأمين أو خدمة الهجرة أو أداة القروض من الأشخاص مشاركة البيانات الشخصية وقراءة القواعد وتحميل الملفات واجتياز الشيكات وانتظار الموافقة. قد يشعر المستخدم بالاندفاع بالفعل. إذا أخفى المنتج الخطوة التالية، تبدأ الثقة بالتسرب مثل الهواء من الإطار.
في اللحظة التي يبدأ فيها المنتج بالشعور بالمخاطرة
يمكن للناس أن يسامحوا الشاشة البطيئة عندما يفهمون ما يحدث. يمكنهم انتظار المراجعة عندما يكون الجدول الزمني منطقيًا. ومع ذلك، فإنهم يصبحون غير مرتاحين عندما لا يقدم المنتج أي فكرة عما سيأتي بعد ذلك. في بوابة القطاع العام، قد يبدو هذا الشك مثل “هل تم استلام النموذج؟”، بينما في تطبيق التكنولوجيا المالية، يبدو الأمر أشبه بـ “هل الأموال آمنة؟”
يقوم الشخص بملء استمارة طويلة، ويصل إلى الشاشة النهائية، ويرى رسالة غامضة مثل “تم تقديم الطلب”. قد يكون ذلك صحيحا، لكنه ليس كافيا. هل يحتاج الشخص إلى التحقق من البريد الإلكتروني؟ هل سيتصل عامل الحالة؟ هل يمكن للمستخدم تعديل الخطأ؟ ربما يكون المنتج قد قام بالمهمة بشكل صحيح، إلا أن الشخص يغادر مع عقدة في المعدة.
بالنسبة للفرق العاملة في مجال تطوير البرمجيات في أوروبا الشرقية، لا تعد هذه التفاصيل مهامًا إضافية عندما يتعامل المنتج مع الأموال أو المزايا أو الهوية أو السجلات القانونية. هم جزء من البناء الأساسي. كلما كان المسار أكثر نظافة، قل عدد طلبات الدعم وعمليات التفتيش الفاشلة والنماذج المهجورة التي ينشئها المنتج. وبالتالي، يمكن لجملة صغيرة تظهر على الشاشة أن تغير وقت المراجعة، واحتياجات التوظيف، وثقة العملاء.
تفاصيل المنتجات العملية لا يمكن تجاهلها
تقوم المنتجات عالية الاحتكاك بتدريب الفرق على ملاحظة الحواف الخشنة التي يمكن أن تخفيها التطبيقات الأخف. قد يكون أحد التطبيقات الاجتماعية عبارة عن شاشة غامضة لأن المخاطر تبدو منخفضة. لا تحتوي طلبات القرض أو بوابة المزايا الصحية على مثل هذه الوسادة. يحتاج المستخدم إلى مسار واضح، ويحتاج الفريق إلى طريقة واضحة لمعرفة أين ينقطع هذا المسار.
- يجب أن يكون الإجراء التالي مرئيًا. بعد كل عملية حفظ أو تحميل أو شيك أو دفع، يجب أن تجيب الشاشة على السؤال التالي للمستخدم قبل أن يتشكل: “ماذا الآن؟”
- يجب أن توضح الأخطاء الإصلاح. “ملف غير صالح” لا يقول شيئًا تقريبًا. “تحميل ملف JPG أو PNG بحجم أقل من 10 ميجابايت” يحول الطريق المسدود إلى خطوة إصلاح.
- يجب أن يتم توجيه عمليات التحقق من الهوية. عندما يطلب أحد المنتجات صورة شخصية أو مسحًا ضوئيًا للمستند أو رمزًا، يجب أن يوضح السبب والوقت المطلوب وماذا يحدث بعد الفشل.
- يجب أن يتناسب الدعم مع اللحظة. لا ينبغي لرابط المساعدة أن ينقل المستخدم إلى مركز مساعدة عملاق. ويجب أن يتطابق مع الصفحة أو النموذج أو الحالة التي تسببت في المشكلة.
- يجب أن تكون الحالة واضحة. تحتاج كلمات مثل “معلق” و”مرفوض” و”موافق عليه” و”قيد المراجعة” إلى تفسيرات قصيرة لأن كل واحدة منها يمكن أن تغير خطة المستخدم لهذا اليوم.
وهذا هو المكان الذي تستطيع فيه شركات تطوير البرمجيات في أوروبا الشرقية جلب عادات عملية من الأعمال المصرفية، والاتصالات، والخدمات اللوجستية، والخدمات العامة، وغيرها من المجالات المثقلة بالقواعد. لقد رأى مقدمو الخدمة مثل N-iX كيف تؤثر اختيارات المنتجات الصغيرة على المستخدمين الحقيقيين تحت الضغط ويمكن أن تساعدك في تطوير منتج يأخذ في الاعتبار جميع هذه الجوانب.
الأخطاء والتحقق من الهوية وتدفقات الدعم
الأخطاء ليست مجرد أحداث فنية. إنها لحظات عاطفية. قد يتساءل الشخص الذي يرى خطأً أثناء تحويل الأموال عما إذا كان النقد قد تم نقله، أو ما إذا كان الحساب مغلقًا، أو ما إذا كانت المحاولة الثانية ستفرض رسومًا مرتين. تقوم أفضل رسائل الخطأ بثلاث وظائف في وقت واحد: فهي تسمي المشكلة، وتشرح ما تغير، وتظهر الخطوة التالية الأكثر أمانًا.
عمليات التحقق من الهوية تزيد من المخاطر. إنها تقع على الحدود بين الوصول والرفض، لذا يجب أن تكون واضحة دون أن تبدو مخيفة. قد يحتاج تطبيق التكنولوجيا المالية إلى قواعد مرتبطة بالاحتيال والمخاطر وفحوصات العملاء، في حين قد تحتاج البوابة العامة إلى التأكد من حصول الشخص المناسب على الخدمة المناسبة. في منتصف التحقق من الهوية، حتى تلميحًا واحدًا مفقودًا يمكن أن يجعل المنتج بأكمله أقل أمانًا.
الدعم جزء من المنتج، وليس طاقم التنظيف. عندما يتعثر شخص ما، يصبح تدفق الدعم هو التجربة الرئيسية. إذا فشل تحميل المستند، فيجب أن يحمل مسار المساعدة تلك التفاصيل. إذا كان الطلب قيد المراجعة، فيجب أن تعرض صفحة الدعم ما يمكن وما لا يمكن تغييره. علاوة على ذلك، يجب ألا تجبر الدردشة أو التذكرة أو التسليم عبر الهاتف المستخدم على تكرار كل خطوة.
وهذا هو أحد الأسباب التي تجعل مطوري البرامج من أوروبا الشرقية الذين يعملون على منتجات الخدمات المعقدة يميلون إلى تقدير شاشات الدعم بقدر اهتمامهم بالشاشات الرئيسية. لم يتم الانتهاء من البناء عندما يعمل المسار السعيد. يتم الانتهاء منه عندما يتمكن المستخدمون المفقودون من العثور على طريق العودة. نفس التفكير يظهر في تصميم القطاع العام، حيث تحتاج النماذج والقواعد والدعم إلى مقابلة الأشخاص أينما كانوا.
خاتمة
المنتج الذي يجعل الخطوة التالية غير واضحة يطلب بشكل أساسي من المستخدمين التبرع بالصبر. البعض سوف يفعل ذلك، لكن الكثيرين لن يفعلوا ذلك. سواء كنت تقوم بتطوير بوابة للقطاع العام، أو تطبيق للتكنولوجيا المالية، أو أي أداة أخرى عالية الاحتكاك، يجب تنفيذ الوضوح في النماذج والأخطاء والتحقق من الهوية والدعم من البداية.
تنمو الثقة عندما يتصرف المنتج كدليل جيد. فهو يشرح المسار، ويحذر من المطبات، ويساعد المستخدمين على التعافي، ويؤكد التقدم. ولذلك، فإن المطورين الذين يعملون على منتجات عملية ومثقلة بالقواعد يتعلمون بسرعة الاهتمام بأدق التفاصيل التي تساعد المستخدمين على التحرك بشكل أسهل عبر التطبيق. قد تبدو هذه التفاصيل متواضعة، لكنها إما أن تستقر الثقة أو تتلاشى.
يتم توفير هذا المحتوى لأغراض إعلامية فقط وليس بديلاً عن المشورة المهنية. ولم يشارك طاقم التحرير في وكالة فرانس برس في إنشاء هذا المحتوى.