عندما يلتقي التصميم بالهندسة في Traveloka

هذه ليست قصة حب عادية.

ملاحظة: هذه مجرد واحدة من التفاعلات بين التصميم والهندسة. أنا أتحدث من طيف واحد صغير من جميع التفاعلات بين التصميم والهندسة في Traveloka. وهذه هي قصتي.

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

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

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

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

متى التقيا لأول مرة؟

بدأت المحادثات في بداية عام 2018 عندما قام فريق الهندسة بإجراء بعض الأبحاث حول React Native و React Native Web (React Native هو إطار لإنشاء تطبيقات الأجهزة المحمولة باستخدام JavaScript). عندما بدأ هذا البحث ، انخرط Web UI Developers من فريق التصميم.

خلال هذه العملية ، كان لدى فريق الهندسة فكرة استخدام React Native كقاعدة لتطوير الأنظمة الأساسية المشتركة. يتضمن ذلك تطوير الويب المحمول الذي يمكن أن يشتمل Web UI Developer فيه على إنشاء مكونات عليه.

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

كيف نما الحب؟

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

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

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

حيث أدى الحب لنا؟

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

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

1. نظام التصميم القائم على الكود.

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

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

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

2. رسم الإضافات.

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

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

3. تصميم linter والاختبار البصري متكامل.

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

4. تصميم وثائق النظام.

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

التوضيح من جانب Ralistu Hayu Pratiwi

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

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

"التصميم ليس فقط ما يبدو ويشعر. التصميم هو كيف يعمل."