دليل مختصر لمساعدة المستخدمين على تجاوز العقبات أثناء كتابة رسائل خطأ “Error message”
لنكن صريحين، تمتلئ التطبيقات والمواقع برسائل خطأ (Error messages) سيئة ومحبطة. لكن، عندما تُصاغ هذه الرسائل باحترافية، فإنها تتحول إلى أداة رائعة؛ والسبب ببساطة أنها تساعد المستخدمين على إنجاز مهامهم دون توقف.
في عالم التقنية، لا تسير الأمور دائماً كما نخطط لها؛ فقد تتعطل الأنظمة أحياناً، وفي أحيان أخرى قد يرتكب المستخدم خطأً غير مقصود. لذلك، من الضروري جداً أن نصمم ونكتب رسائل خطأ (Error messages) واضحة، منطقية، وسهلة الوصول للجميع.
استيعاب الخطأ أولاً
حلل المشكلة قبل كتابة الحل
كيف تتوقع من المستخدم أن يفهم ما يدور خلف الكواليس أو يعرف طريقة الحل، إذا لم تكن أنت نفسك مستوعباً للمشكلة؟ قبل البدء بكتابة أي نص، تأكد من إجابتك على الأسئلة التالية:
- ماذا حدث بالضبط؟ (تحديد المشكلة).
- كيف حدث ذلك؟ (سياق الخطأ).
- كيف يمكن للمستخدم إصلاح الأمر؟ (خطوات الحل).
- من المسؤول عن الخطأ؟ هل هو خطأ مستخدم (User error) أم خطأ في النظام (System error)، أم كلاهما؟
- هل نملك صلاحية تغيير الرسالة؟ أحياناً تكون الرسالة صادرة عن نظام التشغيل (OS) ولا يمكننا التحكم بنصها.
ذي صلة: أمثلة من أشهر المواقع لكتابة تجربة مستخدم مليئة بالإبداع – الجزء الأول/ رسائل الخطأ
صياغة الرسالة
اعتمد هيكلاً أساسياً

لكي يتمكن المستخدم من إصلاح أي خلل، يجب أن يعرف أولاً أين تكمن المشكلة. أبسط هيكل يمكن اعتماده لرسائل الخطأ في النماذج (Forms) هو:
[وصف الخطأ] + [طريقة الإصلاح]
الأمر بهذه البساطة. لكن أحياناً، قد لا يتمكن النظام من تحديد موضع الخطأ بدقة؛ في هذه الحالة، نلجأ للصيغ العامة، وأفضل ما يمكننا فعله هو إرشاد المستخدم إلى الخطوات المحتملة للحل.

البساطة والإيجاز
هدفنا هو مساعدة المستخدم على تجاوز الخطأ بسرعة وبدون توتر ليكمل يومه بسلاسة.
اجعل رسالتك مختصرة ومباشرة؛ تخلص من أي حشو لا داعي له، لكن دون أن يؤثر ذلك على وضوح المعنى. احتفظ بالتفاصيل فقط إذا كانت ضرورية للحل.

ذي صلة: 7 أمثلة عن رسائل الخطأ المليئة بالإبداع من أشهر المواقع العالمية
مراعاة آداب التواصل (Etiquette)

أخطاء النظام (System error)
اعتذر للمستخدم عندما يكون الخطأ ناتجاً عن النظام. لكن كن حذراً؛ لا تبالغ في الاعتذار إذا لم يكن الخطأ من جانبكم، لأن الاعتذار في غير محله قد يبدو غير صادق، أو قد يوحي للمستخدم بأنه لم يخطئ مما يسبب له الارتباك.
- نصيحة: استخدم صيغة المبني للمعلوم (Active voice) لتحمل المسؤولية.
- مثال: قل “تعذر علينا حفظ التغييرات” بدلاً من “لم يتم حفظ التغييرات”.
أخطاء المستخدم (User error)
في حال كان الخطأ من جانب المستخدم، هناك طرق لإخباره بذلك دون إشعاره بالذنب أو توجيه أصابع الاتهام إليه. ركز دائماً على الإجراء المطلوب بدلاً من التركيز على “فشل” المستخدم.
- نصيحة: هنا قد يفيدك استخدام صيغة المبني للمجهول (Passive voice) لتلطيف الموقف.
- مثال: “تم رفض هذه البطاقة” بدلاً من “لقد أدخلت بطاقة مرفوضة”.
اختيار النبرة الصحيحة (Tone)

