ستقدّم تحديثات Figma المنتظرة طريقة جديدة للتعامل مع الحالات المتعددة للمكوّن، تُسمّى variants، وذلك بتجميع المكوّنات في حالات متعددة تفصل بينها شرطة مائلة ( / ). ويضمن اعتماد مبادئ التصميم المتمحور حول المستخدم أن تتوافق قواعد التسمية لديكم مع احتياجات المستخدمين وتوقعاتهم.

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

أما إن كنتم في بداية طريقكم في تصميم واجهة المستخدم وتريدون الاستعداد لمشاريع أكبر (لن تكونوا فيها وحدكم من يعمل على الملف)، فإليكم الأساسيات:

1. اسم مألوف

لا داعي لتقسيم أحجام النصوص إلى H1 حتى H6، أو تغيير ‘popup’ إلى ‘panel’ إن لم يكن فريقكم معتادًا على ذلك. فحصر نظام التصميم في مصطلحات المطوّرين يضع المبتدئين والمصممين غير التقنيين أمام منحنى تعلّم حاد، وقد يثنيهم عن تبنّي نظام التصميم أصلًا. وإن كان فريقكم مرتاحًا لتسميات مثل ‘Normal, Header, Super, Uber’، فلا مانع إطلاقًا من اعتمادها. ويمكن لأبحاث المستخدمين أن تساعدكم في تحديد قواعد التسمية الأوضح والأكثر فاعلية لفريقكم.

للبدء، اطّلعوا على أمثلة أنظمة التصميم "الجيدة" المتاحة على الويب

ومن المفيد أيضًا أن تجمعوا بسرعة Component Wiki أو ورقة مرجعية مختصرة (Cheat Sheet) لفريقكم، تتضمن الأسماء الشائعة والموصى بها (أو في هذه الحالة: لكل مشروع عميل). وبذلك يستطيع الجميع مواكبة التسميات المشتركة والبحث عمّا يحتاجونه عند الحاجة.

نصيحة: إن كنتم تعملون مع مطوّري front-end، فيمكنكم أن تطلبوا منهم الوصول إلى أدوات نظام الواجهة لديهم (Storybook مثلًا)، لتستعيروا منها أسماء مألوفة لفريقي التصميم والتطوير معًا.

2. خصائص يسهل إدارتها

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

[Name] / [Type] / [Size] / [Colour] / [State]

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

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

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

3. قواعد ثابتة لحالة الأحرف

أفضل ما يمكن أن تقدّموه لزملائكم بعد ذلك هو الاتساق، فهو يساعدهم على التنقل في دهاليز نظام التصميم الذي قد يكون (ربما) غير مكتمل بعد. ووجود مجموعة قواعد للتسمية على مستوى المؤسسة كلها قد يكون عونًا كبيرًا للجميع.

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

كما يمكن لاختبارات سهولة الاستخدام أن تؤكد أن قواعد التسمية واضحة وفعّالة لجميع أعضاء الفريق.

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

فلا فائدة من استخدام Title case في مشروع وCamel case في مشروع آخر.

أما في فريقنا، فنفضّل استخدام Title case مع مسافة واحدة قبل الشرطة المائلة وبعدها (Name / Property 1 / Property 2 / … )، لأن ذلك أسهل على العين ويترك مساحة مريحة داخل قائمة الطبقات.

4. بنية قابلة للتوسّع

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

ومن المهم أيضًا تكييف قواعد التسمية مع أنواع مختلفة من واجهات المستخدم، ومنها الواجهات الصوتية، لضمان أن تكون سهلة الاستخدام ومتاحة للجميع.

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

5. توثيق متسق

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

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

6. مواكبة التطورات التقنية

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

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

7. تشجيع التعاون والتواصل

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

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

الأسئلة الشائعة

**س: ما الفرق بين تصميم تجربة المستخدم (UX) وتصميم واجهة المستخدم (UI)؟**ج: يركّز تصميم UX على تجربة المستخدم ككل، بما فيها سهولة الاستخدام وإمكانية الوصول والرضا، بينما يهتم تصميم UI بالعناصر المرئية والمكوّنات التفاعلية للمنتج.

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

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

**س: ما المهارات الأساسية في تصميم تجربة المستخدم؟**ج: من أبرزها أبحاث المستخدمين، وهندسة المعلومات، وتصميم التفاعل، والتصميم المرئي، وبناء النماذج الأولية، وغيرها.

**س: كيف يمكن لنظام التصميم أن يرفع رضا المستخدمين؟**ج: يرفع نظام التصميم المنظّم رضا المستخدمين عبر تقديم تجربة متسقة وبديهية، وتقليل الالتباس، وضمان أن يلبّي المنتج احتياجات المستخدمين وتوقعاتهم.