فهم المشروع وأهداف البزنس Project Discovery & Business Goals
أول خطوة في عملية تصميم تجربة المستخدم UX مش فتح Figma ولا رسم أول شاشة، لكن فهم المشروع نفسه: المنتج بيقدم إيه، وليه المفروض المستخدم يعتمد عليه، وإيه النتيجة اللي البزنس عاوز يوصل لها. من غير الفهم ده، ممكن نطلع بتصميم منظم بصريًا لكنه بيحل مشكلة غلط، أو يضيف خصائص مش مرتبطة باحتياج حقيقي.
في المرحلة دي بنحاول نبني صورة مشتركة بين صاحب المشروع، وفريق البزنس، والمصمم، والمطورين. الهدف إن كل الأطراف تكون فاهمة إحنا بنصمم إيه، ولمين، وإيه القيود اللي لازم نراعيها قبل الدخول في التفاصيل.
– اجتماع انطلاق المشروع Kickoff Meeting
البداية غالبًا بتكون من اجتماع انطلاق المشروع Kickoff Meeting مع أصحاب القرار، علشان نفهم فكرة المنتج، ومرحلة المشروع، وأهدافه، والمشكلة اللي الفريق شايف إنه بيحلها. الاجتماع مش مجرد استلام متطلبات، لكنه فرصة نكتشف الاختلافات بين تصورات الأطراف قبل ما تتحول لمشكلات أثناء التصميم أو البرمجة.
في المشروعات الكبيرة، بنحتاج كمان نعمل مقابلات أصحاب المصلحة Stakeholder Interviews. كل فريق بيشوف المنتج من زاوية مختلفة؛ المبيعات تعرف اعتراضات العملاء، والدعم يعرف المشكلات المتكررة، والتطوير فاهم القيود التقنية، والإدارة عندها أولويات البزنس وخطة النمو.
في نظام ERP مثلًا، تجاهل أي طرف من دول ممكن يطلع لنا تدفق شكله منطقي لكنه مش مناسب لطريقة الشغل الفعلية. علشان كده بنجمع وجهات النظر المختلفة، وبعدها نفصل بين احتياجات المشروع الحقيقية، والاقتراحات الشخصية، والطلبات اللي محتاجة دليل أو اختبار.
– تحديد المشكلة الحقيقية Problem Framing
الطلب اللي بيقوله صاحب المشروع مش دايمًا هو المشكلة اللي محتاجة تتصمم. لو قال: «محتاجين Dashboard»، فده وصف لحل مقترح، لكنه مش بيشرح ليه محتاجها أو مين هيستخدمها.
هنا بنبدأ نسأل:
مين المستخدم الأساسي للوحة التحكم؟
إيه القرارات اللي محتاج ياخدها منها؟
إيه البيانات اللي لازم تظهر فورًا؟
هل محتاج متابعة لحظية ولا تقارير دورية؟
هل كل أنواع المستخدمين عندهم نفس الصلاحيات؟
وإيه اللي هيحصل لو البيانات ناقصة أو متأخرة؟
الأسئلة دي بتحول طلب عام إلى مشكلة تصميم Design Problem نقدر نفهمها ونبني لها أكتر من حل، بدل ما ننفذ أول تصور اتقال في الاجتماع.
– مراجعة متطلبات المشروع Requirements Review
بعد فهم الصورة العامة، بنراجع كل الملفات والمعلومات المتاحة عن المنتج. ممكن تشمل:
ملخص المشروع — Project Brief.
متطلبات المنتج — Product Requirements.
نطاق العمل — Scope of Work.
القيود التقنية — Technical Constraints.
الخصائص الأساسية — Core Features.
أنواع المستخدمين والصلاحيات — User Roles & Permissions.
الأنظمة أو الإصدارات السابقة — Existing Systems.
ملف متطلبات النظام — SRS.
وجود ملف SRS بيساعد جدًا في المشروعات المعقدة، خصوصًا لو فيها صلاحيات، وعمليات مترابطة، وحالات كثيرة. بيكون مرجع مشترك بين البزنس والتصميم والتطوير، ويقلل إن كل طرف يفهم الوظيفة بطريقة مختلفة.
لكن الملف مش بيتعامل كأنه حقيقة نهائية. ممكن يكون فيه متطلبات قديمة، أو حالات ناقصة، أو وظائف مكتوبة من منظور النظام من غير ما تراعي طريقة استخدام الأشخاص له. دور المصمم هنا إنه يراجع المتطلبات، ويحدد الأسئلة المفتوحة، ويكشف التعارضات قبل ما تتحول إلى شاشات وكود.
ولو مفيش ملف متطلبات من الأساس، بنساعد الفريق ينظم الوظائف، وأنواع المستخدمين، والسيناريوهات الأساسية، والقرارات اللي لسه محتاجة حسم قبل بدء التصميم.
– تحديد نطاق المشروع Project Scope
من المهم كمان نحدد حدود المشروع من البداية. هل المطلوب تصميم منتج كامل، ولا خاصية محددة، ولا تحسين منتج قائم؟ هل العمل يشمل البحث والاختبار، ولا فيه بيانات جاهزة؟ وهل التسليم هيكون واجهات فقط، ولا نموذج تفاعلي ونظام تصميم ومتابعة تنفيذ؟
تحديد نطاق المشروع Project Scope بيمنع إن الشغل يتحول لمجموعة طلبات مفتوحة، وبيوضح إيه اللي داخل المرحلة الحالية، وإيه اللي ممكن يتأجل لإصدار لاحق. ده بيساعد الفريق يحافظ على الأولويات والميزانية والجدول الزمني.
– تحديد أهداف البزنس Business Goals
التصميم لازم يخدم هدف واضح للمشروع، مش مجرد تحسين شكل المنتج. علشان كده بنحدد أهداف البزنس اللي المفروض المنتج يساعد على تحقيقها، ونربطها بسلوك يمكن متابعته.
في متجر إلكتروني، الهدف ممكن يكون:
زيادة نسبة إتمام الطلب.
تقليل ترك سلة الشراء.
تسهيل الوصول للمنتجات.
زيادة عمليات الشراء المتكررة.
وفي منصة تعليمية، الهدف ممكن يكون:
زيادة إكمال الدروس.
رجوع المستخدم للمسار التعليمي.
تقليل الانسحاب أثناء التسجيل.
تسهيل الوصول للمحتوى المناسب.
الأهداف دي بتحدد الأولويات. لو هدف المشروع تقليل الانسحاب أثناء الدفع، مش منطقي نستهلك الجزء الأكبر من الوقت في تحسين صفحة جانبية تأثيرها محدود.
– مؤشرات النجاح Success Metrics
بعد تحديد الأهداف، بنحدد إزاي هنعرف إن الحل نجح. هنا بنستخدم مؤشرات النجاح Success Metrics المناسبة لطبيعة المنتج، زي:
نسبة إتمام المهمة — Task Completion Rate.
معدل التحويل — Conversion Rate.
نسبة الانسحاب — Drop-off Rate.
الوقت المطلوب لإتمام المهمة — Time on Task.
عدد الأخطاء أو طلبات الدعم.
معدل الرجوع للمنتج — Retention Rate.
مش كل مشروع عنده بيانات كاملة من البداية، لكن لازم يكون فيه تصور واضح للنتيجة اللي الفريق بيحاول يحسنها. غير كده، تقييم التصميم هيفضل قائم على آراء زي: «الشكل حلو» أو «الواجهة محتاجة تبقى أحدث».
– تحديد الافتراضات والمخاطر Assumptions & Risks
في بداية أي مشروع بيكون فيه معلومات مؤكدة، وحاجات الفريق متوقعها بس. ممكن نفترض إن نوعًا معينًا من المستخدمين محتاج خاصية، أو إن المشكلة سببها صعوبة الخطوات، لكن الافتراض مش بيتحول لحقيقة لمجرد إن الفريق متفق عليه.
علشان كده بنسجل:
الافتراضات اللي محتاجة اختبار.
المعلومات الناقصة.
المخاطر التقنية أو التشغيلية.
القرارات اللي معتمدة على أطراف خارجية.
الخصائص اللي تكلفتها عالية أو تأثيرها غير واضح.
الفصل بين الحقيقة والافتراض بيساعدنا نعرف إيه اللي محتاج بحث، وإيه اللي ممكن نتحرك فيه مباشرة، وإيه القرار اللي خطره كبير لو اتبنى على معلومة غير مؤكدة.
– الإطار الزمني المبدئي Preliminary Timeline
بعد مراجعة نطاق المشروع، والمتطلبات، وعدد المستخدمين والتدفقات، نقدر نحط تصور مبدئي لمراحل الشغل والمدة المتوقعة لكل مرحلة. التقدير هنا بيساعد الفريق يرتب الموارد والمراجعات ومواعيد التسليم، لكنه مش وعد نهائي قبل ما تتضح كل التفاصيل والأسئلة المفتوحة.
خطوات تصميم تجربة المستخدم UX من بداية المشروع للنهاية
تصور للأطار الزمني للمشروع Preliminary Timeline Project
– مخرجات مرحلة فهم المشروع Discovery Deliverables
مخرجات المرحلة مش لازم تكون ملفًا ضخمًا، لكنها لازم توحّد فهم الفريق. ممكن تشمل:
ملخص المشروع — Project Overview.
تعريف أولي للمشكلة — Initial Problem Statement.
أهداف البزنس — Business Goals.
مؤشرات النجاح — Success Metrics.
الجمهور المتوقع — Target Users.
نطاق المشروع — Project Scope.
المتطلبات الأساسية — Core Requirements.
أنواع المستخدمين والصلاحيات — User Roles & Permissions.
القيود التقنية والتشغيلية — Technical & Operational Constraints.
الافتراضات اللي محتاجة اختبار — Key Assumptions.
الأسئلة المفتوحة — Open Questions.
المخاطر الأولية — Initial Risks.
النتيجة المطلوبة إن الفريق يدخل مرحلة البحث وهو فاهم إيه اللي محتاج يعرفه، وليه محتاج يعرفه. مش بنبدأ البحث بشكل مفتوح، ومش بنبدأ التصميم بناءً على Brief قصير أو تصور شخص واحد عن المنتج.
Top comments (0)