دليل
متى تحتاج مصمم UI/UX ومطوّر Front-End معًا؟
يُشترى التصميم والواجهة الأمامية منفصلين عادة، لأنهما يبدوان شيئين منفصلين. ثم يصطدم المشروع بتكلفته الحقيقية: الفجوة بينهما. لا المصمم ولا المطوّر، بل الحدّ الفاصل. يتناول هذا الدليل متى تستحق تلك الفجوة أن تُلغى، ومتى لا تستحق, وهذا لا يقل أهمية.
ما الذي يُفقد فعلًا في التسليم
- حالات لم يحددها أحد. أغلب ملفات التصميم تعرض المسار المثالي. ثم يخترع المطوّر حالات الفراغ والتحميل والخطأ والجزئية ومنع الصلاحية، بسرعة وتحت ضغط موعد نهائي.
- السلوك المتجاوب. الملف يعرض نقطتي توقف أو ثلاثًا. والمتصفحات الحقيقية لديها عدد لا نهائي، وما يحدث بينها يصبح ما يفعله التخطيط افتراضيًا.
- المحتوى الحقيقي. التصاميم تستخدم نصًا مرتبًا. والمحتوى الفعلي أطول أو أقصر أو غائب أو بلغة أخرى بعرض مختلف.
- تفاصيل التفاعل. التوقيت وسلوك التركيز وما يحدث بعد الإرسال وما يعنيه عنصر معطّل.
- المنطق وراء القرار. يرث المطوّر القرار دون سببه، فيُحلّ أول قيد يظهر بالتخمين.
لماذا لا يملك أحد هذه الفجوة
المشكلة البنيوية هي المسؤولية. حين يُطلق شيء خاطئ، يقول المصمم إنه لم يُبنَ كما صُمّم، ويقول المطوّر إنه لم يُحدَّد. وكلاهما صادق عادة. وما لم يكن أحد مسؤولًا صراحة عن الفرق بين التصميم والمنتج المُطلق، يبقى ذلك الفرق مهمة لا أحد، ويتراكم إصدارًا بعد إصدار.
متى يكون المشروع الموحّد أفضل فعلًا
- المنتج فيه رحلات معقدة, حجز، استفسار متعدد الخطوات، لوحات تحكم, تحدد فيها الحالات الطرفية التجربة
- الواجهة مخصصة إلى حد كبير لا مجمّعة من مكتبة مكوّنات جاهزة
- يُطلق بأكثر من لغة، خصوصًا العربية والإنجليزية، حيث يؤثر الاتجاه على التصميم والتنفيذ معًا
- لديك قدرة باك إند وينقصك تصميم المنتج وحرفة الواجهة الأمامية داخليًا
- السرعة مهمة ولا تحتمل جولة مواصفات ذهابًا وإيابًا لكل سؤال بلا إجابة
- لا يوجد داخليًا من يملك الحدّ الفاصل بين التصميم والبناء
متى يكون التوظيف المنفصل هو القرار الصحيح
- لديك فريق واجهة أمامية داخلي قوي، وينقصك طاقة تصميم فقط
- البناء في معظمه تهيئة على منصة أو نظام تصميم قائم
- مدير المنتج لديك يملك فعلًا فجوة التصميم إلى البناء ولديه وقت لذلك
- العمل كبير بما يكفي ليحتاج عدة أشخاص بالتوازي، فيصبح الشخص الواحد عنق زجاجة
- المشتريات أو الحوكمة تشترط فصل الموردين، وهذا سبب مشروع بحد ذاته
كيف يبدو العمل الجيد في الحالتين
إن قسّمت العمل، فقلّص الحدّ الفاصل عمدًا: اشترط أن يشمل التصميم حالات الفراغ والتحميل والخطأ والنجاح؛ واشترط مكوّنات مسمّاة قابلة لإعادة الاستخدام لا شاشات منفردة؛ وأدخل المطوّر في مراجعات التصميم قبل إنهاء الملف؛ واجعل شخصًا محددًا مسؤولًا عن الفرق بين التصميم وما يُطلق. أغلب قيمة المشروع الموحّد يمكن استعادتها بهذه الطريقة، لكنها يجب أن تكون مهمة أحدهم صراحة لا افتراضًا.
أسئلة تستحق طرحها على أي مرشح
- أرني مشروعًا صممت وبنيت فيه الواجهة نفسها. ما الذي تغيّر أثناء البناء ولماذا؟
- كيف تتعامل مع قرار تصميم يتبيّن أنه غير عملي بعد وصول بيانات حقيقية؟
- ما الحالات التي تعتبرها ضمن النطاق الأساسي لا إضافة؟
- كيف تتعامل مع RTL، وفي أي مرحلة تقرره؟
- ما الذي تحتاجه منّا، وماذا يحدث للجدول الزمني إن تأخر وصوله؟
أسئلة شائعة
هل اعتماد شخص واحد على الجانبين مخاطرة؟
هو يركّز الاعتماد، وهذه مفاضلة حقيقية تستحق الذكر. ويخفّفها امتلاكك للملفات والمستودع من البداية، ومكوّنات موثّقة بدل اختصارات شخصية، وتسليم مكتوب لفريق غير من بناه. وفي المقابل تلغي فجوة التسليم تمامًا، وهي للرحلات المعقدة المخاطرة الأكبر عادة.
هل هو أرخص من توظيف مصمم ومطوّر منفصلين؟
غالبًا، لكن هذه ليست الحجة الأساسية. التوفير الحقيقي هو إعادة العمل التي لا تحدث: أسئلة بلا إجابة تُحلّ بالتخمين، وحالات تُكتشف متأخرة، وجولة إصلاحات بعد أن يرى الجميع النسخة المبنية لأول مرة.
هل يجب أن يكون المصمم مطوّرًا؟
لا، لكن التصميم بإحساس دقيق بما يمكن بناؤه يمنع فشلًا محددًا ومكلفًا: ملف جميل يجب إعادة تفسيره، أو يتبيّن أنه غير عملي بعد وصول محتوى وبيانات حقيقية.
لدينا ملف Figma بالفعل. هل نعيده؟
غالبًا لا. يمكن بناء تصميم قائم كما هو، مع طرح الثغرات التي لا يجيب عنها, الحالات الناقصة والحالات الطرفية والسلوك المتجاوب, كأسئلة بدل اختراعها بصمت.
وماذا عن الباك إند؟
التصميم والواجهة الأمامية اقتران تخصصي واحد، والباك إند تخصص آخر. الواجهة الأمامية المبنية جاهزة للربط بالـ API تتصل بباك إندك أو بمطوّر الباك إند لديك أو بخدمة خارجية. واحذر من يطمس هذا الحد، لأنه المكان الذي تبدأ منه خلافات النطاق.
تتردد بين مشروع واحد أو جهتين منفصلتين؟
صف المنتج والرحلة التي يجب أن يصيبها. ستحصل على قراءة صادقة، بما في ذلك متى يكون التوظيف المنفصل هو الجواب الأفضل.