{"id":"l-ds-1-1","courseId":"design-systems","lang":"ar","kind":"intro","summary":"اشرح ما هو نظام التصميم أبعد من مجرد مكتبة مكوّنات، ولماذا يجب أن يُدار كمنتج له مستخدمون وخارطة طريق وفريق، لا كمشروع يُنجَز مرة واحدة.","html":"

حين انضممت إلى Northwind مصمّمةَ منتجات، كان في تطبيق إدارة الشحنات (dispatch) 64 درجة رمادي مختلفة في الإنتاج، و11 شكلًا للأزرار، وثلاثة منتقيات تاريخ يعرض كلٌّ منها التاريخ بطريقة مختلفة. لم يقرّر أحد شيئًا من هذا. لقد تراكم وحده: كل فريق حلّ مشكلته تحت ضغط موعد تسليم، ولم يكن أحد يتقاضى راتبًا ليرى الصورة كاملة.

\n

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

\n

مِمَّ يتكوّن نظام التصميم

\n

نظام التصميم (design system) هو المجموعة المشتركة من القرارات التي تسمح لفرق كثيرة ببناء واجهات متّسقة دون أن تعيد التفكير في كل شيء من الصفر. وهذه القرارات تعيش في طبقات:

\n
\n أربع طبقات متراصّة: الـ tokens في الأسفل، ثم المكوّنات، ثم الأنماط، ثم التوثيق في الأعلى، وكلها داخل إطار عنوانه الناس والعمليات.\n \n الناس والعمليات: الفريق، المساهمة، الـ governance، الإصدارات\n \n التوثيق: متى تستخدم ماذا، ولماذا\n \n الأنماط: النماذج، الحالات الفارغة، جداول البيانات\n \n المكوّنات: Button، Dialog، Tabs\n \n الـ Tokens: اللون، المسافات، الخط، الحركة\n
طبقات نظام التصميم، يجمعها الناس والعمليات
\n\n

مكتبة المكوّنات طبقة واحدة فقط. والفرق التي لا تبني غيرها تحصل على صندوق قطع بلا دليل استخدام، ثم تتقادم القطع.

\n

منتج، لا مشروع

\n

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

\n

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

\n\n

كيف تسير هذه الدورة

\n

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

\n","toc":[{"id":"sec-1","text":"مِمَّ يتكوّن نظام التصميم","level":2},{"id":"sec-2","text":"منتج، لا مشروع","level":2},{"id":"sec-3","text":"كيف تسير هذه الدورة","level":2}],"takeaways":["نظام التصميم هو الـ tokens والمكوّنات والأنماط والتوثيق، ومعها الناس والعمليات التي تبقيها محدَّثة.","المشروع ينتهي عند الإطلاق، أما المنتج فله مستخدمون وbacklog وفريق، وهذا بالضبط ما يحتاجه نظام التصميم ليعيش.","عملاء نظام التصميم هم فرق المنتجات التي تبني به، لذا فالوقت الذي يوفّره لهم هو القيمة التي تقيسها.","أغلب الأنظمة تموت من الإهمال بعد الإطلاق، لا من رداءة المكوّنات يوم الإطلاق."],"further":[{"title":"Design Systems 101 (Nielsen Norman Group)","url":"https://www.nngroup.com/articles/design-systems-101/"},{"title":"About the U.S. Web Design System","url":"https://designsystem.digital.gov/about/"}],"quiz":[{"q":"

أطلق أول نظام تصميم في Northwind مكتبة Figma مصقولة وحزمة React عام 2021، ثم نُقل الفريق إلى عمل آخر. وبحلول 2023 كانت نصف الفرق قد نسخت المكوّنات إلى مستودعاتها (fork). ما السبب الجذري؟

","options":[{"text":"بُنيت المكوّنات بـ React بدل Web Components.","why":"اختيار الإطار قد يحدّ من الانتشار، لكنه لا يفسّر لماذا نسخت الحزمةَ حتى الفرقُ التي تستخدم React."},{"text":"أُدير كمشروع له تاريخ انتهاء، فلم يبقَ أحد يحدّثه.","why":"صحيح. بلا فريق يملكه بقيت الأخطاء بلا إصلاح والطلبات بلا رد، فأصلحت الفرق نسخها الخاصة."},{"text":"كانت مكتبة Figma تضم مكوّنات قليلة جدًا عند الإطلاق.","why":"النظام الصغير الذي يُعتنى به يعيش أطول من النظام الكبير المهجور، فالنطاق لم يكن سبب الفشل هنا."},{"text":"لم تتدرّب الفرق على طريقة تثبيت الحزمة.","why":"التدريب يساعد على التبنّي، لكن الفرق ثبّتت الحزمة فعلًا، وتركتها لأنها لم تعد تلبّي احتياجاتها."}],"answer":1},{"q":"

مَن العميل الحقيقي لنظام التصميم؟

","options":[{"text":"المستخدمون النهائيون للمنتجات المبنية به.","why":"يستفيدون بشكل غير مباشر، لكنهم لا يلمسون النظام أبدًا؛ مَن يقرّر استخدامه أو تركه هم فرق المنتجات."},{"text":"مصمّمو فريق نظام التصميم أنفسهم.","why":"النظام المبني على ذوق صانعيه يتجاهل غالبًا القيود التي تواجهها فرق المنتجات فعلًا."},{"text":"مصمّمو المنتجات ومهندسوها الذين يبنون به.","why":"صحيح. هم مَن يتبنّاه أو يتجاهله أو ينسخه، لذا فاحتياجاتهم هي ما يقود خارطة الطريق."}],"answer":2},{"q":"

سألك مدير «متى سينتهي نظام التصميم؟». ما أدقّ إجابة؟

","options":[{"text":"حين تستخدم كل شاشة في المنتج مكوّنات النظام.","why":"التغطية الكاملة محطة لا نهاية؛ المنتجات تتغيّر باستمرار، فيجب أن يتغيّر النظام معها."},{"text":"حين تصل مكتبة Figma وحزمة الكود إلى الإصدار 1.0.","why":"الإصدار 1.0 يعني API مستقرًا، لا نهاية العمل؛ فالصيانة والتطوير يبدآن من هناك."},{"text":"بعد نشر موقع التوثيق.","why":"التوثيق جزء واحد من النظام ويحتاج إلى صيانة مثل أي جزء آخر."},{"text":"لن ينتهي، تمامًا كما لا ينتهي المنتج الرئيسي؛ فهو يُموَّل كمنتج.","why":"صحيح. النظام الذي يتوقّف عن التطوّر يبتعد عن المنتجات التي يخدمها ثم يُهجَر."}],"answer":3}],"exercise":{"kind":"choice","multiple":true,"options":["forks","greys","one-app","requests","launch"],"correct":["forks","greys","requests"],"title":"دافع عن فريق منتج دائم","prompt":"

لن يموّل نائب رئيس المنتجات في Northwind فريقًا دائمًا لنظام التصميم إلا إذا قدّمت دليلًا على أن الشركة تحتاج إليه. أيّ هذه النتائج يدعم تمويل النظام كمنتج له فريق دائم؟ اختر كل ما ينطبق.

\n","hints":["ابحث عن دليل على تكلفة مستمرة ومتكرّرة، لا مشكلة تحدث مرة واحدة.","اسأل عن كل نتيجة: هل يصلحها مشروع تنظيف مدّته ربع سنة إصلاحًا نهائيًا؟"],"explanation":"

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

\n","checkLabels":{},"optionText":{"forks":{"text":"ست فرق نسخت Button الصادر عام 2021 إلى مستودعاتها لتصلح أخطاءه محليًا.","why":"صحيح. النسخ المنفصلة تثبت أن الفرق تحتاج مكوّنات مشتركة لكن لا أحد في المصدر يصلحها، وهذه مشكلة ملكية."},"greys":{"text":"كشف التدقيق 64 قيمة رمادية مختلفة في تطبيق الـ dispatch والموقع التسويقي.","why":"صحيح. انحراف بهذا الحجم يأتي من فرق كثيرة تتّخذ القرار نفسه منفردة، مرة بعد مرة."},"one-app":{"text":"فريق تطبيق الـ dispatch نفسه يريد إعادة تسمية الـ classes في الـ CSS الخاص به.","why":"هذه إعادة هيكلة داخلية لفريق واحد؛ لا تحتاج إلى نظام مشترك ولا إلى فريق مخصّص."},"requests":{"text":"كل شهر تسأل نحو خمس فرق على Slack إن كان منتقي تاريخ أو جدول بيانات موجودًا بالفعل.","why":"صحيح. الطلب المتكرّر من فرق كثيرة هو بالضبط قاعدة المستخدمين التي يخدمها فريق المنتج."},"launch":{"text":"تريد الإدارة إعلانًا عن نظام التصميم في الاجتماع العام للشركة الشهر القادم.","why":"موعد الإطلاق محطة مشروع؛ لا يقول شيئًا عن الحاجة المستمرة التي تبرّر فريقًا دائمًا."}}},"words":466,"readMinutes":3}