الشاشة الفارغة وشاشة التحميل ورسالة الخطأ: التفاصيل اللي تحدد انطباع المستخدم

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

الحالة الفارغة: فرصة مو فراغ

الشاشة الفارغة لازم تجاوب ثلاثة أسئلة: وش هذا المكان؟ ليش فاضي؟ ووش أسوي الحين؟ بدل «لا توجد بيانات»، اكتب مثلاً: «ما عندك طلبات لين الحين. أول طلب ياخذ منك دقيقة» مع زر «اطلب الآن». جملة، وزر واحد، ورسمة بسيطة لو تبي.

• فراغ أول استخدام: وجّه لأول إجراء.
• فراغ نتيجة بحث: اقترح تعديل الكلمة أو إزالة الفلاتر.
• فراغ بعد إنجاز: مثل «خلصت كل المهام» — هنا احتفل بدل ما توجّه.

التحميل: قلّل الإحساس بالانتظار

• استخدم هيكل تحميل (Skeleton) بنفس شكل المحتوى القادم بدل دائرة في منتصف الشاشة.
• اعرض الأجزاء الجاهزة أولاً ولا تنتظر كل البيانات.
• لو العملية طويلة (رفع ملف، دفع)، أظهر تقدماً أو خطوات، مو دائرة صامتة.
• عطّل الزر أثناء الإرسال وغيّر نصه إلى «جاري الإرسال…» عشان ما يُضغط مرتين.
• لو التحميل سريع جداً، لا تُظهر المؤشر أصلاً؛ الوميض السريع مزعج.

رسالة الخطأ: وش صار، ووش الحل

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

• أخطاء الحقول: الرسالة تحت الحقل نفسه، مو في أعلى الصفحة.
• لا تمسح بيانات النموذج لما يصير خطأ.
• فرّق بين خطأ من المستخدم (رقم ناقص) وخطأ من النظام (الخادم متوقف).
• في الأخطاء الحرجة، اعرض طريقة تواصل مباشرة مع الدعم.

حالات ينساها الجميع

• بدون إنترنت: وش يقدر يشوف المستخدم من المحفوظ؟
• نص طويل جداً: اسم بخمس كلمات، أو عنوان يكسر البطاقة.
• صلاحيات مرفوضة: رفض الموقع أو الكاميرا أو الإشعارات.
• بيانات جزئية: منتج بدون صورة، أو مستخدم بدون اسم.

قائمة فحص لكل شاشة

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

رسائل النجاح أيضاً تحتاج تصميماً

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

نبرة النصوص في هذي الحالات

• اكتب بلغة المستخدم، مو بلغة قاعدة البيانات: «طلباتك» بدل «السجلات».
• لا تستخدم المزاح في الأخطاء الحرجة مثل فشل الدفع؛ الوضوح أولاً.
• تحمّل المسؤولية لما يكون الخطأ من النظام: «صار عندنا خلل» بدل «حدث خطأ».
• خلّ النصوص قصيرة؛ المستخدم في لحظة إحباط ما يقرأ فقرات.
• وحّد المصطلحات: لا تسمّيها «طلب» في شاشة و«حجز» في شاشة ثانية.

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

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

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