أنظمة التصميم تدور حول العلاقات

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

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

ومع ذلك ، فإن أنظمة التصميم لا تختفي. فقط 15٪ من المؤسسات تفتقر إلى نظام التصميم في عام 2018 ، وفقًا لإحدى الدراسات الاستقصائية. هذا أقل من 28٪ في العام السابق. تستخدم بعض الفرق أنظمة تصميم كبيرة للأغراض العامة مثل تصميم المواد من Google ، بينما يستخدم البعض الآخر أنظمة أصغر وأكثر تفصيلاً مثل REI's Cedar و Mozilla Protocol.

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

الصورة الكبيرة

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

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

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

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

ومع ذلك ، اطلع على التصميم أو مجمعات الأخبار الهندسية ومن المحتمل أن ترى تركيزًا واضحًا على ذلك "النظام الفرعي التقني" - الكود والأدوات ، بدلاً من الأشخاص والمحادثات. ما الأداة الإبداعية الأفضل في تتبع رموز التصميم؟ ما هي تقنيات JavaScript التي يجب استخدامها لبناء مكونات قابلة لإعادة الاستخدام - React ، أو مكونات الويب ، أو أي شيء آخر؟ أي أداة بناء هي الأفضل؟

الجواب على هذه الأسئلة ، بالطبع ، "يعتمد!" من سيقوم بتصميم وبناء واستخدام النظام؟ ما هي احتياجاتهم؟ ما هي القيود التي يعملون في ظلها؟ ما هي الأدوات والتقنيات التي يشعرون بالراحة معها؟ ماذا يريدون أن يتعلموا؟

للإجابة على هذه الأنواع من الأسئلة ، يوصي Baxter و Sommerville بنوعين من الأنشطة:

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

يحفر

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

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

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

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

ضع كل شيء معا

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

• يحتوي التصميم متعدد الأبعاد من Google على العديد من التطبيقات في أطر ولغات مختلفة. يتم استخدامه من قبل مجموعة متنوعة من الأشخاص داخل وخارج Google ، لذلك فهو يحتوي على وثائق شاملة ومجموعة متنوعة من مجموعات الأدوات لتطبيقات التصميم.
• يستهدف نظام Fluent Design System من Microsoft أربع منصات مختلفة جدًا. مثل المواد ، فهو يتضمن مجموعات أدوات لمصممي UX ووثائق شاملة.
• يتم تطبيق بروتوكول Mozilla في Sass و Vanilla JavaScript. لديها تركيز قوي على التدويل. يقول Alex Gibson أن هذا النظام يساعد Mozilla على "إنشاء صفحات ويب على العلامة التجارية بوتيرة أسرع مع عمل يدوي أقل تكرارًا."
• تم تصميم REI's Cedar باستخدام مكونات Vue.js ولا يمكن استخدامه مع أطر عمل JavaScript أخرى. يستخدم Cedar بشكل أساسي من قبل المطورين الداخليين لـ REI ويرتبط ارتباطًا وثيقًا بعلامة الشركة التجارية. رمز نظام التصميم مفتوح المصدر ، لكن خطوطه ليست كذلك.
• نظام Lightning Design System الخاص بـ Salesforce هو إطار عمل CSS لا يعتمد على JavaScript. يمكن استخدامه اختياريًا جنبًا إلى جنب مع Lightning Component Framework ، والذي يتضمن تطبيقي JavaScript: أحدهما يستخدم مكونات الويب والآخر يستخدم إطار عمل Aura الخاص بـ Salesforce.
• تم إنشاء PatternFly من Red Hat لتوفير تجربة مستخدم متسقة عبر منتجات النظام الأساسي السحابي للشركة ، لذلك فهي تتمتع بكثافة معلومات عالية نسبيًا وتتضمن مجموعة متنوعة من مكونات تصور البيانات. تحول فريق PatternFly مؤخرًا من Angular إلى React بعد بعض التجارب مع مكونات الويب. يتضمن PatternFly أيضًا تطبيقًا لا يعرف لغة JavaScript باستخدام HTML و CSS. (الإفصاح الكامل: أنا من فريق Red Hatter سابقًا.)
• يوفر نظام تصميم الكربون من IBM تطبيقات في React و Vue و Angular و Vanilla JavaScript بالإضافة إلى مجموعة أدوات تصميم لـ Sketch. يقوم فريق Carbon بإجراء تجارب على مكونات الويب. (نصيحة القبعة لجوناثان سبيك لتعقب هذا المستودع).

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

