DEV Community: Mostafa Ali

أهم خطوة في تصميم تجربة المستخدم UX

Mostafa Ali — Fri, 07 Aug 2026 09:16:14 +0000

فهم المشروع وأهداف البزنس 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 قصير أو تصور شخص واحد عن المنتج.

https://mostafaali.me/ux-design-process-steps-2026/

إيه هو تصميم تجربة المستخدم UX؟

Mostafa Ali — Fri, 07 Aug 2026 09:14:05 +0000

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

علشان كده تجربة المستخدم UX أوسع من شكل الشاشة. هي بتشمل كل حاجة بتحصل من أول دخول المستخدم للموقع أو التطبيق، مرورًا بطريقة عرض المعلومات والتنقل بين الخطوات، لحد إتمام المهمة والحصول على رد Response واضح من النظام Loading Time. حتى وقت الانتظار، ورسائل الخطأ، وحالات عدم وجود بيانات، وطريقة الرجوع أو تعديل القرار، كلها أجزاء أساسية من تجربة الاستخدام UX.

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

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

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

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

علشان كده تصميم تجربة المستخدم UX للمواقع والتطبيقات بيجمع بين بحث المستخدمين، وتحليل احتياجاتهم وسلوكهم، وتنظيم المعلومات Information Architecture، وبناء تدفقات الاستخدام، وتصميم المخططات الأولية Prototyping، ثم اختبار الحل قبل اعتماده. تجربة المستخدم مش مرحلة شكلية تسبق تصميم واجهة المستخدم UI، لكنها الأساس اللي بيحدد محتوى الواجهة، وترتيبها، وطريقة تفاعل المستخدم معاها.

https://mostafaali.me/ux-design-process-steps-2026/

Brand Identity and UI/UX Designer

Mostafa Ali — Fri, 07 Aug 2026 09:09:28 +0000

I’m Mostafa Ali, a Brand Identity and UI/UX Designer from Ismailia, Egypt, with around eight years of experience.

I’ve worked across advertising and software companies, including Index Group and Iraq Soft, where I designed complete visual identities and digital products ranging from simple websites and mobile apps to complex platforms and ERP systems.

Combining branding with product design has taught me to see a brand as a complete experience—from its strategy and visual identity to the way people interact with its digital products. I also enjoy writing and sharing practical insights from my experience and projects.

https://mostafaali.me/blogs