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