النماذج الأولية ومتطلبات واجهة المستخدم

مبادئ قابلية الاستخدام للمحللين

18 دقيقة الدرس 6 من 10

مبادئ قابلية الاستخدام للمحللين

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

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

الاتساق

يعني الاتساق أن الأشياء المتشابهة تبدو وتتصرف بنفس الطريقة في كل مكان داخل النظام. وهو نوعان:

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

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

إجراء المحلل: أضف قسم المفردات المرئية إلى متطلبات واجهة المستخدم. اذكر المصطلحات التي يجب استخدامها باتساق — مثلاً، دائماً "إلغاء" وليس "تراجع" أو "تجاهل"، ودائماً "إرسال" لتقديم النماذج النهائية. ارتبط كل بند بمعرّف المتطلب المقابل حتى يتمكن الفريق التطويري من تتبع صياغة الواجهة إلى مصدرها.
Consistency: Consistent vs Inconsistent UI Patterns Consistent Inconsistent Booking Screen Shipment ID Destination Confirm Cancel Invoice Screen Invoice No. Amount Confirm Cancel Same label, same color, same position on every screen → zero hesitation Booking Screen Shipment ID Destination Confirm Abort Invoice Screen Invoice No. Amount Submit Discard Different labels, different colors — user must re-learn each screen Every variation forces the user to stop and think. Consistency removes that cognitive tax.
اتساق مقابل عدم اتساق تسميات الأزرار وألوانها عبر شاشتين في بوابة لوجستية.

التغذية الراجعة

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

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

  • رؤية الحالة: أخبر المستخدم دائماً بموضعه في عملية متعددة الخطوات (مؤشرات الخطوات، مسار التنقل).
  • تأكيد الإجراء: رسائل النجاح، ولافتات الأخطاء، والتحقق المضمّن كلها تُعدّ تغذية راجعة.
  • وقت الاستجابة: إذا استغرقت عملية ما أكثر من ثانية واحدة، اعرض مؤشر تقدم. وإذا استغرقت أكثر من عشر ثوانٍ، اعرض وقتاً تقديرياً للإتمام.
نصيحة صياغة المتطلبات: اكتب متطلبات التغذية الراجعة كمعايير قبول قابلة للاختبار. مثال: "عند إرسال المستخدم لطلب الموعد، يجب أن يصبح زر الإرسال معطلاً خلال 300 ملي ثانية وأن يعرض النص 'جارٍ الحجز...'. عند نجاح الخادم، يظهر شريط أخضر بالنص 'تم تأكيد الموعد — الرقم المرجعي: #[ID]'." هذا يمنح المطورين والمختبرين معياراً واضحاً وقابلاً للتحقق.

منع الأخطاء

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

تقنيات يمكن للمحلل تحديدها في المتطلبات:

  1. المدخلات المقيدة: استخدم منتقي التواريخ بدلاً من حقول النص الحر. استخدم القوائم المنسدلة حيثما تكون القيم الصالحة محدودة.
  2. مربعات حوار التأكيد للإجراءات الحساسة: يجب أن يستلزم حذف طلب، أو إلغاء شحنة، أو أرشفة سجل مريض تأكيداً صريحاً.
  3. التحقق المضمّن: تحقق من أخطاء التنسيق (البريد الإلكتروني، الهاتف، الرمز البريدي) أثناء الكتابة لا بعد إرسال النموذج.
  4. القيم الافتراضية الذكية: امزج البيانات المعروفة مسبقاً (عنوان المستخدم المسجل، تاريخ اليوم كبداية للتقرير) للتقليل من أخطاء الإدخال.
إرهاق التأكيد المفرط: مربعات حوار التأكيد فعّالة لكنها تُستخدم بإفراط. إذا أطلق كل إجراء رسالة "هل أنت متأكد؟"، سيبدأ المستخدمون بالنقر عليها بشكل انعكاسي — مما يُفسد الغرض منها. احتفظ بمربعات التأكيد للإجراءات التي لا يمكن التراجع عنها أو ذات العواقب الجسيمة (حذف البيانات، المعاملات المالية).

التعرف بدلاً من التذكر

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

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

تطبيقات هذا المبدأ على مستوى المحلل:

  • اعرض تلميحات الحقل وأمثلته (مثال: john@example.com) داخل عناصر الإدخال.
  • أبقِ السياق مرئياً خلال المعالجات متعددة الخطوات — اعرض لوحة ملخص بما أدخله المستخدم في الخطوات السابقة.
  • استخدم الأيقونات مع التسميات (لا الأيقونات وحدها) إلا إذا كانت الأيقونة عالمية فعلاً (بيت للصفحة الرئيسية، مكبّرة للبحث).
  • وفّر العناصر المستخدمة مؤخراً، وعمليات البحث المحفوظة، والإكمال التلقائي للتخلص من الحاجة إلى إعادة إدخال القيم المتكررة.
Recognition Over Recall: Multi-Step Wizard with Summary Panel Multi-Step Wizard: Recognition vs Recall 1 Patient Info 2 Appointment 3 Confirm Recall Design (Bad) Step 2: Choose Appointment Select date Select doctor No patient context visible User must remember DOB, insurance from Step 1 to verify eligibility Recognition Design (Good) Step 2: Choose Appointment Step 1 Summary Sara Ahmed DOB: 1985-04-12 Insurance: A-Type Eligible ✓ Select date Select doctor Context always visible — nothing to remember The summary panel on the right eliminates the need to remember data entered in a previous step.
معالج حجز موعد متعدد الخطوات: تصميم التعرف يُبقي بيانات الخطوة الأولى مرئية خلال الخطوة الثانية، مما يُزيل عبء التذكر.

تطبيق المبادئ الأربعة معاً

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

عند مراجعة نموذج أولي بوصفك محللاً، مرّ على كل شاشة واسأل:

  1. هل يبدو كل إجراء مكافئ ويتصرف بنفس الطريقة في كل مكان؟ (الاتساق)
  2. هل يعرف المستخدم فوراً بعد كل إجراء ما الذي حدث؟ (التغذية الراجعة)
  3. هل يمكن للمستخدم إطلاق إجراء لا رجعة فيه دون تحذير واضح؟ (منع الأخطاء)
  4. هل ثمة شيء يجب على المستخدم حفظه من شاشة سابقة لإتمام هذه الشاشة؟ (التعرف بدلاً من التذكر)

وثّق كل فجوة كنتيجة لقابلية الاستخدام مع أولوية (حرجة / رئيسية / ثانوية) وربطها بمعرّف الشاشة المقابل في نموذجك الأولي. هذا يحوّل مراجعة التصميم الذاتية إلى أثر قابل للتتبع والتنفيذ.

تلميح أدواتي: عند إجراء تقييم إرشادي على نموذج أولي في Figma أو Balsamiq، أنشئ جدولاً بسيطاً: اسم الشاشة، والإرشاد المنتهَك، والوصف، والشدة، والإصلاح المقترح. شارك القائمة المرقمة مع فريقي التصميم والتطوير — فهي تندمج بشكل طبيعي مع مصفوفة تتبع المتطلبات.