جمع متطلبات واجهة المستخدم

جمع متطلبات واجهة المستخدم

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

ما هي متطلبات واجهة المستخدم؟

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

تقع متطلبات واجهة المستخدم عند تقاطع ثلاثة اهتمامات:

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

عملية جمع متطلبات واجهة المستخدم

جمع متطلبات الواجهة ليس ورشة عمل تُنجز مرة واحدة، بل هو دورة منظمة من الاستكشاف والتوثيق والتحقق. يوضح الرسم البياني أدناه دورة المراحل الأربع التي يتبعها المحللون.

المرحلة الأولى — الاستكشاف: تقنيات الاستخلاص

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

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

المرحلة الثانية — التنظيم: كتالوج متطلبات الواجهة

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

• المعرّف — معرّف فريد (مثل UIR-012).
• المصدر — حالة الاستخدام أو الشخصية أو قاعدة العمل التي أفرزته.
• الشاشة / المكوّن — أين ينطبق المتطلب.
• النص — شرط دقيق وقابل للاختبار.
• الأولوية — MoSCoW (يجب / ينبغي / يمكن / لن يتم).
• معيار القبول — كيف ستتحقق منه في اختبار قابلية الاستخدام أو العرض التجريبي.

التتبع: ربط متطلبات الواجهة بالأهداف التجارية

تربط مصفوفة تتبع متطلبات الواجهة كل متطلب واجهة بهدف تجاري وتُعيده للأمام إلى شاشة النموذج الأولي. هذا يضمن ألا يكون شيء مطلّيًا بالذهب (مضافًا دون حاجة حقيقية) وألا يكون شيء مفقودًا.

فئات متطلبات واجهة المستخدم

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

• التخطيط والهيكل المعلوماتي: ما المحتوى الذي يظهر على الشاشة؟ وبأي تسلسل هرمي؟ وما الذي يظل ظاهرًا مقابل ما يختبئ خلف تبويب أو نافذة منبثقة؟
• الإدخال والتحقق: أنواع الحقول، والتنسيقات، والإلزامي مقابل الاختياري، والتحقق الفوري مقابل عند الإرسال، وصياغة رسائل الخطأ.
• التغذية الراجعة وحالة النظام: دوارات التحميل، ومؤشرات التقدم، وإشعارات النجاح والفشل، وإمكانية التراجع.
• التنقل والتدفق: نقاط الدخول، والانتقالات المسموح بها، وسلوك زر الرجوع، والارتباط العميق.
• الاستجابة والمنصة: نقاط الانكسار، واللمس مقابل المؤشر، وتغيير حجم الخط، والسلوك دون اتصال.
• إمكانية الوصول: التنقل بلوحة المفاتيح، وتسميات قارئ الشاشة (aria-label)، وتباين الألوان، ومؤشرات التركيز.
• التدويل (i18n): انعكاس التخطيط للغات RTL، وتنسيقات التاريخ والأرقام، وهامش توسع النص (حوالي 40% للترجمات العربية للتسميات الإنجليزية).
• إدراك الأداء: أهداف وقت أول محتوى ذو معنى، والشاشات الهيكلية، والتحديثات التفاؤلية للواجهة.

مثال عملي: شاشة تتبع الشحنات في شركة لوجستية

تريد شركة لوجستية شاشة لتتبع الشحنات للمرسِّلين. بعد المقابلات السياقية يسجّل المحلل هذه المتطلبات:

• UIR-031 — يجب أن تعرض الشاشة ما يصل إلى 50 شحنة في آنٍ واحد دون صفحات (يجب).
• UIR-032 — يجب أن يعرض كل صف الحالة ببادج ملون: أخضر = تم التسليم، كهرماني = في الطريق، أحمر = متأخر (يجب).
• UIR-033 — يجب أن يتمكن المرسِّلون من التصفية حسب الحالة ونطاق التاريخ في أقل من نقرتين (يجب).
• UIR-034 — ينبغي أن يكون الجدول قابلًا للفرز بالنقر على أي رأس عمود (ينبغي).
• UIR-035 — يمكن أن يظهر عند تحريك الفأرة فوق صف تلميح يعرض الطابع الزمني لآخر إشارة GPS (يمكن).

التحقق من متطلبات الواجهة قبل النمذجة

قبل تسليم المتطلبات لمن يصنع النموذج الأولي، أجرِ مراجعة تحقق سريعة باستخدام قائمة SMART-UI:

• S — محدد: هل يسمّي شاشة أو تفاعلًا ملموسًا؟
• M — قابل للقياس: هل يستطيع المختبِر النجاح أو الفشل دون حكم شخصي؟
• A — متفق عليه: هل أكد مالك المنتج أو راعي العمل أولويته؟
• R — قابل للتحقيق: هل أكد فريق التطوير جدواه التقنية ضمن الميزانية؟
• T-UI — قابل للتتبع: هل هو مرتبط بحالة استخدام أو هدف تجاري في المصفوفة؟

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