مشروع: تصميم نموذج أولي لتدفق شاشة رئيسية
مشروع: تصميم نموذج أولي لتدفق شاشة رئيسية
كل ما تعلمناه في هذه الدورة بنى الأساس لهذه اللحظة. أنت تعرف الآن لماذا تُبنى النماذج الأولية، وكيف تختار مستوى الدقة المناسب، وكيف تبدو الهياكل الشبكية، وكيف تُقيّمها مع المستخدمين الحقيقيين. الآن تطبّق كل ذلك عملياً. يرشدك هذا الدرس خلال مشروع متكامل من البداية إلى النهاية: اختيار تدفق حرج، ورسم هيكل شبكي لكل شاشة، وتحديد متطلبات واجهة المستخدم، وإنتاج مُخرَج يمكن لفريق التطوير العمل به فعلاً.
السيناريو المستخدم طوال هذا الدرس هو بوابة إرسال للوجستية — تطبيق ويب يستخدمه منسوبو التوزيع في شركة شحن لتخصيص السائقين لأوامر التسليم. هذا سير عمل عالي التكرار وضيق الوقت؛ الأخطاء في الواجهة تُفضي مباشرةً إلى تسليمات فائتة وشكاوى العملاء. هذا بالضبط النوع من التدفقات التي يُثبت فيها بناء النماذج الأولية جدارته.
الخطوة الأولى — تحديد التدفق الحرج
ليس كل تدفق يستحق نموذجاً أولياً متكاملاً. أولِ الأهمية للتدفقات ذات التكرار العالي (تُستخدم مرات عديدة يومياً)، أو المخاطر العالية (للأخطاء عواقب جسيمة)، أو الخلاف العالي (يختلف أصحاب المصلحة حول طريقة عملها). في البوابة اللوجستية، يحصل تدفق "تخصيص سائق لأمر" على نقاط عالية في الجوانب الثلاثة. يستخدمه كل منسق عشرات المرات في الوردية؛ التخصيص الخاطئ يُضيّع رحلة كاملة؛ وللإدارة التشغيلية ومنسوبي التوزيع رؤى مختلفة حول كيفية عرض معلومات الأمر.
حدِّد حدود التدفق بدقة قبل رسم أي مربع:
- نقطة الدخول: يفتح المنسق قائمة الأوامر غير المُخصَّصة.
- نهاية المسار الرئيسي: يُخصَّص السائق؛ يتحدث حالة الأمر إلى "تم الإرسال"؛ يرى المنسق إشعار تأكيد.
- المسارات البديلة: لا يوجد سائق متاح؛ السائق المختار فوق الطاقة؛ المنسق يلغي في منتصف التدفق.
- خارج النطاق لهذا النموذج: إنشاء أمر جديد، تعديل ملف السائق، عرض تتبع GPS.
الخطوة الثانية — رسم الهيكل الشبكي لكل شاشة في التدفق
يُجسِّد الهيكل الشبكي البنية وتراتبية المحتوى، لا الألوان أو التنسيق. استخدم تعبئات رمادية ونصوصاً بديلة وعناصر تحكم مُسمَّاة. لكل شاشة اسأل نفسك: ما المعلومات التي يحتاج المستخدم لرؤيتها لاتخاذ قرار، وما الإجراءات المتاحة له؟ الإجابات تصبح تخطيطك.
يتضمن تدفق "تخصيص السائق" ثلاث شاشات: قائمة الأوامر غير المُخصَّصة، ولوحة اختيار السائق (نافذة منبثقة أو درج جانبي)، وتأكيد التخصيص. يوضح الهيكل الشبكي أدناه الشاشات الثلاث في عرض مركّب.
الخطوة الثالثة — تحديد متطلبات واجهة المستخدم بالتوضيح
الهيكل الشبكي بلا توضيحات مجرد صورة؛ أما مع التوضيحات فيصبح مواصفة متطلبات. لكل شاشة ولكل عنصر تحكم مهم، اكتب متطلب واجهة مستخدم مُرقَّماً بلغة واضحة. تغذي هذه المتطلبات مباشرةً قسم واجهة المستخدم في وثيقة SRS ومعايير قبول المطورين.
مثال على مجموعة التوضيحات للوحة اختيار السائق (الشاشة 2):
UI-REQ-NNN) يتطابق مع المعرِّفات في وثيقة SRS. هذا يجعل التتبع من توضيح النموذج الأولي إلى حالة الاختبار أمراً بسيطاً.
الخطوة الرابعة — توثيق المسارات البديلة
المسار الرئيسي نصف القصة فقط. لكل مسار بديل حددته في الخطوة الأولى، أضف شاشة أو حالة للهيكل الشبكي ومتطلبات واجهة مستخدم مقابلة. في البوابة اللوجستية، يهم اثنان من المسارات البديلة:
- لا يوجد سائق متاح: تُظهر الشاشة 2 قائمة فارغة مع رسالة مضمَّنة — "لا يوجد سائق متاح لهذا الطريق في الوقت الحالي. أعد المحاولة خلال 5 دقائق أو قم بالتصعيد للعمليات." هيكل الحالة الفارغة بنفس أهمية الحالة المملوءة.
- المنسق يلغي في منتصف التدفق: زر "إلغاء" في الشاشة 2 يُعيد الأمر للقائمة دون أي تغيير في الحالة. يجب أن يحدد UI-REQ-017 أنه لا يُحفظ أي تخصيص جزئي.
الخطوة الخامسة — مصفوفة تتبع متطلبات واجهة المستخدم
يجب أن يرتبط كل متطلب واجهة مستخدم مشتق من النموذج الأولي بمتطلب وظيفي في وثيقة SRS، ويتقدم إلى حالة اختبار واحدة على الأقل. يوضح الجدول أدناه شريحة نموذجية.
الخطوة السادسة — العرض والتكرار والموافقة
أجرِ جلسة مراجعة منظمة مع أصحاب المصلحة. اسر معهم خلال كل شاشة في التدفق باستخدام بروتوكول التفكير بصوت عالٍ: اطلب منهم سرد ما سيفعلونه في كل خطوة وما يتوقعون حدوثه. لا توجِّههم — إذا ترددوا عند لوحة اختيار السائق، فذلك التردد بيانات. سجِّل كل تعليق مقابل رقم الشاشة ومعرِّف UI-REQ.
بعد الجلسة، صنِّف الملاحظات في ثلاث مجموعات:
- حرجة: النموذج الأولي لا يدعم المهمة. راجع الهيكل الشبكي وأعد الاختبار.
- مهمة: التصميم مربك أو غير فعّال. حدِّث الهيكل الشبكي ومتطلب واجهة المستخدم المقابل.
- ثانوية: تفضيلات الصياغة والتسميات والاقتراحات الجمالية. سجِّلها لمرحلة التصميم المرئي؛ لا تعد بناء النموذج الأولي من أجلها.
كرِّر حتى لا تبقى مشكلات حرجة أو مهمة. ثم احصل على موافقة رسمية: سجل موافقة مؤرَّخ مُرفق بوثيقة النموذج الأولي، يسرد أسماء أصحاب المصلحة وأدوارهم وأي عناصر مؤجَّلة. هذه الموافقة هي تفويضك لتسليم متطلبات واجهة المستخدم لفريق التطوير.
المُخرَج الكامل للمحلل
في نهاية هذا المشروع، تتضمن حزمة المُخرَجات: (1) ملف الهيكل الشبكي المُوضَّح (PDF أو رابط أداة مشتركة)، (2) قائمة متطلبات واجهة المستخدم المُرقَّمة، (3) مصفوفة التتبع التي تربط كل UI-REQ بمتطلب مصدر وحالة اختبار مستهدفة، (4) ملاحظات جلسات أصحاب المصلحة، و(5) سجل الموافقة الموقَّع. تحوِّل هذه الوثائق مجتمعةً المفهوم إلى مواصفة يمكن لفريق التطوير تنفيذها، ولفريق ضمان الجودة التحقق منها، ولمدير المشروع متابعتها. ذلك هو حرفة المحلل، مكتملةً.