ما لا يُسمّى لا يُستخدم | اللغة كركيزة للتصميم النمطي

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

“إنها تمامًا مثل مكعّبات الليغو”

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

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

اقرأ مقالنا بعنوان: تصميم تجربة المستخدم في الألعاب الرقمية إبداع من نوع آخر

ابدأ باللغة

اللغة هي الأساس الذي تُبنى عليه أي عملية تعاونية ناجحة. في كتابها How to Make Sense of Any Mess، تشير آبي كوفرت إلى أن أكبر عائق يواجه الفرق هو غياب لغة مشتركة. ولتجاوز هذا الحاجز، تقترح أن نناقش ونفحص ونوثّق قراراتنا “الأنطولوجية” أي القرارات المتعلقة بكيفية تصنيف الأشياء من خلال ما يُعرف بـ المفردات المُضبوطة (controlled vocabularies).

بمعنى آخر: يجب أن نبدأ باللغة، لا بالواجهات.

تجربة فريق FutureLearn 

على مدار عام تقريبًا، بدأ فريق FutureLearn – وهي منصة تعليم مفتوح – بتجربة منهج التصميم النمطي. وأود هنا أن أنوه لبعض الطرق التي استخدموها لـ صياغة لغة مشتركة ساعدتهم في الانتقال نحو تصميم يعتمد على الوحدات.

بناء مكتبة أنماط… معًا، ونتابع تجربتهم كما وردت عن لسانهم.

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

في تلك اللحظة، كنا نعتقد؛ وربما بسذاجة أن هذا هو ما يعنيه “العمل بطريقة نمطية”.

اقرأ مقالنا بعنوان: مبادئ التصميم الذري (Atomic Design) وأهميتها للمصممين والمطورين

لغة التصميم النمطي (نتابع عن لسانهم)

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

• لم تكن الوحدات محددة بوضوح.
• لم تكن تؤدي وظائف واضحة؛ وغالبًا ما كانت الفروقات بينها شكلية فقط.
• لم نُوحّد أسماءها أو نضع لها تسميات.
• لم نُفكر مليًّا في كيفية إعادة استخدامها.

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

استندنا في منهجنا إلى منهجية التصميم الذري (Atomic Design) التي ابتكرها براد فروست. ومن هنا بدأنا في تفكيك واجهة المستخدم، وحصر مكوناتها، وتعريف العناصر والأنماط الأساسية التي نستند إليها في بناء الصفحات الجديدة.

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

سمّوا الأشياء سويًا، بناءً على وظيفتها الشاملة

بعد أن تؤسّس القاعدة، من المهم أن تُطوّر اللغة الجماعية التي تستخدمها داخل الفريق. وأحد أهم جوانب ذلك هو تسمية المكوّنات التي تُنتجها.

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

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

يشرح التربوي البريطاني الشهير جيمس بريتون في كتابه اللغة والتعلّم (Language and Learning) أن عملية تسمية الأشياء هي، في جوهرها، عملية إبداعية تُضفي على الأشياء وجودًا ومعنى. كما الأطفال، حين يستخدمون اللغة لـ”استحضار العالم من العدم”. وبالمثل، فإن أي كائن داخل الواجهة لا يحمل اسمًا واضحًا ومفهومًا من قِبل أعضاء الفريق، لا يُمكن التعامل معه بوصفه وحدة نمطية حقيقية قابلة للبناء أو التعديل أو الاختبار.

وحين تطلق على كائن ما اسمًا، فأنت في الواقع تحدد مستقبله. فلو منحته اسمًا شكليًا (presentation-based)، سيظل محصورًا في نمط معين. أما إن منحتَه اسمًا وظيفيًا (function-based)، فقد تكون قد وسّعت أفق استخدامه، ولكن الوصول إلى اسم وظيفي يتطلب جهدًا فكريًا أكبر، لأن الوظيفة مسألة نسبية.

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

في الوقت ذاته، وفي مشروع آخر، ابتكر أحد المصممين مكونًا آخر بدا شبيهًا جدًّا بـ”ملصق الدورة” (باستثناء بعض الفروقات الطفيفة في التخطيط والطباعة). لكن وظيفته كانت دعوة المستخدمين للمشاركة في نقاش. فجاءت التسمية الأولى في ذهننا: “مكون النقاش”.

لم يخطر في بال أحد الربط بين “ملصق الدورة” و”مكون النقاش”، لأن كل اسم قيد فهمنا له في سياق وظيفة واحدة ومحددة، لا تتقاطع مع الأخرى.

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

لكن عندما أعدنا النظر إلى السياق العام لكلٍ منهما بل وتخيلنا سيناريوهات استخدام إضافية، تبيّن لنا أن الوظيفتين متقاربتان للغاية: كلاهما يعمل على جذب انتباه المستخدم إلى دعوة للفعل (call to action). أي أن وظيفتهما العليا هي تسليط الضوء على الإجراء الأهم داخل الصفحة.

وفي النهاية، قررنا توحيدهما في مكون واحد يحمل اسمًا وظيفيًا عالي المستوى: “لوحة إعلانية” (billboard).

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

تسمية المكونات: اتفاق جماعي يحدّد طريقة استخدامها

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

“لغة التصميم” جزء من الثقافة اليومية للفريق

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

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

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

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

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

ضع معمارية CSS في الحسبان مع بدء مرحلة التصميم

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

هناك الكثير من المقالات التي تناقش كيفية تعديل مظهر المكونات حسب السياق، لكن المصمم هاري روبرتس يشير إلى أن “الحاجة إلى تغيير المظهر في سياق معين هو رائحة عطب في التصميم” (Design Smell) أي علامة على أن التصميم يفتقر إلى الصلابة.

فكيف نتجنّب ذلك؟

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

وقبل كتابة أي شيفرة CSS، من المهم أن يطرح المصممون والمطورون معًا أسئلة مثل:

• هل سيكون هذا المكون بعرض الصفحة دومًا؟ ولماذا؟
• هل سيتضمن دائمًا هذه الأزرار؟
• هل الخط قد يتغير في المستقبل؟
• هل وجود الخلفية المصورة أساسي؟
• هل الخطوط الفاصلة الأفقية جزء من الوحدة (molecule) أم مجرد زينة؟

الإجابة على هذه الأسئلة تساعدنا على ضمان التناسق بين نية التصميم والتنفيذ الفعلي. فقد نقرر، مثلًا، تحديد بعض الأنماط (styles) على مستوى العنصر الذري (atomic level)، بدلًا من المكوّن الكُلي (organism level)، لنجعل من السهل تعديلها لاحقًا دون تغيير الوحدة كاملة.

أشرك المستخدمين في عملية التصميم

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

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

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

الخُلاصـــــة

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

تسمية العناصر جماعيًّا عادةٌ ثمينة ينبغي للفريق تنميتها؛ فخلال البحث عن اسمٍ معبِّر، يتجلّى دور العنصر وتُحسَم وظيفته، والأهمّ أنّ الفريق يتوصّل إلى إجماع حولها. والاسم المتَّفَق عليه هو ما يحدّد آليّة بناء العنصر ويشجّع على استخدامه استخدامًا متّسقًا بين الجميع. وكما تقول آبي كوفرت: «إن لم تظفر بالاتفاق منذ البداية، فاستعدّ للمزيد من العمل لاحقًا.»

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

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

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

المقال_ مترجم_ بتصرف_ من المصدر: The Language of Modular Design