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