محادثات التصميم: تعاون أفضل بين المصممين والمطورين مع Aarron Walter من InVision

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

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

يعتمد Aarron على 15 عامًا من الخبرة في إدارة فرق المنتجات وتدريس التصميم لمساعدة الشركات على سن أفضل ممارسات التصميم. أسس ممارسة UX في MailChimp وساعد في نمو المنتج من بضعة آلاف مستخدم إلى أكثر من 10 ملايين.

ساعدت إرشاداته في التصميم البيت الأبيض ووزارة الخارجية الأمريكية وعشرات من الشركات الكبرى والشركات الناشئة وشركات رأس المال الاستثماري. وهو مؤلف الكتاب الأكثر مبيعًا Designing for Emotion من A Book Apart. ستجدaarron على Twitter تشارك الأفكار حول التصميم ويمكنك معرفة المزيد عن Aarron على موقع aarronwalter.com.

على Design Better Podcast ، يستضيف كل من Aarron Walter و Eli Woolery قادة التصميم والمؤثرين الذين يشاركون قصصًا عن كيفية حل المشكلات ومسار حياتهم المهنية. من بين الضيوف ديفيد كيلي (المؤسس المشارك لـ IDEO ومؤسس Stanford d.school) وجولي Zhuo (نائب الرئيس للمنتجات والتصميم في Facebook) وجيك كناب (مؤلف Sprint الأكثر مبيعًا) من بين آخرين.

مرحبًا Aarron ، يسعدني أن تكون على مدونة Toptal Design Blog. هل المطورون من المريخ ومصممون من كوكب الزهرة؟

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

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

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

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

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

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

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

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

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

حول فهم فضاء بعضنا البعض بشكل أفضل ...

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

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

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

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

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

يمكن أن يكون قابلاً للقياس الكمي ، على الرغم من أن مكون الجودة سيحقق عائد استثمار قابل للقياس الكمي.

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

حول مخاطر تعاون المصممين والمطورين ...

ما هي بعض أكبر المخاطر التي يواجهها المصممون والمطورون معًا؟

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

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

في هذه البيئة ، يعد تقديم حالة لميزة UX أمرًا صعبًا للغاية بالنسبة للمصمم: "يجب أن يكون لدينا هذه الرسوم المتحركة في المنتج لأنها ستخلق تجربة أكثر إقناعًا ..." عندما يقول 75 مهندسًا: "هذا 250 آخرين أسطر من التعليمات البرمجية ويومين عمل إضافيين. هل حقا يستحق كل هذا العناء؟ " وربما لا. بالنسبة لهم ، سوف يبدو مثل "صقيع". لكن تلك التفاعلات الصغيرة المتحركة لمصمم UX تشكل بالفعل تجربة العميل. إنهم ليسوا الشيء الوحيد ، لكنهم مهمون.

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

عن المصممين الذين يوضحون أهمية تجربة المستخدم ...

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

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

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

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

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

حول مستقبل تعاون المصممين والمطورين ...

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

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

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

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

مزيد من القراءة على مدونة Toptal Design:

• كيفية الاقتراب من التصميم للمطورين
• محادثات التصميم: بحث عملي مع باحثة UX Caitria O'Neill
• محادثات التصميم: تصميم ذكي عاطفياً مع باميلا بافليسكاك
• محادثات التصميم: السعي وراء التصميم القائم على القيمة مع نيك ديساباتو
• كيفية الانتقال من UX Designer إلى UX Consultant