نظام التصميم (Design System): متى يستحقه مشروعك وكم يكلّف

نظام التصميم مستودع للقرارات البصرية والتفاعلية، وفريق يملك صلاحية تغييرها. الجزء الأول يبنيه فريقك في أسابيع، والجزء الثاني هو ما يجعل النظام يعيش أو يموت بعد ستة أشهر. لهذا يبدأ القرار عندك من سؤال واحد: من يوافق على تغيير شكل الزر بعد اليوم؟ إن لم تكن تملك إجابة، فأنت تبني مكتبة مكوّنات، لا نظام تصميم.

تعرّفه مجموعة نيلسن نورمان بأنه مجموعة كاملة من المعايير لإدارة التصميم على نطاق واسع عبر مكوّنات وأنماط قابلة لإعادة الاستخدام، وتضيف أن له جزأين لا جزءًا واحدًا: المستودع، والناس الذين يديرونه. هذا المقال يشرح الجزأين، ثم يعطيك حسابًا تجريه بأرقامك أنت قبل أن تبدأ.

ما الذي يفصل النظام عن ملف Figma مرتّب

الفرق ليس في عدد المكوّنات. ملف Figma فيه مئة مكوّن منظّم يظل ملفًا. يصير نظامًا حين تُضاف إليه ثلاثة أشياء: قيم مشتركة يقرأها التصميم والكود معًا، ونسخة معروفة لكل مكوّن، وقاعدة مكتوبة تحدّد من يغيّر ماذا ومتى.

الغياب الأوضح في الفرق المحلية هو الثالث. تجد مكتبة Figma ممتازة، ومكتبة React موازية، ثم مطوّرًا يضيف زرًّا جديدًا في شاشة الفواتير لأن الزر الموجود لم يناسب المقاس، فيصير عندك زرّان. بعد سنة يصيران سبعة. تسمّي Atlassian هذه النقطة صراحة ضمن فوائد نظامها: حين لا تُوثَّق المعرفة، تخاطر الفرق بفقدانها مع تغيّر الموظفين.

ما الذي يوجد داخل الأنظمة فعلًا

بدل تعداد ما «ينبغي» أن يحتويه النظام، هذه نسب ما يحتويه فعلًا عند المشاركين في تقرير أنظمة التصميم 2025 من zeroheight، وهو استبيان شارك فيه أقل من 300 شخص وجُمعت بياناته بين سبتمبر ونوفمبر 2024:

الرقم الذي يستحق التوقف في بيانات التقرير هو مكتبات الكود عند 73%. أكثر من ربع من يقولون إن لديهم «نظام تصميم» لا يملكون مكتبة كود، أي أن نظامهم يعيش في أداة التصميم وحدها، ويعاد بناؤه يدويًا في كل شاشة. وهذه بالضبط الحالة التي تدفع ثمنها مرتين: مرة في التصميم ومرة في البرمجة.

أما الرقم الذي تغيّر بسرعة فهو التوكنز: 84% هذا العام مقابل 56% في العام السابق حسب التقرير نفسه.

المحددات التصميمية: الطبقة التي تربط Figma بالكود

المحدّد التصميمي (Design Token) اسم وقيمة. الاسم ثابت والقيمة تتغيّر. حين يشير ملف المصمّم وكود المطوّر إلى الاسم نفسه، يصير اللون واحدًا بينهما حتى لو تغيّرت قيمته الست عشرية لاحقًا، كما يشرحه توثيق Material Design 3.

ينظّم Material التوكنز في ثلاث طبقات، وهي أوضح نموذج لفهم البنية:

الطبقة النظامية هي موضع الثيم. هي التي تجعل الوضع الداكن تبديلًا في مرجع واحد بدل مراجعة كل شاشة. ومن السياقات التي يعدّدها التوثيق صراحة، إلى جانب حجم الجهاز والوضع الداكن، أنظمة الكتابة من اليمين إلى اليسار. بعبارة عملية: قيمة المسافة الداخلية اليمنى في واجهة عربية يمكن أن تُحسم في التوكن مرة واحدة بدل أن يعالجها كل مطوّر في مكانه. وإن كانت العربية لغة منتجك الأولى، فهذا وحده سبب كافٍ لبناء طبقة التوكنز قبل أي مكوّن.

