عندما يأتيني عميل كويتي يشتكي من أن فريقه ينهي المشروع بـ 30% تأخير عن الموعد، أول سؤال أطرحه: "كيف تنقل التصاميم من المصمم إلى المطور؟" في 80% من الحالات، الإجابة هي: نفس الطريقة القديمة. المصمم ينشر صورة Figma، والمطور ينسخ ويعيد كتابة كل شيء يدوياً.
هذا ليس كسول — هذا طبيعي في سوق حيث معظم الفرق الصغيرة والمتوسطة لم تُركز على العملية أبداً.
لماذا النقل اليدوي يُغرق مشاريعك
تخيل هذا: مصمم ينهي شاشة جديدة في Figma. يعطيها للمطور. المطور ينظر لـ Figma، ثم يكتب CSS من الصفر. يَخمِّن هوامش الـ Padding، يُقدّر حجم الخط، يختبر في متصفح، ثم يكتشف أن الـ Spacing لا يطابق. يرجع المصمم، يسأل — والمصمم يقول "آه، كان المفروض تكون 16px وليس 12px."
الآن كرر هذا 40 مرة في المشروع الواحد.
من تجربتي في قيادة مشاريع في الكويت والخليج، هذه الدورة تأكل 3-4 أسابيع من التطوير في مشروع متوسط الحجم. وأحياناً — حين يكون الـ Bandwidth منخفض وتأتي تعديلات من الـ Client — تصير 6 أسابيع.
الحل ليس أن تجد مصممين أفضل أو مطورين أسرع. الحل أن تقضي على هذه النقطة تماماً من العملية.
كيف يبدو Figma-to-Code الصحيح
النموذج الأفضل الذي رأيته يعتمد على ثلاث دعائم:
Design System في Figma
كل العناصر الأساسية (Colors, Fonts, Components, Spacing Scale) معرّفة مرة واحدة. المصمم لا يخترع spacing جديد في كل شاشة — يستخدم الـ System نفسه.
Figma Tokens أو Plugin
أداة تُصدّر Color Palette والـ Typography والـ Spacing من Figma مباشرة إلى JSON أو CSS. لا يدوي، لا أخطاء.
Code Generation + Manual Polish
أداة تأخذ المكوّنات من Figma وتولّد React/HTML+CSS الأولي. المطور يُصيح الـ Logic والـ Interactivity، لا الـ Styling.
النتيجة: من 30 يوم إلى 8 أيام — بدون أخطاء spacing.
الأدوات التي تعمل فعلاً
أنا اختبرت كل شيء تقريباً. إليك ما يعمل في حالات حقيقية:
1. Figma Tokens (للـ Design System)
Figma Token هو plugin رسمي من Figma نفسها. بتعريف كل الألوان والخطوط والـ Spacing مرة واحدة في JSON منظم، ثم تُصدّرها إلى Tailwind، CSS Variables، أو حتى SwiftUI. لا يوجد نسخ يدوي.
في مشروع التطوير الأخير، استخدمنا Tokens مع Tailwind. قطعنا 40% من وقت الـ CSS.
2. Penpot (إذا أردت بديلاً مفتوح المصدر)
إذا كنت تريد حراً من Figma، Penpot جيدة جداً. لديها نفس الـ Features تقريباً وعندها Export أفضل.
3. Copilot + Cursor (للـ Code Generation)
أحدث طريقة أشوفها مع فرقي: المصمم ينهي شاشة في Figma، والمطور يفتح Cursor (أو Copilot في VS Code)، يلصق صورة Figma مع التعليمات، والـ AI يولّد 80% من الـ HTML+CSS.
المطور بعدها يصحح الـ Logic وأي edge case، لكن الـ Scaffolding خلصت.
4. Storybook + Chromatic (للـ Review)
لما تنقل كود من Figma، تحتاج طريقة تتأكد أنه يطابق. Chromatic (مختبرات بصرية) تُقارن screenshot من Figma مع screenshot من الـ Live Component. أي اختلاف، تشوفه فوراً.
📌 من تجربتي المباشرة
في مشروع كان فيه Client في الإمارات يطلب تعديلات يومية على التصميم — استخدمنا Chromatic مع Storybook، والـ QA اكتشفت عدم المطابقة قبل الـ Staging. اختصرت عدة أيام من الـ Debugging.
العملية من البداية إلى النهاية
1. Setup Design System (أسبوع واحد)
المصمم ينظم كل الألوان، الخطوط، والـ Spacing في Figma. هذا يحدث مرة واحدة. استخدم Figma Tokens plugin لتسهيل الأمر.
2. Export Tokens (يومي / لما يتغيير Design System)
أداة تُصدّر الـ Tokens إلى JSON أو CSS Variables. تُحط في Repository حتى المطورين يستخدموها.
3. Design الشاشات (عادي، كما هي)
المصمم يصمم. لكن هذه المرة كل shape وcolor وfont موجود في الـ System. لا يخترع معايير جديدة.
4. Screenshot للمراجعة
لما المصمم ينهي شاشة، يأخذ screenshot. يرفعها في Figma comment (أو Slack) مع link للـ Component.
5. Developer ياخذ الـ Screenshot
يفتح Cursor أو Copilot، يلصق الصورة مع التعليمات: "اعمل React component يطابق هذا التصميم، استخدم التوكنز من styles/tokens.json"
6. AI يولّد 80% من الكود
الـ AI يكتب JSX+CSS. قد لا يكون كامل، لكنه يطابق الـ Design تقريباً.
7. Developer يُصيح ويضيف Logic
يُقارن مع screenshot، يصحح أي اختلافات صغيرة، يضيف الـ Interactivity (clicks، forms، إلخ).
8. Chromatic / Visual Tests
تُشغّل automated visual tests. أي اختلاف عن الـ Design، تاخذ screenshot والـ QA تشوفه قبل الـ Deploy.
ماذا لو فريقك صغير؟
أنا أفهم. ليس كل team عندها مصمم + مطور + QA. بعض الشركات الصغيرة في الكويت الشخص نفسه يعمل design و coding.
في هذه الحالة، تركيزك يكون على الحاجات الأساسية: Design System واحد، بدون ارتجال. إذا كان عندك design tokens في CSS Variables أو Tailwind config، أنت فعلاً بتقضي على 80% من المشاكل.
الأدوات المتقدمة (Chromatic, Code Generation AI) تكون اختيارية. الأساس هو: لا تخترع spacing جديد في كل صفحة.
الأسعار والـ ROI
إذا كنت تفكر في توظيف أدوات جديدة، الحساب بسيط:
Figma Tokens: مجاني (plugin رسمي)
Storybook: مجاني (open source)
Chromatic: $90-300 شهرياً (حسب الـ Snapshots)
Cursor أو Copilot Pro: $20 شهرياً
لو الفريق 5 مطورين، وكل واحد ياخذ أسبوع واحد في كل مشروع في نقل التصاميم يدوياً — هذا 5 أسابيع مرتب = 20,000-25,000 دينار كويتي إجمالي سنوياً (بمتوسط راتب 4000-5000 دينار).
الأدوات السابقة بمجموعها = 3,000 دينار سنوياً. الـ ROI واضح جداً.
💡 نقطة مهمة: أدوات بدون عملية = لا فائدة
رأيت شركات تشتري Chromatic ثم لا تستخدمه لأن فريقهم ما عندهم Storybook أصلاً. أدوات بدون عملية مُحددة وموارد مُلزمة = مصروف إضافي. ابدأ بـ Design System والعمليات. الأدوات تأتي بعدها.
الأخطاء الشائعة اللي شفتها
الخطأ الأول: المصمم يصمم بـ "حرية مطلقة" — fonts مختلفة، spacing عشوائي. بعدها الفريق تفاجأت أن النقل صعب. الحل: Design System من البداية.
الخطأ الثاني: شراء أداة code generation بدون فهم أنها توّلد فقط الـ Structure الأساسي، لا الـ Logic. بعدها يقول الـ Developer "الأداة ما تشتغل." بلاش، الأداة كويسة — الـ Expectation غلط.
الخطأ الثالث: Figma و Repository بدون synchronization. المصمم يعدّل Figma، لكن الـ Code عندها نسخة قديمة. بعدها في confusion. الحل: Tokens تُصدَّر تلقائي (زي Git hooks).
الخطوة التالية
إذا أنت ready تطبق هذا:
الأسبوع الأول: نظّم Design System في Figma. ركز على الألوان والخطوط والـ Spacing فقط. لا تعقّد.
الأسبوع الثاني: استخدم Figma Tokens لتصدّر هذا إلى CSS Variables أو Tailwind config. جرب في مشروع صغير أولاً، لا كل شيء.
الأسبوع الثالث: أضف أداة review (Storybook بدون Chromatic الأول — Chromatic بعدها إذا كان عندك Budget).
الشهر الثاني: اختبر AI code generation مع Cursor. ما كل أداة تناسب كل فريق — جرب.
تذكر: الهدف ليس التكنولوجيا. الهدف أن تقطع أسابيع من الوقت المهدر وتسلّم بسرعة وبدون أخطاء Spacing. التكنولوجيا مجرد أداة لتحقيق ده.