نظام التصميم: متى يستحق البناء ومتى يكون مبالغة

الطبقات الثلاث

1. الرموز الأساسية — قيم خام: درجات اللون، ومقاسات المسافة، وأحجام الخط، ونصف أقطار الحواف.
2. الرموز الدلالية — تسمي الاستعمال لا القيمة: لون الخطر، ولون السطح، ومسافة القسم.
3. المكونات — الزر والحقل والبطاقة والنافذة، مبنية كلها على الرموز الدلالية لا على قيم مباشرة.

وهذا الترتيب يجعل تغيير الهوية أو إضافة وضع داكن تعديلا في طبقة واحدة، بدل مطاردة قيم منثورة في مئة ملف.

متى يضاف مكون

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

التوثيق شرط لا ملحق

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

الملكية والحوكمة

النظام الذي لا يملكه أحد يتعفن: تضاف مكونات متكررة، ويهجر التوثيق، ويعود كل فريق إلى حلوله الخاصة. ويحتاج الأمر مالكا معروفا، وآلية واضحة لاقتراح مكون جديد، ومراجعة دورية تحذف ما لم يعد يستعمل.

متى لا تحتاجه

المنتج الواحد الصغير بفريق من ثلاثة أشخاص لا يحتاج نظاما كاملا بمكتبة موثقة. يكفيه ملف رموز وصفحة أنماط. أما إذا تعددت المنتجات أو الفرق أو المنصات فالنظام يوفر أكثر مما يكلف بكثير.

أسئلة شائعة

هل نبني نظاما أم نستعمل مكتبة جاهزة؟

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

كيف نتعامل مع الاختلاف بين التصميم والكود؟

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

هل يبطئ النظام تطوير المميزات؟

يبطئ الأشهر الأولى ويسرع ما بعدها. والمكسب يظهر عند بناء الشاشة العاشرة والعشرين، وعند دخول مطور جديد يجد مكونات جاهزة وقواعد واضحة.