ما الذي تغيّر في 2025

ظل تبادل التوكنز بين الأدوات فوضى صيغ خاصة لسنوات. في 28 أكتوبر 2025 أعلنت مجموعة مجتمع التوكنز في W3C (Design Tokens Community Group) أول نسخة مستقرة من المواصفة برقم 2025.10، بعد ثلاث مسودّات امتدت من 2021 إلى يوليو 2025 كما يوثّق جدول الإصدارات في مستودع المجموعة. والملفات نفسها ملفات JSON عادية، لا صيغة خاصة تحتاج أداة بعينها لقراءتها.

ما يعنيه هذا لفريقك عمليًا ثلاثة أشياء: إدارة الوضع الفاتح والداكن وتعدد العلامات دون تكرار الملفات، ودعم فضاءات الألوان الحديثة مثل Display P3 وOklch، وملف توكنز واحد يولّد كودًا لـ iOS وأندرويد والويب وFlutter. وتذكر المجموعة تطبيقات مرجعية في Style Dictionary وTokens Studio وTerrazzo، وأكثر من عشر أدوات تصميم ومشاريع مفتوحة المصدر تدعم المواصفة أو تنفّذها، منها Figma وSketch وFramer وPenpot.

الخلاصة القابلة للتنفيذ: إن كنت ستبني طبقة توكنز هذه السنة، ابنِها على هذه الصيغة بدل صيغة خاصة بأداة واحدة. التكلفة نفسها اليوم، والفرق يظهر يوم تغيّر أداة أو تضيف منصة.

لكن الأتمتة ليست منتشرة كما يبدو

التوكنز فكرة رائجة والأتمتة خلفها متأخرة. في تقرير zeroheight نفسه، 26% لا يملكون أي أتمتة في مسار التوكنز، و21% يصفون حالهم بأنهم «لم يبدؤوا بعد، نعمل عليها». وأكبر تحدٍّ يذكره المشاركون تعريف معمارية التوكنز (57%)، ثم إدارتها (39%)، ثم دمجها في قاعدة كود قائمة (37%)، وهناك 29% يشكون صراحة من كمية التوكنز المربكة التي عليهم إدارتها. العقبة في هذه الحالات كلها قرار بشري لم يُحسم، لا أداة ناقصة.

الدرس للفريق الصغير: ابدأ بعدد توكنز يمكنك أن تحفظه. طبقة نظامية من ثلاثين اسمًا تُستخدم فعلًا أنفع من ثلاثمئة اسم لا يعرف المطوّر أيّها يختار.

الحوكمة: من يوافق على تغيير المكوّن

هذا هو السؤال الذي تتجاهله أغلب المقالات، وهو الذي يحسم مصير النظام. الحوكمة هنا تعني شيئًا واحدًا: قاعدة معلنة لمن يضيف ومن يعدّل ومن يرفض.

توزيع الصلاحية بين المشاركين في تقرير zeroheight:

أي أن نحو ثلث الفرق تقيّد المساهمة. والنموذج المقيّد ليس بالضرورة خطأ: تفتح Atlassian المساهمة في نظامها لموظفيها وحدهم، وتقبل منهم الإصلاحات والتحسينات الصغيرة مثل إضافة أيقونة إلى المكتبة، بينما تقول إن التحسينات الكبيرة والمكوّنات الجديدة قد لا تُقبل لأنها تتطلب تنسيقًا يمتد عبر الكود والتصميم والإرشادات. وتضيف الصفحة اعترافًا نادرًا في توثيق الشركات: «من الصعب حاليًا المساهمة في نظام التصميم، ونعمل على تحسين ذلك». وفي المقابل تعقد جلسة نقد للنظام كل أسبوعين.

