أنظمة تصميم تُبقي منتجك متسقًا وثنائي اللغة

ما هو نظام التصميم وما الذي لا يُعدّ نظامًا

نظام التصميم مجموعة قرارات مشتركة يعيد الفريق استخدامها بدل أن يعيد صنعها في كل شاشة. ويتكوّن من أربعة أجزاء.

• رموز التصميم (design tokens): قيم مسمّاة للون والخط والمسافات وانحناء الزوايا والظلال والحركة، مثل لون «السطح» أو مسافة «space-4». هي المرجع الوحيد لمظهر الواجهة.
• المكوّنات: الأزرار وحقول الإدخال والنوافذ والجداول والتنقل، تُبنى مرة في Figma ومرة في الشيفرة، وتُعرَّف لكل منها جميع حالاتها.
• التوثيق: متى يُستخدم كل مكوّن، وكيف يتصرف، وما الذي لا يجوز له أن يفعله، مع أمثلة حيّة.
• الحوكمة: من يملك النظام، وكيف تُقترح التغييرات وتُراجَع، وكيف يصل الإصدار الجديد إلى كل منتج.

النظام ليس حزمة واجهات (UI kit)، أي ملفًّا من الأشكال يُظهر المظهر فقط. وليس دليل هوية بصيغة PDF، وليس مشروعًا ينتهي عند تسليم الملفات. هو منتج مستخدموه مصمموك ومهندسوك، ويحتاج إلى مالك. وتجد تعريفه المختصر في مدخل نظام التصميم في قاموسنا.

متى يستحق نظام التصميم الجهد، ومتى يكون مبكرًا

يستحق النظام الجهد حين تُبنى الواجهة نفسها مرات كثيرة على أيدي أشخاص مختلفين. وهذه علاماته:

• يبني عدة مصممين أو مهندسين أو متعاقدين شاشات للمنتج نفسه.
• يعمل المنتج على الويب وعلى الجوال، ويجب أن يبدو منتجًا واحدًا.
• يكرر المهندسون الأسئلة نفسها عن المسافات والحالات والتركيز.
• تطلقون المنتج بالعربية والإنجليزية، فلا بد أن يعمل كل مكوّن في الاتجاهين.

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

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

كيف تبني نظام تصميم خطوة بخطوة

1. جرد ما هو موجود

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

2. تعريف الرموز

ابدأ بالقيم الأولية: لوحة الألوان وسلّم الخطوط وسلّم المسافات. ثم أضف رموزًا دلالية تسمّي الغرض، مثل text-primary وborder-error، ولا تسمح للمكوّنات باستخدام غيرها. بهذا يصير الوضع الداكن أو العلامة الثانية أو النسخة من اليمين إلى اليسار تغييرًا في الرموز لا إعادة كتابة. وتستطيع أداة بناء مثل Style Dictionary تحويل ملف رموز واحد إلى متغيرات CSS وإلى قيم لـ Swift وKotlin وFlutter.

3. بناء المكتبة في Figma وفي الشيفرة

ابنِ المكوّنات نفسها في Figma وفي الشيفرة: React وTypeScript للويب، وFlutter أو الشيفرة الأصلية للجوال، بالأسماء والخصائص والحالات نفسها: الافتراضية والتمرير والتركيز والتعطيل والتحميل والخطأ.

4. التوثيق في Storybook

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

5. الإصدارات والنشر

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

6. وضع قواعد المساهمة

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

إمكانية الوصول والاتجاه من اليمين إلى اليسار مكانهما الرموز

إضافة هذين الأمرين لاحقًا أغلى من بنائهما من البداية، لأنهما يمسّان كل مكوّن. لذلك ضعهما في الأساس.

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

وتجد تفاصيل الخط والتخطيط بالعربية في صفحتنا عن التصميم للعربية ومن اليمين إلى اليسار.

هل تبني نظامك أم تعتمد مكتبة مفتوحة المصدر؟

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

أسباب فشل أنظمة التصميم الشائعة

• بناؤه بمعزل عن الواقع. مكتبة لم يطلبها أحد، فيتجاوزها المهندسون. ابنها من شاشات حقيقية.
• تباعد التصميم عن الشيفرة. يقول Figma شيئًا وتقول الشيفرة شيئًا آخر. شاركوا الرموز وراجعوا الاثنين معًا.
• غياب المالك. بلا مسؤول واضح يتآكل النظام خلال إصدارات قليلة.
• رموز مسمّاة بالقيمة. رمز اسمه blue-500 يُستخدم في كل مكان لا يخبرك بشيء. سمِّ الرموز بالغرض.
• إضافة الاتجاه من اليمين إلى اليسار في النهاية. عكس نظام مكتمل يعني لمس كل شيء. اجعل الاتجاه وضعًا منذ أول رمز.

كيف ندير مشروع نظام التصميم

نظام التصميم بمكوّنات قابلة لإعادة الاستخدام أحد مخرجات خدمة تصميم واجهة وتجربة المستخدم لدينا. وتتبع طريقتنا الخطوات أعلاه، بحجم يناسب المنتج.

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