ماذا يجب أن يقوله تطبيقك عندما يتعطل: كتابة رسائل خطأ يفهمها الناس فعلًا

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

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

لماذا تفشل التطبيقات بصمت أو تُظهر رسائل خطأ مخيفة؟

تتعطل التطبيقات بشكل سيئ بإحدى طريقتين: إما أن تصمت تمامًا عند فشل شيء ما، أو تُظهر خطأً تقنيًا لا يستطيع شخص عادي قراءته. كلتا الحالتين تتركان المستخدم يخمّن، والتخمين هو ما يجعل الناس يستسلمون.

الفشل الصامت. مايا، مصورة مستقلة، بنت نموذج حجز لعملها في التصوير الفوتوغرافي. ضغطت إحدى العميلات على “تأكيد الحجز”، ارتجف الزر، ثم… لا شيء. لا تأكيد، لا خطأ، لا مؤشر تحميل. هل نجح الأمر؟ لم تكن العميلة متأكدة، فحجزت مرة أخرى. أصبح لدى مايا الآن حجزان لنفس الموعد وعميلة مرتبكة. التطبيق لم يتعطل — الحفظ فشل فقط، والتطبيق لم يقل شيئًا، فلم يكن لدى الشخص الذي أمامه أي فكرة عمّا حدث فعلًا.

خطأ تقني مخيف. الفشل الآخر أعلى صوتًا وبطريقة ما أسوأ. متطوعة تدير حملة تبرعات مجتمعية حاولت رفع جدول بيانات فظهر لها مربع أحمر يقول Error 500: Internal Server Error. فهمت الأمر على أنه “لقد أفسدتُ شيئًا ما”. لم تحاول مجددًا، ولم ترسل بريدًا إلكترونيًا طلبًا للمساعدة، بل أغلقت التبويب فقط — لأن الرسالة جعلت المشكلة تبدو وكأنها خطؤها، وأن لمسها مجددًا قد يكون غير آمن.

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

ما الذي يجعل رسالة الخطأ جيدة؟

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

1. تقول ما الذي حدث — “لم نتمكن من حفظ حجزك”، لا الصمت ولا 500.
2. تقول من المسؤول — عادة ما تكون الإجابة الصادقة “نحن”، وقول ذلك يريح الناس.
3. تقول ما الذي يجب فعله بعد ذلك — “حاول مرة أخرى بعد قليل” أو “تحقق من اتصالك بالإنترنت وأعد المحاولة”.
4. لا تفقد عملهم — أيًا كان ما كتبوه، يبقى موجودًا في النموذج عندما تظهر الرسالة.

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

• ❌ (لا شيء يحدث) ← ✅ “لم نتمكن من حفظ ذلك الآن. تفاصيلك ما زالت هنا — اضغط تأكيد للمحاولة مجددًا.”
• ❌ Error 500: Internal Server Error ← ✅ “حدث خطأ من جانبنا أثناء رفع هذا الملف. الأمر ليس بسببك. جرّب مرة أخرى بعد دقيقة.”
• ❌ Invalid input ← ✅ “رقم الهاتف هذا لا يبدو صحيحًا — يجب أن يتكون من 10 أرقام، مثل 555-123-4567.”

لاحظ أن المثال الأخير يشير إلى الحقل المحدد ويُظهر كيف يبدو الشكل الصحيح. “إدخال غير صالح” تجعل الشخص يبحث؛ “رقم الهاتف هذا يجب أن يتكون من 10 أرقام” تخبره بالضبط بما يجب تغييره.

ما هي أخطاء التطبيق التي يجب إصلاحها أولًا؟

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

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

“لا يمكننا استخدام ما كتبته” (التحقق من الصحة). هذا ليس خطأً حقيقيًا — إنه سوء فهم. التقطه في اللحظة التي يغادر فيها الحقل، أشر إلى الحقل بالتحديد، وأظهر مثالًا على التنسيق الصحيح. لا تنتظر حتى يضغط “إرسال” لتكشف عن جدار أحمر.

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

ثلاث عادات تساعد بهدوء

هناك بعض الأمور التي تميّز التطبيقات التي تتعامل مع الفشل بأناقة عن تلك التي لا تفعل:

• لا تُظهر أبدًا كود خطأ خام كنص الرسالة الكامل. يمكن للكود أن يظهر بخط صغير أسفل الرسالة لأغراض الدعم، لكن العنوان الذي يقرأه الإنسان يجب أن يكون جملة، لا ERR_CONN_RESET.
• لا تلم المستخدم أبدًا. “لقد أدخلت شيئًا خاطئًا” تجرح؛ “هذا التاريخ يبدو أنه في الماضي — هل قصدت الشهر القادم؟” تساعد. المعلومة نفسها، شعور مختلف تمامًا.
• احتفظ دائمًا بما أدخله. إذا أعاد التطبيق التحميل أو فشل الحفظ وأصبح النموذج فارغًا، فقد حوّلت عثرة صغيرة إلى عشر دقائق من إعادة الكتابة. الناس يسامحون فشل الحفظ. لكنهم لا يسامحون القيام بالعمل مرتين.

كيف تجعل أداة البناء بالذكاء الاصطناعي تكتب رسائل خطأ أفضل؟

يمكنك الحصول على معظم هذا في طلب واحد — الصق شيئًا كالنص التالي وستطبّق أداة البناء بالذكاء الاصطناعي لديك قواعد اللغة البسيطة أعلاه على تطبيقك بالكامل.

“عندما يفشل الحفظ أو الرفع، لا تفشل بصمت ولا تُظهر كود خطأ تقني. أظهر رسالة قصيرة وودودة بلغة بسيطة تقول ما الذي حدث، وتقول إنه لا بأس بالمحاولة مجددًا، وتحتفظ بأي شيء كتبه المستخدم بالفعل. بالنسبة لحقول النماذج، تحقق من الصحة عندما يغادر المستخدم كل حقل وأظهر رسالة محددة مع مثال على التنسيق الصحيح.”

ثم اطلب منها أن تشرح لك ما يحدث في ثلاث حالات: الإنترنت مقطوع، حقل مطلوب فارغ، والخادم بطيء. إذا كانت الإجابة في أي منها “لا يظهر شيء” أو “يظهر الخطأ الخام”، فهذا هو إصلاحك التالي.

كيف تختبر رسائل الخطأ في تطبيقك؟

أطفئ الواي فاي، افتح تطبيقك، وحاول القيام بالمهمة الرئيسية — هذا هو الاختبار بأكمله، ويستغرق دقيقتين.

احجز الموعد، احفظ الملاحظة، ارفع الملف. راقب ما يقوله. هل أخبرك بشيء يفهمه شخص عادي؟ هل فقد ما كتبته؟ الآن أعد تشغيل الواي فاي واكتب عمدًا محتوى عشوائيًا في أحد الحقول. نفس الأسئلة.

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