النبرة هي “الطريقة” التي تتحدث بها. وتعتمد نبرة رسالتك على مدى خطورة المشكلة:
- الأخطاء البسيطة: يمكن استخدام نبرة ودودة ودافئة.
- الأخطاء الحرجة: تجنب أي مزاح أو خفة، واجعل النبرة جادة ومباشرة.
تذكر دائماً: ابتعد عن المصطلحات التقنية المعقدة واللغة الآلية الجافة. استخدم لغة بيضاء ومفهومة تشعر المستخدم بأن هناك شخصاً حقيقياً يرافقه ويرشده. نحن نتحدث مع بشر في النهاية.
تجنب “الفلسفة” أو الاستظراف
أرجوك، لا تحاول أن تبدو ذكياً أو مبدعاً أكثر من اللازم في هذه اللحظة؛ فهذا ليس الوقت المناسب للمزاح أو استخدام عبارات فكاهية. المحاولات الإبداعية في رسائل الخطأ قد تجعل الرسالة غامضة، وتزيد من إحباط المستخدم بدلاً من مساعدته.
الخطوة التالية (What happens next)

موافق، إعادة التشغيل” و “حسناً، فهمت رسائل خطأ “Error message”
الأزرار والروابط في رسائل الخطأ
قد تتطلب بعض الأخطاء إضافة زر “اتخاذ إجراء” (CTA – Call To Action) أو رابطاً لإصلاح الخلل. وبناءً على طريقة عرض الرسالة، قد تحتاج أيضاً إلى زر للإغلاق أو التجاهل.
- وضح الخطوة القادمة دائماً: يجب أن تكون الأزرار والروابط واضحة ومفهومة حتى لو قُرئت وحدها. هذا الأمر ضروري جداً لمستخدمي “قارئات الشاشة” (Screen readers)، ولمن يكتفي بمسح الصفحة بصرياً بشكل سريع.
- تجنب الاكتفاء بكلمة “موافق” (Ok): موافق على ماذا؟ يجب أن يعرف المستخدم نتيجة ضغطه على الزر. كلمة “موافق” قد تعني إغلاق الرسالة أو تعني الموافقة على إجراء معين؛ لذا كن محدداً.
التوقيت والمكان (Timing and placement)
يجب أن تراعي رسالة الخطأ رحلة المستخدم بالكامل. اختيار التوقيت والمكان المناسبين يمنح المستخدم “السياق” اللازم، وتوفير هذا السياق يجعل عملية الإصلاح أسهل ما يمكن.
اسأل نفسك دائماً:
- ما الذي تسبب في ظهور الرسالة؟
- متى تظهر الرسالة؟
- أين تظهر (في أي جزء من الشاشة)؟
- هل من الواضح للمستخدم بمَ ترتبط هذه الرسالة؟
وعند الإجابة، ضع في اعتبارك كافة فئات المستخدمين؛ فقد يقودك ذلك لتساؤلات أكثر عمقاً:
- كيف نساعد جميع المستخدمين (بمختلف قدراتهم) على الوصول للحل؟
- هل يمكن أن يكون توقيت ظهور الرسالة مزعجاً أو مسبباً للتوتر للبعض؟
- كيف نربط الرسالة بالقسم المتعلق بها بصرياً (للمبصرين) وتقنياً (لضعاف البصر)؟
رسائل الخطأ “Error message” ليست عائق في طريق المستخدم، بل أدوات وُجدت لتمكينه، وطمأنته، وإرشاده نحو الحل الصحيح.
ملخص القواعد الأساسية (Key takeaways)
- استوعب المشكلة أولاً: افهم طبيعة الخطأ جيداً وكيفية إصلاحه قبل البدء بالكتابة.
- الوضوح والإيجاز: أخبر المستخدم بما حدث وكيف يتصرف بلغة بسيطة ومباشرة.
- النبرة وآداب التواصل: اختر النبرة التي تناسب حجم الخطأ، وتحمل المسؤولية بذكاء.
- أزرار إجراء واضحة: اجعل الأزرار والروابط (CTA) شارحة لذاتها وواضحة الهدف.
- السياق الشامل: راعي توقيت ومكان ظهور الرسالة لتناسب جميع فئات المستخدمين.
المقال_مترجم_بتصرف_من المصدر: Writing clearer error messages