انظر إلى المقايضة كما هي: كلما فتحت المساهمة زادت السرعة وقلّ الاتساق، وكلما أغلقتها حصل العكس. ولا يوجد إعداد صحيح لكل الفرق. ما يقوله تقرير zeroheight إن الرضا عن الحوكمة يميل إلى الإيجاب (37% راضون و6% راضون جدًا، مقابل 18% غير راضين و3% غير راضين إطلاقًا)، وأن السبب المتكرر خلف الرضا هو حوكمة خفيفة أساسية، أي «القدر الكافي فقط».

الملاحظة الأهم لك تحديدًا: في البيانات نفسها، الرضا عن المساهمة يتراجع كلما كبرت الشركة، من 44% في الشركات تحت مئة موظف إلى 28% في الشركات بين 500 و999. ميزتك الحالية أن فريقك صغير، والإجراء الذي تضعه الآن أرخص من الذي ستحتاجه بعد ثلاث سنوات.

الحد الأدنى الذي يعمل لفريق من خمسة إلى عشرة أشخاص: شخص واحد يملك قرار الدمج في المكتبة المشتركة، وقناة واحدة تُسجَّل فيها الطلبات مكتوبة لا شفهية، وقاعدة تقول إن أي مكوّن جديد يعيش في كود فريقه أولًا، ولا ينتقل إلى المكتبة المشتركة إلا بعد أن يستخدمه فريق ثانٍ. القاعدة الأخيرة وحدها تمنع أغلب التضخّم.

النسخ والإصدارات: كيف يتغيّر مكوّن دون كسر المنتج

المكتبة المشتركة واجهة برمجية، وتغييرها يكسر ما يعتمد عليها. الحل الصناعي هو الترقيم الدلالي مع سياسة إهمال معلنة، وأوضح مثال منشور عليها هو إرشادات الإهمال في Shopify Polaris.

ما تفعله Shopify عند سحب أي عنصر:

1. تعليم العنصر بأنه مُهمَل داخل الكود نفسه، مع الإشارة إلى البديل.
2. تحديث صفحة التوثيق وتسجيل سبب الإهمال والبدائل.
3. كتابة ترحيل آلي (codemod) يُجري التعديل على قواعد كود المستهلكين.
4. إعلان كل ذلك قبل شهر على الأقل من الإصدار الرئيسي التالي.
5. حذف العنصر فعليًا في فرع الإصدار الرئيسي التالي، لا قبله.

التفصيل الذي يفوت أغلب الفرق: هذه الدورة عند Shopify لا تخص المكوّنات وحدها، بل تسري كذلك على الخاصية (prop)، وعلى قيمة بعينها داخل خاصية، وعلى التوكن نفسه. بمعنى أن تسمية توكن التزام طويل الأمد تمامًا كاسم المكوّن. فإعادة تسمية color-primary إلى color-action بلا دورة إهمال تكسر كل شاشة تقرأ الاسم القديم، مهما بدت في ملف التصميم مجرد ترتيب.

لفريق صغير لا يحتاج الأمر كل هذه البنية. يكفي ثلاثة التزامات: رقم نسخة على المكتبة المشتركة، وسجل تغييرات مكتوب بجملة واحدة لكل تغيير، وقاعدة أن أي حذف يسبقه إهمال معلن في دورة واحدة على الأقل. الإهمال قبل الحذف هو الفرق بين تحديث يُطبَّق في ساعة وتحديث يعطّل الفريق أسبوعًا.

متى يستحق النظام لفريق صغير في مصر والخليج

هذا القسم يحاول أن يقنعك بالتأجيل، لأن التوقيت الخطأ أكثر الأخطاء كلفة هنا.

