مقدمة:
يُفترض أن تربط المصمم علاقة جيدة بفريق المنتج والمستخدمين، لكن بناء علاقته بالمطورين وصيانتها أصعب. ويصعّب غياب القرب حل المشكلات والتحسين. ومن خبرتي، يمكن لإطار القرار المفتوح تجاوز كثير من هذه العقبات.
يؤكد الإطار أن القرار المفتوح شفاف وشامل ومتمركز حول العميل؛ يشارك المشكلات والمتطلبات والقيود بوضوح مع المتأثرين، ويتيح تعاون أصحاب المصلحة لآراء متنوعة وملاحظات شاملة. والأهم إدارة العلاقات والتوقعات بين احتياجات وأولويات متنافسة.
وغالبًا يتفق مع هذه المبادئ كل من يشارك في قرارات تصميم منتج أو وظيفة أو خدمة. والمطور صاحب مصلحة أساسي لأفضل قرارات التصميم؛ فليرحب المصمم بتنوع الرأي.
البنية الخلفية وتجربة المستخدم:
لا تقتصر التجربة على بكسلات الشاشة أو سير العمل. فهي تشمل أداء الخدمة، وسرعة استدعاءات API ، ومعالجة بيانات المستخدم، وحتى تصميم البيانات للتوسع. وحين يُعد المطور شريكًا كاملًا، يقدم خبرته في البنية الخلفية والمعمارية لتحسين التجربة كلها.
ومصمم UX صاحب مصلحة فيما يتولاه فريق التطوير؛ فضعف الأداء أو أثر المعمارية في البيانات المتاحة قد يعرقل التجربة. وتتيح العلاقة المفتوحة التعاون والثقة والشفافية في الجوانب جميعًا.
إفساح المجال للتعاون:
ليست العلاقة المفتوحة بين الطرفين شائعة كما ينبغي، وقد تكون جديدة لكليهما. وهذه نصائحي الخمس.
1. خصص موعدًا متكررًا: يجتمع التصميم والتطوير بوتيرة بين أسبوع وشهر، ويشمل الحضور على الأقل UX وقائد الهندسة وهندسة الجودة، والأفضل دعوة المطورين جميعًا حسب إتاحة الوقت.
2. اجعل المشاركة أساس الاجتماع: يعرض UX حالات الاستخدام والوظائف الجارية وبيانات البحث ذات الصلة، ويشرح سير العمل والمخططات الهيكلية والنماذج عالية الدقة. ويشارك التطوير قراراته التصميمية التي قد تؤثر في التجربة.
3. شجع الأسئلة: ادعُ الجميع للسؤال والتعليق؛ فالإجابات وردود الفعل فرص لنقاش التصميم والاتجاه والتعلم المتبادل.
4. تبنَّ عقلية التعلم: تجنب المحاضرة أو الإملاء، واطلب التعلم من الآخر. وظفوا خبراتكم لبناء تجربة رائعة، واسألوا عن شرح التقنيات والمفاهيم غير المألوفة.
5. فكر في التعلم المنظم: يسهل التعاون حين يتحدث الطرفان لغة مشتركة. فقد يفيد المصممَ مقرر أساسيات برمجة مثل Odin Project المفتوح لفهم إنشاء الخدمة وبنائها. ويفيد المطورَ فهم مبادئ UX لتوجيه أسئلته وملاحظاته، من مقدمات المبادئ والكتب والمقالات.
مثال:
في مراجعة تصميم مبكرة مع مطور بفريقي، عرضت تفاعلًا معينًا لإظهار بيانات إضافية عن كائن، وشرحت حاجة المستخدم. فسأل: هل يلزم تنفيذه بهذه الطريقة تحديدًا؟ وأوضح أن تغييرات طفيفة ستخفض جهد التطوير كثيرًا. واتفقنا على أنها لا تضر التجربة ولا تمنع إنجاز الغاية.
وفرت الملاحظة وقتًا أتاح معالجة الأخطاء وبناء وظائف إضافية وحماية التوازن بين الحياة والعمل. وظلت التجربة قوية، وأصبح الفريق أقوى. وما كان ذلك ممكنًا دون رأي مبكر من مطور تربطني به علاقة عمل جيدة.
خطوتك التالية:
إنشاء التجربة سلسلة قرارات لفريق متعاون. وينبغي أن يعمل المنتج والتصميم والتطوير خبراء في مجالاتهم وأصحاب مصلحة في المجالات الأخرى. وأشجع على إشراك الطرفين في الملاحظات والعمل معًا لأفضل منتج وأفضل تجربة.
المراجع:
https://www.redhat.com/en/topics/api/what-are-application-programming-interfaces?intcmp=7013a000002qLH8AAM
https://www.redhat.com/architect/keycloak-ui-architecture?intcmp=7013a000002qLH8AAM
https://developers.redhat.com/cheat-sheets/advanced-linux-commands/?intcmp=7016000000127cYAAQ
https://www.redhat.com/en/services/training/rh024-red-hat-linux-technical-overview?intcmp=7016000000127cYAAQ
https://console.redhat.com?intcmp=7016000000127cYAAQ
https://www.theodinproject.com/