تسليم التصميم والهندسة: ما وراء تعليقات Figma
لماذا لا تستطيع تعليقات Figma وحدها سد فجوة تسليم التصميم والهندسة، وما الذي يصلح فعلاً للفرق الصغيرة.
By Ellis Keane · 2026-04-06
أفضل أداة لتسليم التصميم والهندسة هي التي لا يفتحها المهندسون قط
كلما استثمر المصممون أكثر في إتقان تسليم Figma – التخطيط التلقائي، رموز التصميم، تعليقات وضع المطوّر، توثيق المكوّنات – كلما ساءت عملية تسليم التصميم والهندسة الفعلية في الغالب. ليس لأن التصميم رديء – بل هو رائع في الغالب – لكن كل ذلك الجهد يقيم داخل أداة يزورها المهندسون على مضض، يتصفحونها سريعاً، ثم يغلقونها ليبنوا ما ظنّوا أنهم رأوه.
لقد كنت على كلا الجانبين. بدأت مصمماً (بالمعنى المتساهل – كنت أبني مواقع متاجر الرهن في نيو هامبشاير، فلنتسامح مع اللقب)، والآن أكتب معظم الكود الهندسي في Sugarbug. مشكلة تسليم التصميم والهندسة ليست مشكلة أدوات، بل مشكلة سير العمل. المعلومات موجودة، لكنها في المكان الخطأ في الوقت الخطأ.
يبدو تسليم التصميم والهندسة النموذجي هكذا: يقضي المصمم ثلاثة أيام في صقل إطار Figma، يضيف اثنتي عشرة تعليقة تشرح قرارات التباعد والحالات الحدية، يضع وسماً على المهندس، ثم ينتظر. يفتح المهندس Figma، يطالع الإطار نحو تسعين ثانية، يفكر "حسناً، فهمت"، يغلق التبويب، ويبني شيئاً صحيحاً بنسبة ٨٠٪ وخاطئاً بنسبة ٢٠٪ بطرق ستستغرق أسبوعاً آخر من الردود المتبادلة لحلها. التعليقات الاثنتا عشرة؟ قُرئت منها أربع على الأرجح.
تسليم التصميم والهندسة ليس ملفاً يُقذف فوق الجدار. إنه سياق يجب أن يعيش حيث يعمل المهندس – في القضية، في PR، في الكود – لا في أداة تصميم يزورها مرةً واحدة.
لماذا تعليقات Figma شكلٌ خاطئ للتسليم
أستخدم Figma كل يوم وأستمتع بها حقاً (وهو على الأرجح عيبٌ في الشخصية في هذه المرحلة). لكن تعليقات Figma مُحسَّنة للتعاون بين المصممين، لا لتسليم التصميم والهندسة، والفارق أهم مما تدرك معظم الفرق.
جوهر عدم التطابق هو هذا: تعليقات Figma مثبَّتة مكانياً بالإطارات والمكوّنات. وهي موجودة داخل ملف التصميم. لكن المهندسين لا يعملون داخل ملفات التصميم – يعملون في قضايا Linear وطلبات GitHub PR وبيئة التطوير الخاصة بهم. حين يترك مصمم تعليقة على إطار تقول "يجب أن تنطوي هذه القائمة المنسدلة على الشاشات المحمولة التي يقل عرضها عن ٦٤٠ بكسل"، تلك المعلومة محبوسة الآن في Figma. لا تتحول إلى مهمة. لا تظهر في سير عمل المهندس. تعيش في كون موازٍ يجب على المهندس أن يتذكر زيارته، و(وهنا يكمن جوهر المسألة) زيارة Figma ليست جزءاً من حلقة العمل الطبيعية للمهندس كما هو التحقق من Linear أو مراجعة طلبات PR.
النتيجة متوقعة: تضيع القرارات التصميمية الحيوية، ليس لأن أحداً مهمل، بل لأن المعلومة في الأداة الخطأ. الأمر كأنك تترك ورقة لاصقة على مكتب شخص يعمل من المنزل.
أين يترك المصممون السياق
- تعليقات Figma – مكانية، مثبَّتة بالإطارات
- تعليقات وضع المطوّر في Figma – تفصيلية لكنها تستلزم فتح Figma
- خيوط Slack – حوارية، يصعب البحث فيها بعد أسبوع
- توثيق نظام التصميم – شامل لكن نادراً ما يُراجع في منتصف السبرنت
أين ينظر المهندسون فعلاً
- وصف قضية Linear – أول ما يقرؤونه قبل البدء
- وصف GitHub PR – مرجع أثناء التنفيذ
- تعليقات الكود – تُكتشف أثناء المراجعة
- بيئة التطوير IDE – حيث يمضون ٩٠٪ من وقتهم
ما يصلح فعلاً (من شخص يؤدي كلا الدورين)
خلال العام الماضي من بناء Sugarbug، كنت المصمم و(في معظم الأحيان) المهندس أيضاً، مما يعني أنني مررت بتجربة غريبة وهي تسليم العمل لنفسي ومع ذلك أفقد السياق. إذا لم أتذكر قراراتي التصميمية من الثلاثاء الماضي، فليس بمقدور مهندس مستقل بأي حال أن يستوعب كل شيء من خيط تعليقات Figma.
إليك ما نجح فعلاً في عملية تسليم التصميم والهندسة لدى فريقنا، ولا شيء منه له علاقة بكتابة تعليقات Figma أفضل.
١. اكتب قرار التصميم في القضية لا في ملف التصميم
قبل أن يبدأ المهندس في البناء، يجب أن يعيش سياق التصميم في قضية Linear (أو أي أداة يستخدمها فريقك). ليس رابطاً لملف Figma مع "انظر التصاميم" – هذا تهرب يعرفه الجميع. يجب أن تتضمن القضية:
- ماذا: لقطة شاشة أو إطار مُصدَّر (لا رابط Figma – ملف PNG يمكن للمهندس رؤيته دون فتح أداة أخرى)
- لماذا: المنطق وراء القرارات الرئيسية. "اخترنا لوحة الانزلاق الجانبي بدلاً من النافذة المنبثقة لأن المستخدم يحتاج الرجوع إلى القائمة أثناء التحرير" – جملة واحدة توفر ثلاث جولات من "لماذا لا نافذة منبثقة؟"
- الحالات الحدية: ماذا يحدث على الهاتف؟ مع النص الطويل؟ حين لا توجد بيانات؟ إن فكّرت، اكتب. إن لم تفكّر، قل ذلك (بصدق، "لم أحسم حالة الفراغ بعد" أنفع من الصمت)
٢. مراجعات التصميم تجري في القضية لا في Figma
حين أتلقى ملاحظات تصميمية أثناء التنفيذ، أريدها في خيط قضية Linear، لا كتعليقة Figma قد لا أراها لمدة يومين. القضية هي مصدري الوحيد للحقيقة بشأن العمل – إذا عاشت الملاحظة هناك، سأراها في المرة التالية التي أفحص فيها القضية، وهو ما يحدث عدة مرات يومياً. أما إذا عاشت في Figma، فسأراها حين أفتح ذلك الملف، وقد يكون ذلك في يوم لا يأتي.
هذا لا يعني الإقلاع عن تعليقات Figma كلياً. إنها رائعة للتعاون بين المصممين، وتعليق تفاصيل بصرية بعينها، والحوار حول التصميم ذاته. لكن حين تصبح الملاحظة "يجب على المهندس تغيير شيء ما"، عليها الانتقال إلى سير العمل الهندسي.
stat: "معظم" headline: "ظلّت تعليقات Figma دون أن تُرى لأكثر من ٤٨ ساعة حين اعتمدنا عليها في التسليم" source: "تجربة فريقنا على مدى ٣ أشهر من التتبع غير الرسمي"
٣. أغلق الحلقة بلقطات الشاشة لا بالافتراضات
أرخص أشكال التحقق في تسليم التصميم والهندسة هو لقطة الشاشة. حين ينتهي المهندس من تنفيذ مكوّن، يلصق لقطة شاشة في PR أو القضية ويضع وسماً على المصمم. "هل هذا يطابق؟" يستغرق عشر ثوانٍ ويلتقط ٢٠٪ من الانحراف قبل الإطلاق. لا اجتماعات، لا طقوس مقارنة Figma – مجرد PNG وسؤال.
بدأنا نفعل هذا في كل PR لواجهة المستخدم، وانخفض عدد محادثات "هذا لا يطابق التصميم" إلى ما يقرب من الصفر. المحادثات المتبقية هي حالات حدية حقيقية لم يغطِّها التصميم، وهذا مقبول – هذا النوع من الأشياء ينبغي نقاشه، لا أساسيات من قبيل "استخدمت ١٦ بكسل حشواً بدلاً من ١٢".
٤. دع السياق يتدفق بين الأدوات تلقائياً
هنا سأذكر Sugarbug، لأننا بنيناه حرفياً لحل هذه المشكلة بالذات. يترك مصمّمنا تعليقة في Figma بشأن تعديل التباعد. يلتقط Sugarbug تلك التعليقة، يربطها بقضية Linear وGitHub PR ذات الصلة، ويرى المهندس ذلك في سير عمله دون أن يفتح Figma. يتوقف تسليم التصميم والهندسة عن كونه طقساً يدوياً للنسخ واللصق ويصبح شيئاً يحدث من تلقاء نفسه.
لكن إن لم تستخدم Sugarbug (ومعظمكم لا يفعل – لا نزال ما قبل الإطلاق)، فالنسخة اليدوية هي: عيّن شخصاً "جسراً للتسليم" يفحص تعليقات Figma يومياً وينسخ الملاحظات ذات الصلة إلى قضايا Linear. مرهق، لكنه يؤدي الغرض، وهو أفضل بلا قياس من مجرد الأمل في أن يتذكر المهندسون فحص Figma.
إذا لم أتذكر قراراتي التصميمية من الثلاثاء الماضي، فليس بمقدور مهندس مستقل بأي حال أن يستوعب كل شيء من خيط تعليقات Figma. attribution: Chris Calo
قائمة مراجعة تسليم التصميم والهندسة
إن كنت ستأخذ شيئاً واحداً من هذا المقال، فليكن هذا: الحل ليس أدوات أفضل (ليس في المقام الأول – رغم أنني أبني أداة، فخذ ذلك بحذر). الحل هو وضع أعراف لمكان القرارات التصميمية، والتأكد من أن هذا "المكان" يقع داخل سير العمل الطبيعي للمهندس.
- [ ] صدِّر الإطارات الرئيسية كملفات PNG إلى قضية Linear (لا مجرد رابط Figma)
- [ ] اكتب "لماذا" لكل قرار تصميمي رئيسي في وصف القضية
- [ ] أدرج الحالات الحدية المعروفة (الهاتف، الحالة الفارغة، النص الطويل) – أو وضّح صراحةً ما لم يُحسم بعد
- [ ] انقل ملاحظات التنفيذ من تعليقات Figma إلى خيط القضية
- [ ] اشترط لقطة شاشة في كل PR لواجهة المستخدم قبل الموافقة التصميمية
- [ ] عيّن شخصاً "جسراً للتسليم" إن لم تتوفر أدوات لربط Figma وLinear تلقائياً
الأسئلة الشائعة
Q: لماذا تفشل تعليقات Figma كأداة لتسليم التصميم والهندسة؟ A: تعيش تعليقات Figma داخل ملف التصميم، منفصلةً عن سير العمل الهندسي. يعمل المهندسون في Linear وGitHub وبيئة التطوير – لا في Figma. لا تتحول التعليقة على الإطار إلى مهمة إلا إذا نسخها أحد يدوياً، وعند تلك الخطوة اليدوية تنهار عملية تسليم التصميم والهندسة. إنها ليست مشكلة أشخاص، بل مشكلة حدود الأدوات.
Q: هل يربط Sugarbug تعليقات Figma بقضايا Linear تلقائياً؟ A: نعم – وهذه إحدى المشكلات التي بنيناه لحلها تحديداً. يجمع Sugarbug تعليقات Figma ويربطها بقضايا Linear وطلبات GitHub PR ذات الصلة، فيظهر ملاحظات التصميم في سير عمل المهندس دون أن يضطر أحد إلى النسخ واللصق بين الأدوات. نستخدمه بأنفسنا كل يوم، والفارق (بصدق) محرج بعض الشيء بالنظر إلى مدى بساطة الفكرة.
Q: ما أفضل عملية تسليم بين التصميم والهندسة للفرق الصغيرة؟ A: اكتب قرار التصميم في قضية Linear قبل أن يبدأ المهندس في البناء. أدرج المنطق، لا الشكل المرئي فحسب. إذا ظهرت حالات حدية أثناء التنفيذ، ناقشها في خيط القضية – لا في تعليقة Figma يضطر المهندس للبحث عنها. العملية الأبسط هي في الغالب الأكثر استدامة.
Q: كيف تتعامل مع تغييرات التصميم بعد بدء العمل الهندسي؟ A: تعامل معها كتغييرات في النطاق: وثّق التغيير في القضية بصورة قبل/بعد واضحة، اشرح المنطق، ودع المهندس يقيّم تكلفة التنفيذ قبل الالتزام. أسوأ إخفاقات التسليم تقع حين تصل تغييرات التصميم كتعليقات Figma عارضة على عمل اكتمل بناؤه بالفعل – هكذا يتولّد مهندسون ساخطون ومصممون محبَطون.
احصل على ذكاء الإشارات مُوصَّلاً إلى صندوق بريدك.