الجزء الأول: عن فهم الـ Market بشكل أوسع و المتطلبات الحالية
سوق العمل بيتغير بسرعة، وده بيأثر على طريقة تقييم المصممين، والمهارات المطلوبة منهم، وطبيعة الفرص المتاحة.
عشان كده، مينفعش تقيّم مستواك اعتمادًا على الـJob Title بس. ممكن تكون Team Lead في شركة صغيرة، وبعد انتقالك لشركة أكبر تشتغل Senior أو Mid-Level بسبب اختلاف حجم الفريق، وهيكل المؤسسة، وطبيعة المسؤوليات.
ده مش تقليل من خبرتك. المسميات الوظيفية مش موحدة بين الشركات، ونفس المسمى ممكن يكون مرتبط بمسؤوليات مختلفة تمامًا من مكان للتاني.
ومع انتشار الـAI، الشركات بقت تهتم مش بس بجودة الشغل، لكن كمان بسرعة الإنتاج، والقدرة على التعلّم، وفهم الـBusiness، والتعامل مع أدوات وتقنيات جديدة.
بحسب تقرير Future of Jobs 2025 الصادر عن World Economic Forum، التفكير التحليلي ما زال من أهم المهارات الأساسية المطلوبة، بجانب الـTechnological Literacy، والمرونة، والتعلّم المستمر. وده معناه إن استخدام أدوات الـAI مهم، لكن قيمتك الحقيقية ما زالت مرتبطة بقدرتك على التفكير والتحليل وحل المشكلات.
هل فرص الـJunior Designers اختفت؟
لأ، لكنها بقت أكثر تنافسية.
في الفترة اللي بعد 2020، بعض الشركات كانت بتعيّن أكتر من Junior Designer، ويكون فيه Senior مسؤول عن التدريب والمراجعة. حاليًا، بعض الشركات بقت تحت ضغط إنها تنتج أسرع وتقلل التكلفة، وبالتالي قلّت مساحة التدريب من البداية في بعض البيئات.
ده لا يعني إن الشركات كلها توقفت عن تعيين الـJuniors، لكنه معناه إن المصمم المبتدئ محتاج يقدّم مستوى شغل أوضح، ويثبت إنه قادر يتعلم ويتطور ويشتغل باستقلالية نسبية.
مستوى الجودة المطلوب بيختلف من شركة للتانية. المطلوب في Software House مش زي Product-Based Company، وبيختلف كمان عن الجهات الحكومية. لكن في كل الحالات، المصمم اللي بيفهم المشكلة ويعرف يتواصل ويسلّم نتيجة قابلة للتنفيذ بيكون عنده قيمة أعلى.
ابدأ من الـPortfolio
لو إنت في بداية المجال، فأول خطوة هي تحسين جودة الشغل اللي بتعرضه.
وجود Group Projects شيء طبيعي، لكن لو كل مشروعاتك جماعية، هيبقى صعب على الشخص اللي بيراجع الـPortfolio إنه يعرف دورك الحقيقي. حاول يكون عندك مشروع أو أكتر يوضح بشكل مستقل طريقة تفكيرك، والقرارات اللي أخدتها، والجزء اللي كنت مسؤولًا عنه.
مش لازم تعمل مشروعًا جديدًا كل مرة. أحيانًا تطوير مشروع قديم يكون أهم من إضافة مشروع جديد.
راجع:
الـProject Covers.
ترتيب المشروعات.
جودة الصور والمقاسات.
الـLayouts والـSpacing.
طريقة عرض الـUI.
شرح دورك داخل المشروع.
توافق الشغل مع مستواك الحالي.
أربع أو خمس مشروعات قوية أفضل من عدد كبير من المشروعات الضعيفة. ولو فيه مشروع مبقاش بيمثل مستواك، ممكن تحوّله إلى Draft لحد ما تطوره.
الـPortfolio مش Task بتتعمل مرة واحدة؛ هو مساحة بتتطور مع تطورك.
قدّم قصة المشروع، مش الشاشات بس
الـUI هو غالبًا أول عنصر بصري هيلفت الانتباه، لكن عرض الشاشات لوحده مش كفاية.
الـCase Study الجيدة لازم تجاوب عن خمس نقاط:
Problem: إيه المشكلة؟
Context: المشكلة ظهرت فين وبتأثر على مين؟
Role: إنت كنت مسؤولًا عن إيه؟
Solution: إيه الحل اللي قدمته؟
Impact: إيه النتيجة أو القيمة اللي أضافها المشروع؟
مش ضروري تعرض كل خطوة في الـDesign Process لمجرد إثبات إنك نفذتها. اعرض فقط الأنشطة والقرارات اللي ساعدت فعلًا في الوصول للحل.
ولو المشروع جماعي، وضّح دورك بدقة. بدل ما تقول: «اشتغلنا على المشروع»، اشرح إنت نفذت إيه، وشاركت في أي قرارات، وإيه الـDeliverables اللي كنت مسؤولًا عنها.
جهّز Script لشرح مشروعاتك
أحيانًا بيكون المشروع قوي، لكن المصمم مش عارف يشرحه في الـInterview.
عشان تتجنب ده، جهّز Script مختصرًا لكل مشروع مهم. مش المطلوب تحفظ نص ثابت، لكن ترتب القصة في دماغك:
المشروع بدأ إزاي؟
المستخدم كان مين؟
المشكلة كانت إيه؟
كان دورك إيه؟
أخدت قراراتك على أي أساس؟
إيه القيود اللي واجهتك؟
الحل حقق إيه؟
وإنت اتعلمت إيه؟
جهّز كمان تعريف مختصر بنفسك بالعربي والإنجليزي. البداية الواضحة بتقلل التوتر وبتساعدك تكمل المقابلة بثقة أكبر.
المصمم الـT-Shaped
التخصص مهم، لكن فهم المجالات القريبة منك بيوسّع قدرتك على التعامل مع المشروعات والفرق المختلفة.
المقصود بالـT-Shaped Designer هو شخص عنده عمق في تخصص أساسي، ومعرفة عملية بالتخصصات المحيطة بيه.
لو إنت UX/UI Designer، فمن المفيد إنك تفهم أساسيات:
Product Management.
Business Analysis.
كتابة الـPRD والـUser Stories.
الـDocumentation.
Presentation Design.
الـPrototyping والـMotion.
الـFrontend والـHandoff.
HTML وCSS.
تصميم التقارير والعروض.
مش مطلوب منك تتحول إلى Product Owner أو Developer، لكن مهم تفهم الشخص اللي بيجهز الـRequirements، والشخص اللي هيستلم التصميم بعدك.
المعرفة دي بتحسن التواصل، وتقلل الأخطاء، وبتساعدك تحل المشكلات بدل ما الشغل يقف عند حدود تخصصك.
استخدم الـAI لتسريع العمل
الـAI يقدر يساعد المصمم في:
تنظيم الـRequirements.
إعداد Draft PRD.
تجهيز User Stories مبدئية.
تحليل المنافسين Competitive Analysis.
إعداد Proposals وPresentations.
تلخيص الاجتماعات.
إنتاج UI Draft.
إنشاء Prototype مبدئي.
تجربة حلول مختلفة بسرعة.
لكن النتيجة بتعتمد على جودة الـContext اللي بتديه للأداة.
لو طلبت: «اعمل لي CRM» أو «صمم Ticketing App» من غير معلومات كافية، غالبًا هتحصل على Structure عامة، وممكن الأداة تضيف Features ملهاش علاقة بالمشروع.
وضّح الأول:
طبيعة الـBusiness.
الـIndustry.
الـPersonas.
الخدمات الأساسية.
الـBusiness Rules.
القيود.
المعلومات المؤكدة.
النقاط اللي محتاجة Validation.
الدور اللي عايز الـAI يقوم بيه.
هل عايزه يساعدك كـProduct Owner، ولا Business Analyst، ولا UX Researcher، ولا Product Designer؟ تحديد الدور والـContext بيحسن النتيجة، لكنه لا يلغي ضرورة مراجعتها.
الجزء الثاني: من فكرة العميل إلى UI قابل للتنفيذ
في الفيديو اللي في أخر النشرة الجزء العملي بيشرح Workflow كامل باستخدام مثال لتطبيق Technical Support تابع لمصنع بيبيع معدات وماكينات صناعية.
الوصف الأول للمشروع كان بسيط: العميل محتاج Mobile Application يسمح لعملائه بفتح Tickets عند حدوث مشكلة في المعدات ومتابعة الدعم الفني.
بدل الدخول مباشرة إلى Figma، بدأ العمل بفهم الـIndustry، وتحديد المستخدمين، وتحليل الخدمات والسيناريوهات. بعد كده تم استخدام الـAI لتنظيم الـRequirements وإنتاج UI Draft، ثم تحليل النتيجة وإعادة بنائها باستخدام الـDesign System.
العناوين التالية بتلخص مراحل التطبيق. ولو محتاج تشوف خطوات التنفيذ، والـPrompts، وطريقة المراجعة داخل Figma، هتلاقي التفاصيل كاملة في الفيديو.
فهم الـBusiness والـIndustry
تحديد طبيعة المعدات، وطريقة عمل الدعم الفني، والمعلومات المتاحة عن كل ماكينة. الهدف هو منع التعامل مع المشروع كـTicketing System عام من غير فهم لسياقه الحقيقي.
تحديد الـUsers والـServices
تحديد الأطراف الأساسية، مثل Customer وTechnical Support وTechnician، وبعدها تحديد ما يحتاج كل مستخدم إلى تنفيذه داخل النظام.
تحليل الـScenarios
تحليل رحلة إنشاء Ticket، وإضافة المشكلة والمرفقات، ومتابعة الحالة، وتحديد موعد الزيارة، وإغلاق الطلب أو إعادة فتحه.
بناء الـInformation Architecture
تنظيم التطبيق في Modules وصفحات رئيسية، مثل:
Home.
Tickets.
New Ticket.
Machines.
Profile.
تحويل الافتراضات إلى أسئلة
أي Feature غير مؤكدة لازم تتحول إلى سؤال يُناقش مع العميل. مثلًا: هل فيه Live Chat؟ هل المستخدم ينشئ الحساب بنفسه؟ هل التطبيق بيدعم طلب Spare Parts؟ وهل فيه عقود صيانة دورية؟
جمع الـMoodBoard
اختيار مراجع تساعد في اتخاذ قرارات محددة، زي شكل Ticket Card، وخطوات إنشاء الطلب، وطريقة عرض الـStatus والـPriority والـAttachments.
نقطة اختيارية ولكن مهم تجرب وهي إعداد Draft PRD
استخدام الـAI لتنظيم المعلومات في صورة Draft PRD، مع مراجعة كل Feature وحذف أي اقتراح لا يتوافق مع الـBusiness Scope.
والـUser Story مش مجرد جملة قصيرة؛ هي وسيلة لوصف احتياج المستخدم وقيمته، وتحتاج إلى تفاصيل ومعايير قبول مناسبة حسب تعقيد المشروع.
بناء الـSitemap
تحديد الـUsers والصفحات والـActions والـStates قبل طلب الـUI. الـSitemap الواضحة بتقلل اعتماد النتيجة على تخمين الأداة.
تحديد الـVisual Direction
تحديد اللغة، واتجاه RTL أو LTR، والخطوط، والألوان، والـDesign System، والـSpacing، والمرجع البصري المطلوب.
إنتاج UI Draft أو Prototype
استخدام أداة زي Figma Make لتحويل الوصف والـRequirements إلى تجربة قابلة للمراجعة. Figma نفسها بتقدم Make كأداة لتحويل الأفكار المكتوبة إلى نماذج تفاعلية وتطبيقات مبدئية، لكن النتيجة ما زالت محتاجة توجيه ومراجعة من المصمم.
هنا الصمم بيقع في مشكلة وهي إن التصميم اللي طلع كـ Output من الـ AI هل أستخدمه زي ما هو؟ و ازاي ادمجة في المشروع بتاعي بشكل Profissional.
تحليل التصميم إلى Components
بدل إعادة رسم الصفحة ككتلة واحدة، يتم تقسيمها إلى:
Header.
Tabs.
Ticket Card.
Machine Card.
Status Badge.
Buttons.
Navigation.
Profile Items.
إعادة البناء بالـDesign System
استخدام الـComponents والـTokens المعتمدة، وربط الألوان والـTypography والـSpacing بالـVariables والـStyles الصحيحة.
خليني أراجع معاك،الفيديو الأول بيركز على:
تغيّرات سوق العمل.
تطوير الـPortfolio.
طريقة عرض الـCase Studies.
المهارات المطلوبة من المصمم.
دور الـAI في زيادة الإنتاجية.
رابط الجزء الأول:
الفيديو الثاني بيركز على:
تحليل مشروع حقيقي.
بناء الـInformation Architecture.
إعداد Draft PRD.
كتابة وتطوير الـPrompts.
إنتاج UI Draft.
تحويل النتيجة إلى Components.
إعادة البناء باستخدام الـDesign System.
رابط الجزء الثاني:
الخلاصة
الـAI ملغاش دور المصمم، لكنه غيّر جزءًا من طريقة العمل.
الأداة ممكن تسرّع الـResearch والـDocumentation والـDrafting والـPrototyping، لكن المصمم ما زال مسؤولًا عن فهم المشكلة، وتحديد الـContext، ومراجعة الافتراضات، واتخاذ القرارات، وضمان جودة النتيجة.
القيمة مش في إنك تعرف اسم كل أداة جديدة، لكن في إنك تعرف تستخدم الأداة داخل Workflow حقيقي، وتراجع الناتج، وتحوله إلى حل مناسب للمستخدم والـBusiness.
التعليقات