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

القصص المصورة وتدفقات المستخدم

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

القصص المصورة وتدفقات المستخدم

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

القصص المصورة: سرد القصة الإنسانية

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

لنفكر في نظام حجز مواعيد عيادة طبية. قد تُظهر قصة مصورة نموذجية:

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

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

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

تدفقات المستخدم: خرائط التنقل الدقيقة

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

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

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

User Flow: Online Store Checkout Start Cart Review Items + totals Shipping Info Address form Valid address? Inline Error Msg Payment Card / wallet Payment approved? Decline Screen Order Confirmed Order # + email End Checkout Submit No Yes Submit No Yes Email sent
تدفق مستخدم لعملية الدفع في متجر إلكتروني: الشاشات (أزرق)، نقاط القرار (كهرماني)، حالات الخطأ (أحمر)، نقطة الإنهاء الناجح (أخضر).

بناء تدفق المستخدم: خطوة بخطوة

اتبع هذه العملية القابلة للتكرار عند بناء تدفق مستخدم لميزة جديدة:

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

ربط تدفقات المستخدم بالمتطلبات

تدفقات المستخدم هي جسور قابلية التتبع. يجب أن تتصل كل عقدة شاشة بمتطلب وظيفي واحد على الأقل؛ وكثيراً ما تتصل كل معينة قرار بقاعدة عمل في مستند المتطلبات. عملياً، يضيف المحللون معرّفات المتطلبات (مثل FR-14 و BR-03) مباشرةً على المخطط حتى تصبح وثيقة واحدة أداةً للتصميم وقائمة تدقيق للمراجعة في آنٍ واحد.

في شركة لوجستية تُلحق سائقين جدداً، سيتضمن تدفق المستخدم شاشات لرفع المستندات، والتحقق من الهوية، وتتبع حالة فحص الخلفية، والموافقة النهائية. يرتبط معين القرار "هل المستندات مكتملة؟" مباشرةً بـ BR-07 في وثيقة قواعد العمل. عند تغيير المتطلبات — مثلاً إضافة حقل تنظيمي جديد — يحدث المحلل التدفق، ويتتبع الأثر، ويُعلم الإطارات التخطيطية وحالات الاختبار المتأثرة في الوقت ذاته.

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

أخطاء شائعة يجب تجنبها

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

صيغة المُخرَج العملي

في مُخرَج مهني، تُدرج تدفقات المستخدم عادةً في وثيقة متطلبات واجهة المستخدم أو مواصفة متطلبات النظام جنباً إلى جنب مع الإطارات التخطيطية المقابلة. يحصل كل تدفق على معرّف فريد (مثلاً UF-01 — تدفق الدفع كضيف) وسجل إصدارات. كثيراً ما تُلحق الفرق التي تعتمد منهجيات رشيقة تدفق المستخدم مباشرةً بالملحمة أو القصة في أداة إدارة المشروع، مما يجعله متاحاً فوراً للمصممين والمطورين الذين يتناولون العمل.

سواء استخدم فريقك أدوات متخصصة كـ Figma أو Miro أو Lucidchart، أو رسومات يدوية تُصوَّر وتُضمَّن في وثيقة Word، فإن الصرامة التحليلية — المسارات الكاملة، والانتقالات المعنونة، والمتطلبات المتتبعة — هي ما يحوّل الرسم التخطيطي إلى مواصفة.