The following article is offered for informational purposes only, and is not intended to provide, and should not be relied on, for legal or financial advice. Please consult your own legal or accounting advisors if you have questions on this topic.

في فليكس، نحن فريق هندسي صغير معروف بقدرتنا على تحقيق إنجازات تفوق حجمنا بكثير، ولدينا ميل كبير نحو التنفيذ. بعد بضع سنوات من التغييرات السريعة في المنتجات والتحولات، تراكم لدينا قدر كبير من ديون تجربة المستخدم (UX debt) مما بدأ يظهر تجربة استخدام غير سلسة. 

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

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

المطلوب

سرعان ما أصبح السؤال هو: "كيف يمكننا تطبيق نظام تصميم "خفيف الوزن" – نظام يحقق قيمة دون أن يبطئنا؟"

أول شيء كان علينا فعله هو تقييم ما يستلزمه نظام التصميم الشامل مقابل النظام خفيف الوزن الذي كنا نهدف إلى بنائه.

أنظمة التصميم الشاملة والعادية

• مكونات مخصصة (أزرار، نوافذ منبثقة، جداول، إلخ.)
• أدوات مخصصة (إعدادات Storybook، بنية تحتية داخلية)
• عمليات/حوكمة للتغييرات
• تكاليف صيانة عالية

أنظمة التصميم خفيفة الوزن

• المكونات والأنماط الأكثر استخدامًا فقط
• سهلة التبني — الوثائق والأكواد موجودة حيث يعمل المطورون بالفعل
• تستفيد من المكتبات الموجودة بدلاً من البناء من الصفر (عند الإمكان)
• لديها معايير لتوضيح كيفية الاستخدام

قيودنا: فريق صغير، أهداف كبيرة.

بدأنا بسلسلة أنيقة من التصاميم التي امتدت من المكونات الأساسية (مثل الأزرار وحقول الإدخال) إلى التخطيطات الشائعة والتدفقات متعددة الخطوات. 

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

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

إنشاء سلسلة من المعايير الموحدة

كنا قد بدأنا سابقًا العمل على قسم "ورقة الغش" للمطورين ليحتوي على مجموعة من أفضل الممارسات للنسخ واللصق. أصبح هذا المكان المثالي لعرض نظام التصميم الناشئ لدينا. يمكننا استخدام هذه المنطقة (التي أعيد تسميتها لاحقًا بـ "Playground") لتمكين المطورين من عرض واستخدام هذه المعايير لواجهات المستخدم الأكثر شيوعًا لدينا لتسريع عملهم، وكذلك السماح للمصممين برؤية أن ما قاموا ببنائه هو ما يتم استخدامه بالفعل. أخيرًا، ساعد تضمين هذا في تطبيق الويب الخاص بنا (بدلاً من كونه خارجيًا، عبر منصة مثل Storybook) في ضمان استخدامه.

ومع ذلك، كانت القصة قد بدأت للتو. كان لدينا بضعة تحديات كبيرة يجب التغلب عليها أولاً:

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

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

عوامل مضاعفة القوة

بعد إعادة تصميم أداتنا الداخلية، ألفريد، وتطبيق الويب، بدأنا في إنشاء سلسلة من أفضل الممارسات في Playground. بمرور الوقت، احتوت Playground على "80/20" من حالات الاستخدام لدينا — متجر شامل للمكونات والتخطيطات والأدوات المشتركة.

‍

‍

بينما كنا نعلم أن Playground سيكون مفيدًا للمطورين لنسخ ولصق المكونات لتسريع العمل، تبين أن هذه المجموعة من المعايير مثالية لنموذج اللغة الكبير (LLMs) لفهم كيفية إنشاء كود واجهة المستخدم.

نقدم لكم: Cursor

بعد وقت قصير من بدء بناء Playground، بدأ فريق الواجهة الأمامية لدينا في استخدام الذكاء الاصطناعي Cursor. لقد أنشأنا بيئة Playground المرجعية لقواعد Cursor لاستخدامها كنقطة انطلاق عند إنشاء أي كود يعتمد على واجهة المستخدم:

• للاطلاع على أمثلة حول كيفية استخدام مكونات نظام التصميم الخاص بنا، تحقق من Playground في `src/areas/playground`.
• عند تنفيذ مكونات جديدة مثل الأدراج والجداول والمعالجات والتخطيطات وما إلى ذلك، انسخ الملف كما هو مطبق في Playground واستخدمه كنقطة انطلاق في المنطقة التي تعمل عليها.
• في معظم الأحيان لن تقوم بتحديث أي ملفات في `src/areas/playground`، بل ستستخدم المكونات الموجودة هناك كنقاط انطلاق لنسخها إلى مجلدات جديدة في `src/areas`.

لقد أتت جهودنا السابقة لإعادة تصميم الثيمات بثمارها بشكل كبير هنا، حيث مهدت الطريق لـ Cursor لبناء واجهات مستخدم متوافقة مع نظام التصميم الخاص بنا دون الحاجة إلى الرجوع إلى أي إرشادات تصميم.

لزيادة التركيز على "ما تعنيه جودة الواجهة الأمامية في Flex"، قمنا بتدوين المعايير التي اتفقنا عليها سابقًا كفريق واجهة مستخدم. يشير Cursor إلى هذا بالإضافة إلى قواعد Playground حتى يفهم LLM ليس فقط ما يجب بناؤه، بل وكيفية بنائه بالاقتران مع أدواتنا واتفاقياتنا المختلفة. إليك مقتطف يوضح كيف نشير إلى مكتبة واجهة المستخدم الحالية لدينا، Mantine، من ملف قواعد Cursor الخاص بنا:

• استخدم Mantine كمكتبة مكونات React الأساسية الخاصة بك.
• استفد بالكامل من مكتبة Mantine، بما في ذلك المكونات من `@mantine/core`، والـ hooks من `@mantine/hooks`، والنماذج باستخدام `@mantine/form`.
• بالنسبة للمكونات، حاول دائمًا استخدام المكونات الموجودة في مجلداتنا `components/core` أو `components/composites` أولاً، وإلا، استخدم مكونات Mantine الأساسية كلما أمكن ذلك.
• تجنب استخدام التنسيق المضمن (inline styling) أو الفئات (classes) — حاول دائمًا أولاً استخدام خصائص Mantine لتنسيق الألوان وألوان الخلفية، والمسافات والأحجام، وما إلى ذلك.
• بالنسبة للألوان، استخدم دائمًا ألوان ثيم Mantine الخاصة بنا (أي `theme.colors.yourColorHere[index]`).
• بالنسبة للمسافات والأحجام، استخدم دالة `rem()` الخاصة بـ Mantine بدلاً من قيم البكسل أو القيم الرقمية، أي `gap={rem(12)}`.

نتائج Flex

لقد كان استخدام الذكاء الاصطناعي جنبًا إلى جنب مع نظام التصميم الخاص بنا له تأثير كبير على جميع الأصعدة في إنشاء والحفاظ على مستوى أعلى للسرعة والجودة. لقد تم بناء ميزة "الذمم المدينة" (Accounts Receivable) الأخيرة لدينا بالكامل في غضون ثلاثة أسابيع فقط! 

وبالمثل، فإن استخدام Playground كمجموعة قوية من المكونات والأنماط قد عزز معايير الجودة لدينا، لكل من المطورين ونماذج اللغة الكبيرة (LLMs) على حد سواء. في سعينا لاتباع نهج أكثر مرونة في بناء نظام تصميم، تمكنا من تجاوز العديد من المزالق المرتبطة غالبًا بأنظمة التصميم، مع الحفاظ على مزايا الاتساق والتوجيه.

مؤخرًا، استخدمنا Playground كمورد تعليمي لتوضيح كيف يمكن للمطورين استخدام بدائل لأداة إدارة الحالة التي نسعى جاهدين لإهمالها. في المستقبل القريب، نهدف إلى ربط معايير Playground الخاصة بنا ببناء CI الخاص بنا لضمان المزيد من التبني.

دروس للفرق الأخرى

إذا كنت في المراحل المبكرة، إليك ما نوصي به:

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

أفكار ختامية

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

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

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

‍