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