سد الفجوة بين المصممين والمطورين

هذه المقالة مدعومة من أصدقائنا في UXPin ، وهي أداة تصميم ونماذج أولية لواجهة المستخدم تمنح نماذجك الأولية القوى الخارقة التي تستحقها: الحالات ، وتعبيرات JS ، والمتغيرات ، والتفاعلات الشرطية ، ومزامنة Git. ومع ذلك ، لا تتأثر هذه المقالة بـ UXPin بأي شكل من الأشكال وتعبر عن الرأي المستقل للمؤلف. شكرا لك!

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

لنلقِ نظرة على معضلة نموذجية:

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

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

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

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

جوهرة مخبأة في كل هذه الفوضى

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

الخروج مع العملية القديمة

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

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

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

مع العملية الجديدة

لذا ، قد تتساءل ، كيف تساعد تقنية UXPin Merge في هذه العملية الفائقة التي نستخدمها جميعًا اليوم؟ حسنًا ، ألق نظرة على الرسم البياني أدناه. قد تلاحظ إنشاء مكون ولا توجد حاجة للمتغيرات (في معظم الحالات). تقلل هذه العملية الجديدة من مقدار العبث بأدوات التخطيط التلقائي ، بسبب علاقتنا المتآزرة الآن مع المطورين:

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

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

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

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

لكن يكفي عن هذه العملية. لنلق نظرة على كيفية عمل UXPin Merge.

إدارة المكتبات

أفضل جزء هو أنه يمكن استيراد المكتبات مباشرة من مستودع الشفرة الخاص بك مثل GitHub و Bitbucket و GitLab (يعمل فقط لمكونات React) أو حتى من Storybook. بمجرد إنشاء مكتبة ، سيكون لديك خيارات لتسمية المكتبة.

عند الاستيراد باستخدام Storybook ، تكون العملية واضحة تمامًا. ما عليك سوى الحصول على عنوان URL الخاص بالمكتبة ، وسيقوم UXPin بالباقي نيابةً عنك. باستخدام مكونات React ، باستخدام CLI ، يمكنك التحكم في المكونات التي يتم نشرها عن طريق تحديد الرمز المميز الفريد لمكتبة UXPin.

التحكم في الإصدار والاختبار

يعد التحكم في الإصدار أحد أكبر مخاوف المصممين وفرق أنظمة التصميم. يمكن حل معظم المخاوف باستخدام ميزة دمج UXPin هذه. دعنا نرسم صورة سريعة:

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

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

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

تحديثات الاختبار

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

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

التصميم مع الكود

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

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

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

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

تسليم

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

إمكانية الوصول

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

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

التخطيطات والقوالب والشبكات

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

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

في الختام

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