المطوِّرون "يمتلكون" الكود ، لذا ألا يجب على المصممين "امتلاك" التجربة؟

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

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

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

مزيد من القراءة على SmashingMag:

  • لماذا يجب عليك تضمين المطور الخاص بك في عملية التصميم
  • تعاون الفريق وسد فجوات الكفاءة في التصميم سريع الاستجابة
  • المصممين والمطورين يلعبون بشكل جيد
  • كيفية التواصل الفعال مع المطورين

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

المزيد بعد القفز! أكمل القراءة أدناه ↓
عندما يشارك العديد من الأشخاص في مشروع ما ، من المهم جدًا التأكد من أن لديهم فهمًا مشتركًا للمشكلة وحلها.
عندما يشارك العديد من الأشخاص في مشروع ما ، من المهم جدًا التأكد من أن لديهم فهمًا مشتركًا للمشكلة وحلها. (رصيد الصورة: The Next Web)

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

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

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

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

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

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

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

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

التواصل هو المفتاح ، لذا كن متاحًا.
كل شخص لديه رأي. ومع ذلك ، ليس سببًا جيدًا كافيًا للتعمق في الأمر والبدء في إجراء التغييرات. رصيد الصورة: Open Source Way

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

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