الأرقام تقول إن الأنظمة المؤسسية ليست القاعدة عند الشركات الصغيرة. في بيانات zeroheight، وبين الشركات تحت مئة موظف، 60% بلا فريق نظام إطلاقًا، و25% بموارد جزئية، و15% فقط بفريق متفرّغ. ومتوسط حجم الفريق عند هذه الشريحة هبط من 5 إلى 3 أشخاص بين الاستبيانين. الاتجاه لدى الشركات الصغيرة يميل إلى التقليل لا التوسيع.

وتقول مجموعة نيلسن نورمان الشيء نفسه بصياغة القرار: لنموذج أولي أو إثبات مفهوم يُرجَّح أن يتغيّر، بناء نظام كامل لا يحقق عائدًا مرغوبًا على المدى القريب، لأن الفائدة كلها في التكرار المستقبلي. ويضيف توثيق Material قيدًا موازيًا: التوكنز أقل فائدة لتطبيق قائم بقيم مثبّتة لا يُرجَّح تغيّره خلال سنة أو سنتين.

العلامات التي تجعل البناء قرارًا سليمًا الآن:

• تشغّل أكثر من واجهة على المنتج نفسه: موقعًا ولوحة تحكم وتطبيقًا، وتريدها متسقة.
• يعمل أكثر من مصمم أو أكثر من مطوّر واجهات في الوقت نفسه على شاشات مختلفة.
• تكرّر الشاشة نفسها بتنويعات: جدول طلبات، جدول فواتير، جدول مستخدمين.
• أمامك عمل تصميمي قابل للتكرار يمتد سنوات لا أشهرًا.
• العربية لغة المنتج الأولى، وتدفع ثمن قرارات RTL في كل شاشة على حدة.

العلامات التي تعني أن الوقت مبكر:

• المنتج لم يثبّت شكله بعد، وقد تعيد تصميمه كليًا خلال ستة أشهر. ابدأ من الحد الأدنى من المنتج (MVP) أولًا.
• مصمّم واحد ومطوّر واحد، والتنسيق بينهما يتم في محادثة قصيرة.
• المنتج صفحة هبوط أو موقع تعريفي لن تضيف إليه شاشات.
• لا تعرف بعد ما الذي يحتاجه المستخدم من الشاشة أصلًا. النظام يوحّد الشكل ولا يصحّح الوظيفة، وهذا عمل أبحاث المستخدم.

بين الحالتين يوجد خيار وسط تتجاهله المقالات: التبنّي بدل البناء. تذكر مجموعة نيلسن نورمان ثلاث مقاربات، هي تبنّي نظام جاهز كما هو، أو تكييفه، أو بناء نظام خاص، وتشير إلى أن التكلفة والوقت يرتفعان كلما زاد التخصيص. لفريق من ستة أشخاص في القاهرة أو جدة، تكييف نظام مفتوح قائم وإضافة طبقة توكنز خاصة بعلامتك يعطي أغلب الفائدة بجزء من الكلفة.

كم يكلّف: حساب تجريه بأرقامك

لا توجد أسعار منشورة موثوقة لبناء نظام تصميم في السوق المصري أو الخليجي، وأي رقم جاهز تقرأه غالبًا مستورد من سوق آخر. الطريقة الوحيدة الصادقة أن تحسبها بمدخلاتك. وإن كنت تريد سعر السوق لشراء النظام كخدمة ضمن عرض تصميم، فذلك موضوع دليل تكلفة تصميم UX/UI.

المعادلة بسيطة: الكلفة = عدد أشهر-الشخص × تكلفتك الشهرية للفرد الواحد.

أشهر-الشخص تأتي من نقطتين موثّقتين: الحد الأدنى لفريق النظام عند مجموعة نيلسن نورمان هو مصمم تفاعل ومصمم بصري ومطوّر، ومتوسط الفريق في الشركات تحت مئة موظف ثلاثة أشخاص. لكن هؤلاء الثلاثة لا يلزم تفرّغهم، وهذا ما يفسّر أن ربع الشركات الصغيرة تصف فريقها بأنه «بموارد جزئية».

