كيفية الحصول على اعتماد واسع النطاق لنظام التصميم الخاص بك

استخدام الوثائق لزراعة الملكية المشتركة بين التصميم والتطوير

هذا المنشور هو الثاني في سلسلة حول HubSpot Canvas ، لغتنا التصميمية الجديدة. اقرأ الأول هنا.

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

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

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

لقد كان الكثير من العمل. ولكن كان سيكون هناك الكثير من العمل إذا لم نتعلم درسًا رئيسيًا على طول الطريق:

لا تعمل إعادة التصميم إلا عندما يكون المصممون والمطورون مشتركين.

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

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

الرياح المعاكسة والخياطين

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

الخلفية

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

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

الرياح المعاكسة

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

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

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

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

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

  1. لم يضطر أي شخص إلى تغيير منطق المكدس أو العمل.
  2. كان التناقض يجرنا إلى أسفل. رأى مديرو المنتجات ذلك في تعليقات المستخدمين. رأى المصممون ذلك في العديد من درجات اللون الرمادي عبر منتجاتنا. رأى مطورو البرامج في العديد من مكتبات منتقي التواريخ. بدا أن مكتبة مكونات موثوقة وقابلة لإعادة الاستخدام تم بناؤها وصيانتها من قبل فريق آخر تبدو رائعة.
  3. نظام التصميم الجديد ، HubSpot Canvas ، بدا جيدًا. مثل ، حقا جيدة.

من مشروع إلى عملية

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

هذا لن يعمل من أجلنا.

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

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

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

لكن.

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

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

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

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

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

كان الحل واضحًا ، لكنه لن يكون سهلاً.

نحن بحاجة إلى وثائق أفضل.

إنشاء دليل أسلوب المعيشة

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

كنا نعلم أننا نريد أن تكون وثائقنا:

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

زرع البذور

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

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

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

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

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

من أجل مساعدة المصممين على الانتقال بسلاسة بين Sketch ووثائق المكونات ، قررنا أن نظهر التنقل ، والهيكل ، والمصطلحات في مجموعة Sketch ومكتبة UI ، وطورنا نظامًا للاحتفاظ بالتحديثات في مجموعة Sketch ومكتبة UI في lockstep .

إزهار كامل

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

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

احتاج المطورون أيضًا إلى صندوق رمل حيث يمكنهم اختبار المكونات بسرعة ، لذلك قمنا بتحسين تجربة التحرير في الوقت الفعلي للمكونات في المكتبة من خلال تضمين محرر كود React مع جميع مكوناتنا في نطاق (مع استكمال تسليط الضوء على الإمكانات وإمكانات Prettier). لقد جعلنا أيضًا من السهل نقل هذه الأمثلة إلى محرر خالٍ من الهاء يعرض المكونات على الفور ، بحيث يمكن للمطورين استخدامها كمساحة لإنشاء بدايات تصميم أو لاختبار مجموعة معينة من المكونات. بعد ذلك ، يمكنهم بعد ذلك مشاركتها بسهولة مع HubSpotters الآخرين ، مما يتيح لهم سرعة تكرار الأفكار والتصحيح ومشاركتها بسهولة والحلول المقترحة.

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

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

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

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

التأثير

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

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

100000/10
اللهم إن إطار واجهة المستخدم في الواجهة الأمامية رائع وسنوات ضوئية قبل أي إطار واجهة مستخدم تفاعلي مفتوح المصدر

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

نرى ذلك بنفسك

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

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

ائتمانات:
الرسوم التوضيحية التي كتبها سو يي

نشرت أصلا على مدونة المنتج HubSpot