دليل عملي لتسمية مكوّنات الواجهات وDesign Tokens بوضوح

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

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

ما الذي يصنع اسماً جيداً؟

يشير الدليل إلى مجموعة مبادئ متكررة في ممارسات فرق التصميم:

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

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

لا تبدأ من الصفر عند تسمية المكوّنات

عند التردد في اسم مكوّن واجهة، يمكن الاستفادة من أسماء مستخدمة في أنظمة تصميم أخرى. يضم Component Gallery أمثلة لأكثر من 50 مكوّناً، من accordion إلى العناصر المخفية بصرياً، ويعرض الأسماء البديلة الشائعة لكل مكوّن.

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

تسمية الطبقات وDesign Tokens: المعنى قبل الشكل

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

وتظهر أهمية ذلك أكثر في أنظمة التصميم متعددة المنتجات أو متعددة السمات. يورد الدليل تجربة Intuit في بناء تصنيف مرن لـDesign Tokens يخدم منتجات متعددة، بدلاً من ربط النظام بسمة علامة تجارية واحدة. كما يعرض خريطة Vodafone UK لتصنيف المتغيرات، التي تربط بين القيم الأساسية للعلامة والمعاني الدلالية ثم استخدامها في الصفحات.

الهدف من هذا النوع من التصنيف هو أن يتمكن عضو الفريق من فهم ما يمثله الرمز وأين قد يُستخدم من اسمه، بدلاً من البحث في ملفات كثيرة لمعرفة أثر أي تعديل.

اسم الميزة جزء من قابلية اكتشافها

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

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

موارد عملية للتسمية

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

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