الشراكة مع المطورين: المصمم والبرمجة
أجمل تصميم في العالم قيمته صفر لو المطور معرفش ينفذه. الدليل ده هيعلمك تبني شراكة حقيقية مع المطورين: تفهم قيود الكود، وتسلّم ملفات جاهزة للتنفيذ، وتبني معاهم Design System واحد — وتقدموا للعميل مشروعًا كاملًا بدل نصف مشروع.
محتويات الدليل
- الفجوة بين التصميم والكود: ليه أجمل تصميم بيموت في التنفيذ
- الحد الأدنى من البرمجة اللي لازم كل مصمم يفهمه
- نظام الـ Handoff: تسليم ملف التصميم من غير فوضى
- الـ Design System: اللغة المشتركة الحقيقية
- التعاون أثناء التنفيذ: حلقة المراجعة اللي بتحمي التصميم
- الـ Responsive والحالات الحدية: التفاصيل اللي بتكسر أي تصميم
- الشراكة التجارية: مصمم + مطور = فريق مشاريع كاملة
- 7 أخطاء قاتلة في شراكة المصمم والمطور
- الأسئلة الشائعة
1 الفجوة بين التصميم والكود: ليه أجمل تصميم بيموت في التنفيذ
المشهد ده حصل مع كل مصمم واجهات مرة على الأقل: تسلّم ملف Figma شكله تحفة — ألوان متناسقة، مسافات مضبوطة بالبكسل، كل حاجة في مكانها. وبعد أسبوعين المطور يبعت لك لينك الموقع التجريبي، وتفتحه تلاقي حاجة تانية خالص. الزر مختلف، المسافات مضروبة، الخط شكله غريب، والصفحة على الموبايل كارثة.
أول رد فعل طبيعي: “المطور ده مش شاطر”. لكن خليني أقولك الحقيقة اللي محدش بيحب يسمعها: في أغلب الحالات المشكلة مش في المطور — المشكلة في الفجوة بين اللي أنت صممته واللي هو يقدر يبنيه. وأنت اللي مسؤول عن سد الفجوة دي، لأنك أنت صاحب التصميم.
مثال افتراضي: صفحة الهبوط اللي ماتت مرتين
مصمم مستقل (مثال افتراضي) اتفق مع عميل على صفحة هبوط لمنتج جديد. صمم صفحة مبهرة: عنوان بخط مخصص حمّله من موقع خطوط مجاني، صورة خلفية ضخمة بجودة عالية، قسم متحرك بتأثيرات معقدة، ونموذج تسجيل بتصميم غير تقليدي تمامًا. العميل انبهر واعتمد التصميم فورًا.
المطور استلم الملف وبدأ التنفيذ، وبعد 3 أيام رجع بقائمة مشاكل: الخط المخصص ترخيصه لا يسمح بالاستخدام على الويب، الصورة الضخمة حجمها هيخلي الصفحة تفتح في 12 ثانية، التأثيرات المتحركة محتاجة مكتبة مدفوعة، ونموذج التسجيل غير التقليدي هياخد ضعف الوقت لأنه مش عنصر قياسي. النتيجة: إما تعديل التصميم كله، أو دفع تكلفة إضافية كبيرة، أو موقع بطيء وقبيح. التصميم “مات” قبل ما يتعرض على حد.
المشكلة هنا مش إن المصمم وحش ولا المطور كسول. المشكلة إن المصمم صمم في فراغ — من غير أي اعتبار لقيود التنفيذ. والمطور دخل متأخر جدًا، بعد ما القرارات كلها اتاخدت.
الجذر: المصمم يصمم “صورة” والمطور يبني “نظامًا”
هنا بقى أعمق نقطة في الدليل كله، فخد نفس وركز. أنت كمصمم بتشتغل على صورة ثابتة: شاشة بمقاس معين، نص بطول معين، صورة موجودة، كل حاجة في مكانها المثالي. المطور بقى بيبني نظامًا حيًا: نفس الشاشة لازم تشتغل على 20 مقاس مختلف، النص ممكن يطول أو يقصر حسب اللغة والمحتوى، الصورة ممكن متوصلش، والزرار له 5 حالات (عادي، hover، مضغوط، معطل، جارٍ التحميل).
الصورة بتجمد لحظة واحدة مثالية. النظام لازم يتعامل مع كل اللحظات — حتى القبيحة منها. طول ما أنت بتصمم صورة والمطور بيبني نظامًا، هتفضلوا تتكلموا لغتين مختلفتين. الشراكة الحقيقية تبدأ لما المصمم يبدأ يفكر بمنطق الأنظمة: مش “الشكل ده حلو”، لكن “الشكل ده هيتصرف إزاي لما الظروف تتغير؟”
| وجه المقارنة | عقلية المصمم (الصورة) | عقلية المطور (النظام) |
|---|---|---|
| الوحدة الأساسية | الشاشة الكاملة — التكوين البصري ككل | المكون (component) — قطعة قابلة لإعادة الاستخدام |
| النص | طول ثابت مختار بعناية لشكل مثالي | محتوى متغير — ممكن يطول 3 أضعاف أو يبقى فارغًا |
| الصور | موجودة دائمًا وبجودة مثالية | ممكن تفشل في التحميل أو تبقى بأبعاد مختلفة |
| التفاعل | لقطة واحدة للحالة المثالية | حالات متعددة: تحميل، خطأ، فارغ، نجاح |
| المقاسات | مقاس أو مقاسان مصممان بعناية | سلسلة متصلة من المقاسات من الموبايل الصغير للشاشات الكبيرة |
| الخطأ | مش موجود في التصميم أصلًا | لازم يتصمم له شكل — المستخدم هيقابله حتمًا |
3 أسباب بتوسع الفجوة (والحل لكل واحد)
السبب الأول: لغة مختلفة. أنت بتقول “خلي المسافة مريحة شوية” وهو محتاج رقم: 16px ولا 24px؟ أنت بتقول “اللون الأزرق بتاعنا” وهو محتاج الكود الست عشري بالظبط. الحل: لغة الأرقام والقيم الدقيقة في كل تواصل — بلا أوصاف عاطفية.
السبب الثاني: المطور بيدخل متأخر. النموذج التقليدي: المصمم يصمم، العميل يعتمد، وبعدين المطور يستلم و”ينفذ”. يعني الشخص اللي عارف القيود بيدخل بعد ما كل القرارات اتاخدت. الحل: إشراك المطور من مرحلة التصميم — مراجعة سريعة قبل الاعتماد النهائي توفر أسابيع من إعادة الشغل.
السبب الثالث: التصميم بيتعامل كأنه نهائي. ملف Figma عند المصمم “خلص”، لكن عند المطور هو “بداية”. أي تعديل بعد بدء التنفيذ = تكلفة. الحل: تجميد التصميم (design freeze) قبل التنفيذ — أي تغيير بعده يمر بعملية موافقة وتقدير وقت.
2 الحد الأدنى من البرمجة اللي لازم كل مصمم يفهمه
خلينا نتفق من الأول: مش مطلوب منك تبقى مطور. محدش بيطلب من المصمم يكتب كود الإنتاج. لكن فيه فرق ضخم بين “مش بكتب كود” و”مش فاهم الكود بيشتغل إزاي”. الأول طبيعي، التاني بيكلفك شغل وفلوس وسمعة.
اللي محتاجه هو فهم القيود — تعرف إيه السهل وإيه الصعب وإيه المستحيل في التنفيذ، عشان تصمم داخل منطقة الممكن بدل ما تصمم أحلامًا وبعدين تتفاجئ. وده مش علم صواريخ — هو مجموعة مفاهيم أساسية لو فهمتها هتتغير طريقة تصميمك كلها.
الثالوث: HTML وCSS وJavaScript بجملة واحدة لكل واحد
HTML هو الهيكل: تخيله كعلب داخل علب — صفحة الويب عبارة عن صناديق متداخلة: صندوق كبير جواه صندوق للعنوان وصندوق للنص وصندوق للزرار. كل عنصر في تصميمك هيتحول لصندوق في الكود. لما تصمم، فكر: “العناصر دي مترتبة إزاي جوه بعض؟” — الترتيب المنطقي ده هو اللي بيخلي التنفيذ سهل.
CSS هو الشكل: كل حاجة بصرية — الألوان، المقاسات، المسافات، الخطوط، الظلال — بتتكتب بلغة اسمها CSS. المهم تفهمه: CSS له نظام وراثة ومنطق — يعني لو حددت لونًا لصندوق كبير، العناصر جواه ممكن ترثه. وده معناه إن التناسق في تصميمك (نفس اللون، نفس المسافة) بيترجم لكود أنضف وأسرع — والعشوائية بتترجم لكود معقد وبطيء.
JavaScript هو التفاعل: أي حاجة “بتحصل” لما المستخدم يدوس أو يحرك — القوائم المنسدلة، السلايدر، النوافذ المنبثقة — دي شغل JavaScript. القاعدة العملية: كل تفاعل بتصممه = وقت تطوير إضافي. التفاعلات القياسية (زرار بيفتح قائمة) رخيصة وسريعة. التفاعلات المخصصة والمعقدة غالية — فلازم تكون مستاهلة.
5 مفاهيم لو فهمتها هتتصمم بشكل مختلف تمامًا
1. الـ Box Model — كل حاجة صندوق: أي عنصر على الويب له 4 طبقات: المحتوى نفسه، ثم padding (مسافة داخلية)، ثم border (إطار)، ثم margin (مسافة خارجية). لما تقول للمطور “المسافة 24px” لازم تحدد: داخلية ولا خارجية؟ الفرق ده بيغير التنفيذ تمامًا. في Figma: الـ padding هو المسافة جوه الـ frame، والـ margin هي المسافة بين العناصر (gap).
2. الـ Responsive Units — مش كل البكسل زي بعضه: على الويب فيه وحدات نسبية (زي % وrem) ووحدات ثابتة (px). التصميم اللي كله مقاسات ثابتة بالبكسل هيتكسر على الشاشات المختلفة. القاعدة: صمم شبكة مرنة (grid) بمسافات نسبية، وسيب التفاصيل الدقيقة للمطور — هو هيترجمها للوحدة المناسبة.
3. الـ Flexbox والـ Grid — لغة الترتيب: دي الطريقة اللي المطور بيرتب بيها العناصر: جنب بعض ولا فوق بعض، في النص ولا على الطرف. لما تصمم بـ Auto Layout في Figma أنت فعليًا بتتكلم نفس لغة الـ Flexbox — وده بيخلي ملفك “مقروءًا” للمطور بدل ما يكون لغزًا.
4. الخطوط على الويب مش زي برامج التصميم: الخط اللي شغال عندك في Figma ممكن ميشتغلش على الموقع — لازم يكون متاحًا كملف ويب (woff2) وترخيصه يسمح بالاستخدام على المواقع. وأوزان الخطوط الكتير (خفيف، عادي، متوسط، عريض، أسود) كل واحد ملف بيتحمل — يعني 5 أوزان = 5 ملفات = موقع أبطأ. اختار وزنين أو تلاتة بالكتير.
5. الأداء جزء من التصميم: الصورة الـ 5 ميجا اللي حاططها خلفية، الفيديو اللي بيشتغل تلقائيًا، الخطوط الـ 8 أوزان — كل دي “قرارات تصميم” بتأثر على سرعة الموقع. والموقع البطيء = زوار بيمشوا = تصميمك فشل حتى لو شكله حلو. اسأل نفسك مع كل عنصر تقيل: “هل يستاهل التكلفة؟”
قاموس المصمم: مصطلحات المطور بالمصري
دي الكلمات اللي هتسمعها في أي اجتماع مع مطور — افهمها عشان متبقاش قاعد مش فاهم:
| المصطلح | معناه بالمصري | ليه يهمك كمصمم |
|---|---|---|
| Component | قطعة جاهزة بتتكرر — زي الزرار أو الكارت | صمم القطعة مرة واحدة صح، وهتتكرر في كل الموقع بنفس الشكل |
| State | حالة العنصر: عادي، لما تقف عليه، لما تدوسه، لما يتعطل | لازم تصمم كل الحالات — مش الحالة المثالية بس |
| Breakpoint | مقاس الشاشة اللي عنده التصميم بيتغير شكله | حدد مع المطور المقاسات اللي هيصمم لها: موبايل، تابلت، ديسكتوب |
| API | البوابة اللي الموقع بيجيب منها البيانات (منتجات، مقالات…) | المحتوى جاي من API يعني متغير — صمم لحالات: بيانات كتير، قليلة، مفيش |
| Deploy | نشر الموقع على الإنترنت — اللحظة اللي الشغل بيبقى لايف | أي تعديل بعد الـ deploy أصعب وأخطر من قبله |
| Responsive | التصميم بيتكيف مع كل مقاسات الشاشات | مش رفاهية — أغلب الزوار من الموبايل |
| Pixel-perfect | التنفيذ مطابق للتصميم بالبكسل | هدف جميل لكن مش دايمًا ممكن — المرونة أحيانًا أهم من التطابق |
| Edge case | الحالة الشاذة: نص طويل جدًا، صورة مش موجودة | صمم لها — المطور هيسألك عنها حتمًا |
ليه الفهم ده بيرفع سعرك؟
المصمم اللي بيقول “مش شغلتي” لما المطور يتكلم عن قيود التنفيذ، بيتحول لعبء على الفريق — حد لازم يترجم له كل حاجة. والمصمم اللي فاهم الأساسيات بيتحول لشريك: بيصمم حاجات قابلة للتنفيذ من أول مرة، بيتكلم لغة المطور، وبيوفر وقت الفريق كله. الفرق بين الاتنين في السوق: الأول بيتنافس على السعر، والتاني بيطلب السعر اللي هو عايزه — لأن العميل بيدفع لمن يقلل مخاطره، مش لمن يرسم حلو بس.
ولو لسه بتبني أساسك في التصميم نفسه قبل الغوص في عالم المطورين، ابدأ من الأساس الصح:
3 نظام الـ Handoff: تسليم ملف التصميم من غير فوضى
كلمة handoff بتتترجم “تسليم” — لكن في الواقع معظم اللي بيحصل مش تسليم، هو رمي. المصمم يبعت لينك Figma على واتساب ويقول “اتفضل”، والمطور يفتح يلاقي ملفًا فيه 40 شاشة بأسماء زي “Frame 27″ و”نسخة نهائية 2” و”جرب كده”، وطبقات مش مسماة، وألوان متكررة بدرجات مختلفة، ولا صفحة توضح إيه النهائي وإيه المسودات.
وبعدين المصمم يستغرب ليه التنفيذ مختلف. يا صديقي: المطور مبيقرأش أفكارك. كل قرار مش موثق في الملف = قرار المطور هياخده بنفسه — وغالبًا هياخده غلط من وجهة نظرك. الـ handoff المحترم نظام كامل، مش لينك.
قاعدة الملف النظيف: 6 شروط قبل ما تبعت اللينك
التوثيق: القرارات اللي مش مكتوبة مش موجودة
الملف النظيف بيجاوب على “إيه الشكل؟” — لكن المطور محتاج إجابة “ليه كده؟” و”إيه اللي يحصل لما…؟”. عشان كده جنب كل شاشة معقدة، اعمل صفحة أو قسم ملاحظات (Annotations) يوضح:
- سلوك العناصر: الزرار ده لما تدوس عليه بيحصل إيه؟ القائمة دي بتتفتح إزاي؟ اكتبها — مش كل حاجة واضحة من الشكل.
- الحالات (States): لكل عنصر تفاعلي: شكله العادي، لما تقف عليه بالماوس، لما يتعطل، لما يكون بيحمل. صمم الحالات دي أو على الأقل اوصفها.
- المحتوى المتغير: “النص هنا ممكن يطول” — حدد أقصى طول متوقع وإيه اللي يحصل بعده (سطر جديد؟ نقاط …؟). “الصورة هنا اختيارية” — وضح شكل التصميم من غيرها.
- الأولويات على الموبايل: لما الشاشة تصغر، إيه اللي بيختفي وإيه اللي بيفضل؟ رتب العناصر حسب الأهمية.
- ملفات التصدير: الأيقونات والصور بصيغة SVG للحاجات المتجهة، وبمقاسات مضبوطة للصور — ومتسمية بأسماء واضحة مش “image-final-v2”.
اجتماع التسليم: 30 دقيقة توفر 30 ساعة
بعد ما الملف جاهز، متبعتش اللينك وتمشي. اعمل اجتماع تسليم قصير (30 دقيقة) تمشي فيه مع المطور على الشاشات الأساسية: توضح الفكرة العامة، وتنبهه للأجزاء المعقدة، وتسمع منه أول انطباع عن الصعوبات. الاجتماع ده هو اللي بيكشف “التصميم ده هياخد وقت أطول من المتوقع” قبل ما المطور يبدأ — مش بعد ما يخلص نص الشغل ويكتشف.
وفي الاجتماع ده اتفقوا على 3 حاجات: قناة التواصل (تعليقات Figma؟ مجموعة واتساب؟)، إيقاع التحديثات (امتى تشوف نسخة تجريبية؟)، وقاعدة التعديلات (أي تغيير في التصميم بعد الاجتماع ده بيتوثق أولًا وبعدين يتنفذ — مش العكس).
4 الـ Design System: اللغة المشتركة الحقيقية
لو الـ handoff هو “تسليم الشحنة”، فالـ Design System هو “اللغة اللي بتتكتب بيها الشحنة”. هو مجموعة القواعد والمكونات المشتركة اللي بيشتغل بيها المصمم والمطور معًا — بدل ما كل شاشة تتصمم من الصفر وكل صفحة تتبني من الصفر.
خليني أوريك المشكلة اللي بيحلها بمثال افتراضي: موقع فيه 12 صفحة، وفي كل صفحة زرار “اشترك الآن”. المصمم صمم كل زرار لوحده — واحد عريض شوية، واحد لونه أزرق مختلف درجة، واحد الخط فيه أكبر. المطور نفذ كل واحد لوحده — 12 كود مختلف لنفس الزرار. بعد 3 شهور العميل قال “غيّروا لون الأزرار” — المطور اضطر يعدل 12 مكانًا، وغلط في 2 منهم. ده اللي بيحصل من غير Design System: فوضى مضروبة في عدد الصفحات.
مع Design System: الزرار متعرف مرة واحدة — شكله، لونه، مقاساته، حالاته. المصمم بيستخدمه من مكتبة المكونات، والمطور بيستخدمه من مكتبة الكود. تغيير اللون؟ مكان واحد. النتيجة واحدة في كل الصفحات. ده مش رفاهية للشركات الكبيرة — ده توفير وقت من أول مشروع متوسط.
الـ Design Tokens: أبسط فكرة وأقواها
الـ tokens هي الخطوة الأولى والأهم: بدل ما القيم مكتوبة خام في كل مكان، بتتسمى وتتخزن في مكان واحد. اللون الأزرق مش “#2563EB” المكتوبة في 50 مكان — هو “primary-500” المتعرف مرة واحدة. المسافة الأساسية مش “16px” متنطورة — هي “spacing-md”.
ليه ده مهم للشراكة؟ لأن الـ tokens هي أول لغة مشتركة حقيقية بين ملف Figma وملفات الكود. نفس الاسم هنا وهناك. لما العميل يطلب تغيير اللون الأساسي، التغيير بيحصل في مكان واحد وينعكس على التصميم والكود معًا — بدل ما المصمم يعدل 50 شاشة والمطور يعدل 50 ملفًا. أدوات زي Tokens Studio بتخلي المزامنة دي أوتوماتيكية بين Figma والكود.
الهرم: من الذرة للصفحة (Atomic Design)
منهجية Atomic Design — المشروحة بالكامل في كتاب براد فروست المجاني — بتقسم الواجهة لـ 5 مستويات، وكل مستوى بيتبني على اللي قبله:
الجمال هنا إن التقسيمة دي هي نفسها طريقة تفكير المطور — هو بيبني المكونات بنفس التدرج. لما تتكلموا بنفس الهرم، الخلافات بتقل بشكل جذري لأنكم شايفين نفس الخريطة.
قبل وبعد: الفرق بالأرقام العملية
| وجه المقارنة | من غير Design System | مع Design System |
|---|---|---|
| تغيير اللون الأساسي | تعديل يدوي في كل شاشة وكل ملف كود | تغيير token واحد ينعكس في كل مكان |
| إضافة صفحة جديدة | تصميم وبناء من الصفر | تركيب مكونات جاهزة — التصميم والكود معًا |
| اتساق الشكل | يعتمد على ذاكرة المصمم ودقة المطور | مضمون بالنظام — المكون الواحد شكله واحد دائمًا |
| دخول عضو جديد للفريق | أسابيع عشان يفهم “إحنا بنعمل الحاجات إزاي” | يقرأ النظام ويبدأ ينتج من أول يوم |
| الخلافات بين المصمم والمطور | كثيرة — كل تفصيلة محتاجة قرارًا جديدًا | قليلة — معظم القرارات متاخدة مسبقًا في النظام |
ابدأ صغيرًا: نظام من صفحة واحدة
متخليش كلمة “System” تخوفك — مش لازم تبني نظامًا زي جوجل من أول يوم. ابدأ بـ صفحة Style Guide واحدة في كل مشروع: الألوان (كـ Styles مسماة)، أنماط النصوص (عناوين، نص عادي، تعليقات)، الأزرار بحالاتها، والمسافات الأساسية. الصفحة دي لوحدها بتحل أغلب مشاكل الاتساق.
وبعد كام مشروع هتلاقي عندك مكتبة مكونات بتتكرر — ساعتها وثّقها: كل مكون له اسم، وشكل، وحالات، وقواعد استخدام (“الزرار الأساسي للإجراءات الرئيسية فقط”). كده أنت بنيت Design System حقيقي من غير ما تحس — والمطور اللي هيشتغل معاك هيلاقي نفسه قدام نظام جاهز مش ملف فوضوي.
ولو شغلك الأساسي واجهات مواقع — خصوصًا المتاجر — فالدليل المتخصص هيكمل الصورة معاك:
5 التعاون أثناء التنفيذ: حلقة المراجعة اللي بتحمي التصميم
التسليم مش نهاية العلاقة — هو بدايتها الحقيقية. الفترة بين تسليم التصميم وإطلاق الموقع هي اللي بتحدد: هل التصميم هيطلع زي ما اتصمم، ولا هيتحول لحاجة تانية؟ والفرق بين الحالتين مش موهبة المطور — هو نظام التعاون أثناء التنفيذ.
أول قاعدة ذهنية لازم تتبناها: المطور مش عدوك ولا موظف تنفيذ أعمى — هو شريكك في الجودة. هو أول واحد هيشوف تصميمك “حيًا”، وهو اللي هيكتشف المشاكل اللي أنت مشفتهاش وأنت بتصمم صورًا ثابتة. التعامل معاه كخصم بيخليك تخسر أهم عين ناقدة عندك.
مراجعة المطور المبكرة: قبل الاعتماد مش بعده
أذكى حركة في العملية كلها: قبل ما تعتمد التصميم النهائي مع العميل، اعرضه على المطور لمراجعة سريعة (30 دقيقة). اسأله سؤالًا واحدًا: “في حاجة هنا هتكون مكلفة أو صعبة في التنفيذ؟” — الإجابة هتوفر عليك كوارث:
- هيقولك إن التأثير المتحرك المعقد ده هياخد أسبوع لوحده — فتبسطه قبل الاعتماد.
- هينبهك إن الخط ده مش متاح على الويب — فتغيره قبل ما العميل يتعلق بيه.
- هيقترح بديلًا أرخص لنفس الأثر البصري — فتكسب نفس الشكل بوقت أقل.
المراجعة دي لو حصلت بعد اعتماد العميل، أي تغيير هيبقى “تعديلًا على المعتمد” — بمشاكله وتكلفته. لو حصلت قبل الاعتماد، هي مجرد “تحسين في المسودة” — بلا تكلفة نفسية أو مادية.
المراجعة البصرية (Visual QA): حقك ونظامك
قبل الإطلاق، من حقك — بل من واجبك — تراجع التنفيذ وتقارنه بالتصميم. لكن عشان المراجعة دي متتحولش لخناقة، لازم تكون نظامًا متفقًا عليه من الأول مش مفاجأة في الآخر. اتفق مع المطور من البداية: “قبل الإطلاق هيكون فيه جولة مراجعة بصرية — هراجع وأبعت ملاحظات محددة”.
قائمة الفحص (Checklist) بتاعتك:
- الألوان: مطابقة لقيم الـ tokens بالظبط — مش “قريبة منها”
- الخطوط: النوع والحجم والوزن والتباعد — قارن جنبًا إلى جنب مع التصميم
- المسافات: الـ padding والـ margin بين الأقسام — أكتر حاجة بتتضرب في التنفيذ
- الحالات التفاعلية: جرّب الـ hover والضغط والتعطيل — مش الشكل الثابت بس
- المقاسات الثلاثة: افتح الموقع على موبايل وتابلت وديسكتوب — مش مقاس واحد
- المحتوى الحقيقي: مش النص التجريبي — حط المحتوى الفعلي وشوف الشكل
- سرعة التحميل: الصفحة بتفتح في وقت معقول؟ الصور تقيلة؟
- الأخطاء الإملائية: أيوه — دي مسؤوليتك أنت كمصمم سلمت النصوص
فن الملاحظة: إزاي تقول “ده غلط” من غير ما تخسر الشريك
الفرق بين ملاحظة محترمة وملاحظة مستفزة هو التحديد. “الصفحة دي شكلها مختلف” = ملاحظة مستفزة (بتتهم من غير دليل). “العنوان هنا 24px والمفروض 32px حسب التصميم” = ملاحظة محترمة (حقيقة قابلة للتحقق والتنفيذ). القاعدة: كل ملاحظة لازم تحتوي على 3 عناصر — المكان بالظبط (سكرين شوت مع تحديد)، القيمة الحالية، القيمة المطلوبة.
وفرّق بين نوعين من الملاحظات: أخطاء تنفيذ (حاجة مختلفة عن التصميم المعتمد — دي لازم تتصلح)، وتحسينات جديدة (فكرة خطرت لك وأنت شايف الموقع حيًا — دي مش خطأ المطور، ولو هتتنفذ يبقى بموافقة على الوقت الإضافي). خلط النوعين هو اللي بيعمل التوتر: المطور بيحس إنك بتحاسبه على حاجات مش غلطته.
لما المطور يقول “مستحيل”: بروتوكول التعامل
هتسمعها — “التصميم ده مش هيتنفذ كده”. متدخلش في جدال “أنت مش عايز تتعب نفسك”. امشِ على البروتوكول:
- افهم السبب التقني: “مستحيل” غالبًا معناها “مكلف جدًا” أو “هياخد وقت طويل” — اسأل عن السبب الحقيقي والتكلفة الحقيقية.
- اطلب البديل: “طيب إيه أقرب حاجة ممكنة؟” — المطور الشاطر هيقترح حلًا يحقق أغلب الأثر البصري بجزء من التكلفة.
- قيّم البديل بموضوعية: لو الفرق البصري بسيط والتوفير كبير — اقبل البديل. العناد على تفصيلة صغيرة بيثمن غالٍ.
- لو الفرق جوهري: ارجع للعميل بالخيارين والتكلفة — القرار قراره هو، مش معركة بينك وبين المطور.
واحفظ القاعدة الذهبية: المطور اللي بيقولك “صعب” بدري صديقك — والمشكلة في اللي بيسكت وينفذ حاجة مختلفة من غير ما يقول. شجع المطور إنه يتكلم بدري، وكافئ الصراحة بالمرونة — هتكسب شريكًا يقولك الحقيقة بدل ما يخبيها.
6 الـ Responsive والحالات الحدية: التفاصيل اللي بتكسر أي تصميم
لو فيه اختبار واحد بيفرق بين المصمم الهاوي والمحترف في عين المطور، فهو ده: هل صممت للمقاسات المختلفة والحالات المختلفة، ولا صممت شاشة واحدة مثالية وسبت الباقي؟ المطور بيبني موقعًا هيتفتح على مئات المقاسات — والمصمم اللي مديله مقاسًا واحدًا بيقوله ضمنيًا: “خمّن الباقي أنت”.
والنتيجة المتوقعة: الموقع على الموبايل شكله مختلف تمامًا عن التصميم، والنصوص الطويلة كاسرة التنسيق، والصور الناقصة سايبة فراغات قبيحة. وكل ده كان ممكن يتجنب بشوية تخطيط.
صمم 3 مقاسات: القاعدة غير القابلة للتفاوض
أي شاشة مهمة لازم تتصمم على 3 مقاسات على الأقل: موبايل (العرض الضيق — الأغلبية)، تابلت (الوسط)، ديسكتوب (العريض). ومش بس ترص نفس العناصر بمقاسات أصغر — كل مقاس له منطق مختلف:
- الموبايل: عمود واحد، الأولوية للمحتوى الأساسي، القوائم بتتحول لأيقونة، الأزرار بعرض الشاشة لسهولة اللمس.
- التابلت: منطقة رمادية — حدد بوضوح: هل بياخد سلوك الموبايل ولا الديسكتوب؟ الغموض هنا هو اللي بيعمل المشاكل.
- الديسكتوب: استغلال العرض: أعمدة متعددة، محتوى جنبًا إلى جنب — لكن بحذر من السطور الطويلة جدًا اللي بتصعب القراءة.
والأهم من المقاسات نفسها: سلوك التحول بينها. لما الشاشة تصغر تدريجيًا، إيه اللي بيحصل؟ القائمة العلوية بتتحول لأيقونة عند أي مقاس؟ العمودان بيبقوا عمودًا واحدًا إمتى؟ حدد الـ breakpoints دي مع المطور — هو هينفذها، لكن القرار التصميمي قرارك أنت.
الحالات الحدية: التصميم الحقيقي بيبان هنا
الحالة الحدية (Edge Case) هي أي وضع غير الوضع المثالي اللي صممته. والموقع الحقيقي مليان حالات حدية — المستخدمون الحقيقيون مش بيتصرفوا زي النص التجريبي المثالي بتاعك:
| الحالة الحدية | اللي بيحصل فعلًا | صمم لها إزاي |
|---|---|---|
| نص أطول من المتوقع | عنوان المنتج 5 كلمات بدل كلمتين — الكارت اتمدد وكسر الشبكة | حدد أقصى عدد أسطر + سلوك الزيادة (نقاط … أو سطر جديد) |
| صورة ناقصة | المنتج من غير صورة — فراغ رمادي قبيح | صمم placeholder أنيق: أيقونة + لون خلفية من الهوية |
| قائمة فارغة | المستخدم الجديد مفيش عنده عناصر — صفحة بيضاء | صمم Empty State: رسالة ودودة + زرار إجراء واضح |
| خطأ في التحميل | الإنترنت قطع — الصفحة علقت | صمم شاشة خطأ: توضيح المشكلة + زرار إعادة المحاولة |
| نص قصير جدًا | اسم مستخدم من حرفين — التصميم شكله فاضي | تأكد إن التصميم متماسك مع المحتوى القليل مش بس الكثير |
| لغة مختلفة | الترجمة الإنجليزية أطول أو أقصر — الكلام خرج بره الزرار | اختبر التصميم بالنصوص الفعلية بكل اللغات المدعومة |
القاعدة العملية: أي عنصر له حالة واحدة في التصميم = مفاجأة في الكود. المطور هيسألك عن الحالات دي — إما دلوقتي وأنت بتصمم (رخيص)، أو بعد الإطلاق لما المستخدمين يشتكوا (غالٍ). اختار الرخيص.
الـ RTL: التفصيلة العربية اللي بتتنسى
بما إنك بتصمم بالعربي، الـ RTL مش رفاهية — هو الأساس. لكن كتير من المصممين بيصمموا بالعربي ويسيبوا تفاصيل الانعكاس للمطور، والنتيجة أخطاء محرجة: أيقونة “التالي” بتشير شمال، شريط التقدم بيبدأ من الشمال، والأرقام والتواريخ طالعة معكوسة.
القاعدة: صمم الـ RTL من الأول مش كترجمة. الاتجاهات (يمين/شمال) في التصميم العربي معكوسة عن الإنجليزي — “التالي” عندنا بيشير شمال. والأيقونات الاتجاهية (أسهم، مشغلات) لازم تتعكس. وثّق ده في ملف التصميم عشان المطور — خصوصًا لو بيستخدم أدوات أجنبية — ميغلطش.
7 الشراكة التجارية: مصمم + مطور = فريق مشاريع كاملة
لحد هنا اتكلمنا عن الشراكة “الفنية” — إزاي تشتغلوا مع بعض. دلوقتي نتكلم عن الشراكة “التجارية” — إزاي تكسبوا مع بعض. لأن فيه حقيقة سوقية بسيطة: العميل مش عايز تصميمًا — عايز موقعًا شغالًا. والمصمم لوحده بيقدم نصف المنتج، والمطور لوحده بيقدم النصف التاني. الاتنين مع بعض بيقدموا المنتج الكامل — والمنتج الكامل بيتباع بسعر أعلى بكتير من مجموع النصفين.
ليه العميل بيفضل الفريق الجاهز؟
حط نفسك مكان صاحب البيزنس: محتاج موقع لشركته. الخيار الأول: يتعاقد مع مصمم، يستنى التصميم، وبعدين يدور على مطور، ويبقى هو الوسيط بينهم لما يختلفوا. الخيار التاني: يتعاقد مع فريق “مصمم + مطور” بيشتغلوا مع بعض من زمان، يستلم موقعًا شغالًا، ويتعامل مع شخص واحد. أي خيار هيختار؟ التاني — حتى لو أغلى. لأنه بيشتري راحة البال مش بس الموقع.
وده معناه إن الشراكة بينك وبين مطور شاطر مش مجرد “تعاون لطيف” — هي ميزة تنافسية بتخليكم تاخدوا مشاريع لا المصمم لوحده ولا المطور لوحده يقدروا ياخدوها. مشاريع المواقع الكاملة، المتاجر الإلكترونية، منصات الحجوزات — كل دي مشاريع “فريق” مش مشاريع “فرد”.
3 نماذج للشراكة التجارية (اختار اللي يناسبك)
أبسط نموذج: مشروع يجيلك (أو يجيله) وتتقاسموه. أنت التصميم وهو التطوير، والعميل بيتعامل مع واحد فيكم كمسؤول رئيسي. القسمة العادلة بتتحسب من حجم الشغل الفعلي: كل واحد يقدّر ساعاته × سعر ساعته، والمجموع يتقسم بالنسبة دي. مثال افتراضي: موقع تعريفي — التصميم 40 ساعة × 300 = 12,000، والتطوير 60 ساعة × 300 = 18,000 — يبقى التقسيم 40% للمصمم و60% للمطور من إجمالي المشروع.
المهم: الاتفاق مكتوب قبل الشغل — مين مسؤول عن إيه، ومين بيستلم من العميل ويوزع، وإيه اللي يحصل لو العميل طلب شغلًا خارج النطاق. الفلوس الشفهية بتخرب أجمل الشراكات.
بدل ما تستنوا المشاريع تجيلكم، ابنوا منتجًا مشتركًا: “باقة الموقع التعريفي الكامل”، “باقة المتجر الإلكتروني”، “باقة صفحة الهبوط”. كل باقة لها نطاق واضح وسعر ثابت ومدة محددة — أنت عارف دورك وهو عارف دوره. الباقات بتتباع أسهل من الخدمات المفتوحة لأن العميل شايف بالظبط هياخد إيه وبكام.
مثال افتراضي لباقة: “موقع تعريفي كامل — 5 صفحات: تصميم UI مخصص + تطوير responsive + نموذج تواصل + ربط الإحصائيات — تسليم خلال 3 أسابيع”. الباقة دي كمنتج جاهز بتتباع أسرع بكتير من “مصمم ومطور متاحان للمشاريع”.
أقوى نموذج على المدى الطويل: عميل واحد (شركة أو جهة) بيحتاج تصميمًا وتطويرًا بشكل مستمر — تحديثات الموقع، صفحات جديدة، حملات موسمية. تعرضوا عليه اشتراكًا شهريًا: عدد ساعات تصميم + عدد ساعات تطوير بسعر ثابت كل شهر. العميل بيضمن فريقًا جاهزًا، وأنتم بتضمنوا دخلًا ثابتًا.
النموذج ده بيحتاج ثقة مبنية على مشاريع ناجحة سابقة — مبيتباعش من أول تعارف. ابنوه تدريجيًا: مشروع واحد ناجح، ثم التاني، ثم اعرض الـ retainer.
إزاي تلاقي المطور الشريك الصح؟
الشريك الغلط أسوأ من مفيش شريك. المطور الشريك مش بس “شاطر في الكود” — لازم يكون محترمًا في التعامل: بيرد بسرعة، بيلتزم بالمواعيد، وبيتكلم معاك باحترام لما يختلف معاك في التصميم. المهارات التقنية ممكن تتقيم من معرض الأعمال — لكن الاحترافية في التعامل مش بتبان إلا بالتجربة.
عشان كده القاعدة: ابدأوا بمشروع تجريبي صغير قبل أي التزام. مشروع حقيقي صغير (صفحة هبوط، موقع بسيط) هيكشف كل حاجة: سرعة التواصل، جودة الشغل، طريقة التعامل مع الخلافات، والالتزام بالمواعيد. لو المشروع الصغير نجح بسلاسة — عندكم شراكة. لو كان متعبًا — أحسن تكتشف ده في مشروع صغير من مشروع كبير مع عميل حقيقي.
وفين تلاقيه؟ ابدأ من دائرتك — مطورين اشتغلت معاهم قبل كده وكان التعامل مريحًا. بعدهم: مجتمعات التقنية، منصات العمل الحر (دور على تقييمات عالية في نفس تخصصك)، وتوصيات المصممين التانيين. الشريك الكويس غالبًا بيجي بالتوصية مش بالإعلان.
عقد الشراكة: الكلام الحلو مش كفاية
حتى مع أقرب صديق، الشراكة التجارية محتاجة اتفاقًا مكتوبًا. مش عقد 20 صفحة — صفحة واحدة واضحة فيها:
- تقسيم الأدوار: مين مسؤول عن إيه بالظبط — التصميم والتطوير والمحتوى وإدارة العميل.
- تقسيم الفلوس: النسبة أو طريقة الحساب — وميعاد التوزيع (بعد استلام كل دفعة من العميل).
- إدارة العميل: مين نقطة التواصل الرئيسية — العميل اللي بيكلم اتنين بيستغل الاتنين.
- التعديلات الخارجة عن النطاق: مين يقدّر تكلفتها ومين ينفذها — عشان متتحولش لخلاف.
- الخروج: لو حد عايز ينسحب من الشراكة — إيه الإجراء؟ الكلام ده سهل في البداية وصعب جدًا في النهاية.
8 7 أخطاء قاتلة في شراكة المصمم والمطور
دول مش نظريات — دي أخطاء بتتكرر يوميًا وبتكلف مشاريع حقيقية. كل خطأ تحته التكلفة والبديل:
التكلفة: المطور بيضيع أيام في فهم الملف بدل ما يبني — وبعدين بينفذ غلط لأن “القرار مش واضح”. وأنت بتضيع أيام في مراجعة أخطاء كان ممكن تتجنب.
البديل: نظام الـ handoff من القسم الثالث: تسمية، صفحة تغطية، فصل النهائي عن المسودات، Styles موحدة، Components، وAuto Layout — قبل ما تبعت اللينك.
التكلفة: تصميم معتمد من العميل ومستحيل التنفيذ بنفس الشكل — فإما إعادة تصميم (وإحراج قدام العميل)، أو تنفيذ مشوه، أو تكلفة إضافية ضخمة.
البديل: مراجعة المطور المبكرة قبل الاعتماد + فهم قيود البرمجة من القسم الثاني. صمم داخل منطقة الممكن — والإبداع الحقيقي هو الجمال داخل القيود.
التكلفة: كل مشكلة تقنية بتتكشف متأخرًا = تعديل على تصميم معتمد = إحراج + تكلفة + تأخير. والمطور بيحس إنه “منفذ” مش “شريك” — فبيتعامل ببرود.
البديل: المطور شريك من أول المشروع: مراجعة سريعة للتصميم قبل الاعتماد، ومشاركة في تقدير الوقت. الشريك المبكر بيحميك — والمنفذ المتأخر بيفاجئك.
التكلفة: المطور بنى على التصميم القديم وأنت غيرت الجديد — شغل اترمى، ووقت ضاع، وغضب مكتوم بيتراكم لحد ما ينفجر في مشروع تاني.
البديل: تجميد التصميم قبل التنفيذ — وأي تعديل بعده يتوثق في الملف أولًا، ويتبلغ للمطور رسميًا، مع تقدير لتكلفة التعديل. التعديل الشفهي ممنوع.
التكلفة: موقع شكله ممتاز على شاشتك وكارثة على موبايل العميل — والعميل بيفتح من الموبايل. والنصوص الطويلة والصور الناقصة بيكسروا التنسيق قدام المستخدمين الحقيقيين.
البديل: 3 مقاسات لكل شاشة مهمة + تصميم الحالات الحدية (نص طويل، صورة ناقصة، قائمة فارغة، خطأ تحميل) — من القسم السادس.
التكلفة: ملاحظات ضايعة في الشات، قرارات منسية، “أنا قولتلك” مقابل “محدش قالي” — وفوضى بتكبر مع حجم المشروع.
البديل: قناة تواصل واحدة متفق عليها: تعليقات Figma للملاحظات البصرية (مرتبطة بالعنصر نفسه)، وتوثيق مكتوب للقرارات. الشات للطوارئ فقط — مش لإدارة المشروع.
التكلفة: “ممكن تغير دي بسرعة؟” كل يوم = مطور مشتت ومشروع متأخر. و”الموقع لسه مخلصش ليه؟” كل يوم = مصمم مضغوط ومطور محبط. الاحترام المتبادل للوقت هو وقود الشراكة.
البديل: دفعات تعديلات مجمعة بمواعيد ثابتة — مش تعديلات لحظية. وجدول زمني واقعي يحترم وقت الطرفين. الشراكة اللي فيها طرف بيستنزف وقت التاني مش بتكمل.
الأخطاء السبعة دي لها جذر واحد: التعامل مع المطور كـ”منفذ” بدل “شريك”. اللي بيبني نظامًا للتعاون — handoff منظم، تواصل موثق، مراجعة مبكرة، واحترام متبادل — بيكسب شريكًا يخليه يشتغل أسرع ويبيع أغلى. واللي بيتعامل بمنطق “أنا أصمم وأنت تنفذ واسكت” بيخسر أحسن حليف ممكن.
خطة أول شراكة: امشِ عليها بالترتيب
- اتعلم الأساسيات: افهم قيود البرمجة من القسم الثاني — مش عشان تكتب كود، عشان تصمم صح.
- نظم ملفاتك: طبق نظام الـ handoff على مشروعك الحالي — سمِّ، وثّق، واعمل Components.
- ابنِ لغة مشتركة: ابدأ صفحة Style Guide بـ tokens مسماة — نواة الـ Design System بتاعك.
- لاقِ الشريك: مطور واحد شاطر ومحترم — واختبروه بمشروع تجريبي صغير.
- اتفقوا كتابة: الأدوار والفلوس وإدارة العميل — قبل أول مشروع حقيقي.
- ابنوا باقة مشتركة: منتج واحد واضح بسعر ثابت — وبيعوه مع بعض.
الشراكة الأولى هي الأصعب — بعدها هيبقى عندكم نظام يتكرر. ومشروع واحد ناجح معًا أقوى من أي كلام في بناء الثقة بينكم وبين العملاء.
مصادر للتعمق (روابط مباشرة)
- وضع المطور في Figma — Dev Mode مجاني
الصفحة الرسمية لوضع المطور: فحص المقاسات والألوان، استخراج أكواد CSS، وتعليم التصاميم الجاهزة للتنفيذ — الأداة الأساسية للـ handoff الحديث. - كتاب Atomic Design — براد فروست مجاني
الكتاب الكامل مجانًا على الإنترنت: منهجية بناء الـ Design Systems من الذرات للصفحات — المرجع النظري الأهم للقسم الرابع. - منصة Storybook لبناء مكونات الواجهة مجاني
ورشة بناء وتوثيق واختبار مكونات الواجهة بمعزل عن التطبيق — مفتوحة المصدر ومجانية، وتتكامل مع Figma. - منصة Zeplin لتسليم التصميم Mostly Free
مساحة منظمة لتسليم التصميم للمطورين: مواصفات جاهزة، تتبع النسخ، وتوثيق — مفيدة خصوصًا لو المطور مش بيستخدم Figma. - منصة Tokens Studio للـ Design Tokens Mostly Free
إدارة الـ design tokens ومزامنتها بين Figma والكود — اللغة المشتركة بين التصميم والبرمجة موثقة عمليًا. - نظام Material Design 3 من جوجل مجاني
نظام التصميم المفتوح المصدر من جوجل: مكونات وتوكنز وأدلة استخدام — مثال حي على Design System متكامل بين التصميم والكود. - مرجع MDN Web Docs للويب مجاني
المرجع الأشمل للـ CSS وتقنيات الويب — للمصمم اللي عايز يفهم قيود البرمجة من المصدر الموثوق. - أبرز مشاكل العمل الحر والحلول المقترحة لها — أكاديمية حسوب مجاني
مقال عربي عن مشاكل المستقلين مع العملاء والشركاء: الطلبات الخارجة عن الاتفاق، إلغاء المشروع من المنتصف، وتأخر المستحقات — والحلول العملية. - كتاب “دليل المستقل والعامل عن بعد” — أكاديمية حسوب مجاني
كتاب حسوب المجاني: فصول عن التعامل مع العملاء والشركاء، وإدارة المشاريع المشتركة — مرجع عربي شامل للمستقل.
خطوتك الأولى النهاردة
متقفلش الدليل ده وتقول “هطبقه لما ألاقي مطور”. ابدأ من عندك:
افتح آخر ملف Figma اشتغلت عليه وسمِّ 10 طبقات بأسماء واضحة — أول خطوة في نظام الـ handoff بتاعك. وبعدين ابعت لمطور تعرفه: “تعال نجرب نشتغل مع بعض في مشروع صغير”.
؟ الأسئلة الشائعة
هل لازم المصمم يتعلم برمجة فعلًا عشان يتعامل مع المطورين؟
لا — مش مطلوب تبقى مطور، لكن مطلوب تفهم قيود البرمجة. المصمم اللي فاهم يعني إيه box model ويعني إيه responsive وإن الخطوط على الويب سلوكها مختلف عن برامج التصميم، بيصمم حاجات قابلة للتنفيذ من أول مرة. الهدف مش كتابة كود، الهدف إنك تبطل تصمم حاجات مستحيلة التنفيذ أو مكلفة جدًا. ساعة واحدة في فهم CSS أساسيات توفر عليك أسابيع من التعديلات.
إيه هو الـ handoff وإمتى يبدأ بالظبط؟
الـ handoff هو عملية تسليم التصميم للمطور بشكل منظم: ملف Figma مسمّى ونظيف، مكونات components جاهزة، مقاسات ومواصفات واضحة، ملفات جاهزة للتصدير، وتوثيق للحالات المختلفة لكل عنصر. والغلطة الشائعة إنه بيبدأ متأخر — الصح إنه يبدأ من أول المشروع: المطور يشارك في مراجعة التصميم قبل الاعتماد، عشان يقولك إيه الصعب وإيه المكلف قبل ما تبني عليه.
المطور بيقول لي التصميم ده صعب التنفيذ — أعمل إيه؟
متتخانقش ومتستسلمش فورًا — اسأل: صعب ليه؟ بالظبط إيه الجزء المكلف؟ كتير من الحاجات اللي بتبان صعبة لها بديل أرخص يحقق نفس الأثر البصري. اطلب من المطور يقترح البديل بدل ما يرفض الفكرة كلها. ولو البديل هيغيّر الشكل جوهريًا، ارجع للعميل بالخيارين: التصميم الأصلي بتكلفة أعلى ووقت أطول، أو البديل المقترح. القرار للعميل — مش معركة بينك وبين المطور.
هل Figma Dev Mode يغني عن الشرح والتواصل مع المطور؟
لا. Dev Mode أداة ممتازة — بيطلع المقاسات والألوان وأكواد CSS جاهزة — لكنه مش بديل عن التواصل. الأداة بتنقل القيم، لكنها مش بتنقل القرارات: ليه الزر ده كده؟ إيه اللي يحصل لما النص يطول؟ إيه سلوك العنصر على الموبايل؟ الحاجات دي محتاجة توثيق وكلام. استخدم Dev Mode كقاعدة، وضيف عليه صفحة ملاحظات في الملف واجتماع تسليم قصير — كده التغطية كاملة.
إزاي أتعامل مع تعديلات التصميم بعد ما المطور بدأ التنفيذ؟
القاعدة: التعديل بعد بدء التنفيذ له تكلفة حقيقية — مش مجرد تحريك عنصر في Figma. قبل أي تعديل اسأل المطور: التعديل ده هياخد وقت قد إيه؟ وبناءً عليه قرر: تعديل بسيط يتنفذ فورًا، تعديل متوسط يتجمع مع دفعة تعديلات، تعديل كبير يعني إعادة تقدير للوقت والسعر. ووثّق التعديل في ملف التصميم أولًا وبعدين بلّغ المطور — العكس (تعديل شفهي) هو اللي بيعمل الكوارث.
مين المسؤول عن الـ responsive: المصمم ولا المطور؟
الاتنين — بس بأدوار مختلفة. المصمم مسؤول عن تصميم 3 مقاسات على الأقل (موبايل وتابلت وديسكتوب) وتحديد سلوك العناصر بينهم: إيه اللي بيختفي؟ إيه اللي بيتكدس فوق بعضه؟ والمطور مسؤول عن تنفيذ السلوك ده بدقة عبر الـ breakpoints. الغلطة الشائعة إن المصمم يصمم مقاس واحد ويسيب الباقي لتخمين المطور — والنتيجة موقع مختلف تمامًا على الموبايل. صمم المقاسات التلاتة من الأول.
إيه الـ design tokens ببساطة ومن غير تعقيد؟
الـ tokens هي أسماء للقيم المتكررة في التصميم بدل القيم نفسها. بدل ما اللون الأزرق مكتوب كـ #2563EB في 50 مكان، بيتسمى primary-500 ويتخزن مرة واحدة. لما العميل يطلب تغيير اللون، التغيير بيحصل في مكان واحد وينعكس على التصميم والكود معًا. هي أبسط فكرة في الـ Design System وأقوى فكرة: لغة مشتركة بين ملف Figma وملفات الكود.
كمصمم مستقل: ألاقي مطور شريك منين؟
ابدأ من دائرتك: مطورين اشتغلت معاهم قبل كده وكان التعامل مريحًا. بعدهم: مجتمعات المصممين والمطورين العرب، ومنصات العمل الحر (ابحث عن مطور بتقييمات عالية في نفس تخصصك)، وفعاليات التقنية المحلية. الاختبار الحقيقي مش في الكلام — اعملوا مشروعًا تجريبيًا صغيرًا مع بعض قبل أي التزام. الشراكة الناجحة بتتبني على مشروع صغير ناجح، مش على وعود كبيرة.
نقسم الفلوس إزاي في المشاريع المشتركة بين المصمم والمطور؟
مفيش نسبة سحرية ثابتة — القسمة العادلة بتتبني على حجم الشغل الفعلي لكل طرف في المشروع ده بالذات. الطريقة العملية: كل واحد يقدّر ساعاته وسعر ساعته، والمجموع يتقسم بالنسبة دي. والمهم يتكتب قبل الشغل: مين مسؤول عن إيه، وإيه اللي يحصل لو العميل طلب تعديلات خارج النطاق، ومين بيستلم الفلوس من العميل ويوزعها. الاتفاق الشفهي على الفلوس هو أسرع طريق لخسارة الشريك.
المطور غيّر في التصميم من غير ما يقول لي — أتصرف إزاي؟
أول حاجة: متفترضش سوء نية — غالبًا غيّر عشان حاجة تقنية اضطرته، أو عشان التصميم كان ناقص تفصيلة وهو خمّن. اسأله بهدوء: لاحظت إن الجزء ده مختلف عن التصميم — إيه السبب؟ لو السبب تقني، ناقشوا البديل مع بعض. لو كان اجتهادًا شخصيًا، اتفقوا على قاعدة: أي تغيير بصري يرجع للمصمم أولًا. والحل الجذري: مراجعة بصرية منظمة قبل الإطلاق — Visual QA — تلقط الفروقات دي بدري.
هل أحتاج Zeplin لو بستخدم Figma Dev Mode؟
لو فريقك كله على Figma وDev Mode مغطي احتياجكم، فغالبًا لا. Zeplin كان الحل قبل ما Figma يطور Dev Mode — وهو لسه مفيد لو بتتعامل مع مطورين مش بيستخدموا Figma، أو لو عايز مساحة تسليم منظمة منفصلة عن ملف التصميم الحي اللي بيتغير باستمرار. القاعدة: اختار أداة واحدة للتسليم والتزم بيها — التشتت بين أداتين أسوأ من أي نقص في أداة واحدة.
إزاي أراجع شغل المطور (Visual QA) من غير ما أبقى متسلط؟
المراجعة البصرية مش تفتيش — هي جزء متفق عليه من العملية. من الأول اتفقوا إن فيه مرحلة مراجعة قبل الإطلاق، وجهز قائمة فحص واضحة: المقاسات، الألوان، الخطوط، المسافات، سلوك الـ hover، والمقاسات المختلفة للشاشات. ولما تلاقي فرقًا، صوّره وحدد مكانه بالظبط واقترح القيمة الصحيحة — مش لاحظ إن الشكل مختلف. الفرق بين المتسلط والمحترف: الأول بيقول ده وحش، والتاني بيقول الزر هنا 16px والمفروض 20px.