أوضح جوش ماتيو وبريندون مانوارنج أن مصممي Spotify "يرون دورهم كمساهمين أساسيين ومؤلفين مشاركين لنظام مشترك - وهو نظام يمتلكون ملكيته." تصف مينا ماركهام نفسها بأنها "المترجمة بين الهندسة والتصميم" في نظام تصميم Pantsuit. تتعمق جينا آن في ديناميكيات الفريق وأبحاث المستخدم وراء أنظمة التصميم: "تنبيه المفسد! ستحتاج إلى أكثر من مجرد مصممين ".

دعونا نبني بعض الأشياء!

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

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

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

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

ضع في اعتبارك البدء صغيرًا من خلال إعداد بعض العناصر الأساسية:

• نظام التحكم في الإصدار لتخزين التعليمات البرمجية الخاصة بك. GitHub و GitLab و Bitbucket كلها خيارات رائعة هنا. تأكد من أن كل شخص يستخدم النظام يمكنه الوصول إلى الكود واقتراح التغييرات. إذا كان ذلك ممكنًا ، ففكر في جعل الكود مفتوح المصدر للوصول إلى أكبر عدد ممكن من الجمهور.
• كود CSS لتنفيذ النظام. استخدم متغيرات Sass أو خصائص CSS المخصصة لتخزين "الرموز المميزة للتصميم" - القيم الشائعة مثل العروض والألوان.
• ملف package.json يحدد كيف يمكن للتطبيقات بناء نظام التصميم وتثبيته.
• توثيق HTML الذي يوضح كيفية استخدام نظام التصميم ، من الناحية المثالية باستخدام CSS الخاص بالنظام.

توضح وثائق node-sass لإطار عمل CSS Bulma هذه الخطوات بمزيد من التفصيل قليلاً. يمكنك تخطي تثبيت واستيراد Bulma إذا كنت ترغب في البدء من نقطة الصفر ، أو يمكنك تضمينه إذا كنت ترغب في البدء ببعض الأساسيات الموجودة.

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

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

أخيرًا ، ضع في اعتبارك نشر نظام التصميم الخاص بك كحزمة على npm بحيث يمكن للمطورين استخدامه عن طريق تشغيل الأمر npm install your-design-system . بشكل افتراضي ، تكون حزم npm عامة ، ولكن يمكنك أيضًا نشر حزمة خاصة ، أو نشر الحزمة إلى سجل خاص ، أو مطالبة المطورين بتثبيت الحزمة مباشرة من نظام التحكم في الإصدار. سيسهل استخدام مستودع الحزم اكتشاف التحديثات وتثبيتها ، ولكن التثبيت مباشرة من التحكم في الإصدار يمكن أن يكون حلاً سهلاً قصير المدى لمساعدة الفرق على البدء.

إذا كنت مهتمًا بمعرفة المزيد عن الجانب الهندسي للأشياء ، فإن Katie Sylor-Miller Building Your Design System توفر لك تجربة غوص عميقة رائعة. (الكشف الكامل: لقد عملت مع كاتي).

تغليف

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

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

مزيد من القراءة على SmashingMag:

• نصائح لإدارة أنظمة التصميم
• بما في ذلك الرسوم المتحركة في نظام التصميم الخاص بك
• ما وراء الأدوات: كيف يمكن أن يؤدي بناء نظام التصميم إلى تحسين طريقة عملك
• بناء نظام تصميم واسع النطاق لحكومة الولايات المتحدة (دراسة حالة)