مثال افتراضي. الأرقام التالية مدخلات مفترضة لتوضيح طريقة الحساب، وليست أسعار سوق ولا أسعار سنابل. ضع مكانها تكلفتك الفعلية للفرد شهريًا شاملة الأعباء:

لاحظ ما تكشفه الأرقام: السنة الثانية أغلى من الأولى. بناء النظام مشروع ينتهي، وصيانته بند متكرر لا ينتهي. وهذا ما ترصده البيانات: أكبر تحدٍّ يذكره المشاركون في تقرير zeroheight هو نقص الموارد بنسبة 63%، ومجموعة نيلسن نورمان تصفه بأنه نشاط كثيف الوقت وليس حلًّا يُنجز مرة واحدة.

نقطة التعادل تحسبها هكذا: اقسم مجموع أشهر-الشخص على عدد الشاشات التي تنوي إطلاقها في الاثني عشر شهرًا القادمة، ثم قارن الناتج بالوقت الذي يوفّره النظام فعلًا في الشاشة الواحدة عندك. إن لم يكن عندك عدد شاشات مرتقب تكتبه الآن بثقة، فأنت في مرحلة التأجيل لا البناء.

ثلاثة قرارات تخفّض الكلفة دون أن تفرّغ النظام من معناه: ابدأ بالتوكنز وثمانية إلى اثني عشر مكوّنًا تغطي أغلب شاشاتك بدل تغطية شاملة؛ اكتب مكتبة الكود من اليوم الأول فلا تقع في فجوة الربع الذي يملك تصميمًا بلا كود؛ واجعل معايير إمكانية الوصول ومعايير WCAG داخل المكوّن نفسه، لأن تصحيحها لاحقًا في كل شاشة أغلى من بنائها مرة واحدة.

ماذا تفعل الآن

إن كانت علامات التأجيل تنطبق عليك، أجّل وابنِ عادة واحدة بدلها: ملف ألوان ومسافات وخطوط مشترك بين التصميم والكود. هذه هي طبقة التوكنز في صورتها الأبسط، وهي كل ما تحتاجه اليوم.

وإن كانت علامات البناء تنطبق، فالترتيب الذي يعمل: طبقة توكنز على الصيغة المستقرة، ثم المكوّنات التي تتكرر أكثر، ثم توثيق قصير يجيب «متى أستخدم هذا المكوّن ومتى لا أستخدمه»، ثم اسم شخص واحد مكتوب أمام قرار الدمج. رتّب الأربعة قبل أن ترسم المكوّن الثالث عشر.

وقبل أن توقّع مع أي مورّد على تصميم منتجك، اسأله كيف يسلّم النظام ومن يملكه بعد التسليم. هذا سؤال ضمن قائمة أطول في كيف تختار شركة تصميم UX/UI، ويفيدك قبله أن تعرف مبادئ تصميم UX/UI التي يُفترض أن يطبّقها.

إذا كنت تدرس بناء نظام تصميم لمنتجك، أو توحيد واجهات تشغّلها بالفعل، اعرض الحالة على فريق سنابل لخدمات تصميم UI/UX. يصلك خلال 24 ساعة تصوّر مبدئي للنطاق وتقدير للمدة والكلفة، بلا رسوم ولا التزام عليك.

المصادر

• Design Systems 101 — Nielsen Norman Group، آخر مراجعة 27 أغسطس 2026.
• Design Tokens specification reaches first stable version — Design Tokens Community Group (W3C)، 28 أكتوبر 2025.
• Design Tokens Community Group — مستودع المواصفة وجدول الإصدارات — DTCG.
• Design tokens — Material Design 3، Google.
• Deprecation guidelines — Shopify Polaris.
• Contribution وAbout the Atlassian Design System — Atlassian.
• Design Systems Report 2025 — zeroheight، بيانات جُمعت بين سبتمبر ونوفمبر 2024.

جميع الروابط رُوجعت في 22 سبتمبر 2026.