رسائل الخطأ في الواجهات: وضّح المشكلة وخطوة التعافي

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

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

حدد الحالة قبل كتابة العبارة

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

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

سمّ ما يحتاج التعديل

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

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

اقترح فعلًا يستطيع المستخدم تنفيذه

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

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

احتفظ بما يساعد على التصحيح

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

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

اجعل الرسالة قابلة للوصول

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

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

لا تتهم المستخدم بما لا تعرفه

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

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

عبّر بصدق عن حالة العملية

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

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

راجع مسار الخطأ كاملًا

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

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

عن الكاتب

فريق جادالحق

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

تنبيه: المحتوى المالي في الموقع للتثقيف العام فقط، وليس نصيحة استثمارية أو مالية شخصية؛ استشر مختصًا مرخّصًا قبل أي قرار يخص أموالك.