كيف يمكن لمطوري الواجهة الأمامية تمكين عمل المصمم

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

اليوم ، أود أن أشارككم النصائح العملية التي ساعدتني على التعاون بكفاءة أكبر مع المصممين في السنوات الماضية.

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

فهم خلفية مصممي UX

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

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

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

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

تبني طريقة جديدة في التفكير

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

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

ملاحظة : هناك دورة تدريبية عبر الإنترنت تُعرف باسم "تصميم للمطورين" وكتاب يسمى "Refactoring UI" - وكلاهما مفيد للبدء. باستخدام هذه ، ستتمكن من تنفيذ واجهات المستخدم بعين حادة للحصول على التفاصيل واكتساب نفوذ كبير عند التواصل مع المصممين.

تضخيم وعي المصممين لديك

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

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

علمهم الكود ، وليس كيفية البرمجة

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

اجلس بجوار المصمم الذي تعمل معه لمدة 15 دقيقة وعلمهم كيف يمكنهم أن يروا بأنفسهم ما إذا كانت مواصفات عنصر ما صحيحة وكيفية تغييرها. أجد أن Firefox Page Inspector سهل الاستخدام بشكل ملحوظ لهذا الغرض.

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

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

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

اطلب من المصممين تضمينك في عملية التصميم الخاصة بهم

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

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

قد نستخدم أدوات مختلفة ، لكن يجب أن نتحدث نفس اللغة

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

النظر إلى ما وراء محرر الكود

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

استخدام أنظمة واجهة المستخدم كعقد

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

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

الاعتراف بالمصدر الحقيقي للحقيقة

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

السيطرة على الدين

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

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

لا يعني إمكانية الوصول إليها أن تكون قبيحًا

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

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

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

إعطاء ملاحظات قيمة للمصممين

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

في وقت سابق ردود الفعل ، كان ذلك أفضل

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

اشرح الأفكار المجردة بعبارات بسيطة

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

لا تدع الافتراضات تتحول إلى قرارات

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

لا تفعل الحلول بنفسك

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

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

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

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

فكر فيما وراء الحالة المثالية - معًا

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

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

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

سيوفر لك أخذ كل هذه السيناريوهات في الاعتبار الكثير من الوقت ذهابًا وإيابًا خلال مرحلة التطوير.

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

قبول طلبات التغيير

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

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

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

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

خاتمة

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

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

القراءة ذات الصلة على SmashingMag:

• "تصميم للمطورين" بواسطة Mason Gentry
• "العمل معًا: كيف يمكن للمصممين والمطورين التواصل لإنشاء مشاريع أفضل" بقلم راشيل أندرو
• "كيف يمكن لمطوري الواجهة الأمامية المساعدة في سد الفجوة بين المصممين والمطورين" بقلم ستيفان كالتينيجر
• "ما البودكاست الذي يجب على مصممي الويب والمطورين الاستماع إليه؟" بواسطة ريكي أونسمان