هل أعتمد على نماذج تصميم UX في اتخاذ القرار — وكيف أميز بين الجيد والسيئ؟

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

اختبر النموذج الذي تضعه الوكالة أمامك في الاجتماع وفق هذه المعايير الثلاثة: 1) البحث والتصفية: هل يمكنك تضييق نطاق الفلترة بنقرتين في ظل وجود عشرات الخصائص التقنية المعقدة في الصفحة؟ 2) كثافة المعلومات: هل يستطيع الحرفي رؤية قطر القطعة والموديلات المcompatible معها في شاشة واحدة أم يمل من التمرير لأسفل؟ 3) تعقيد النماذج: كم عدد الحقول غير الضرورية المطلوب تعبئتها عند الطلب؟

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

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

هل أرسلت لكم الوكالات لقطات شاشة ثابتة أم قدمت نماذج تفاعلية قابلة للنقر (prototypes)؟ وهل تحدثتم مع ثلاثة عملاء حقيقيين على الأقل من قطاعكم يشترون منكم لمعرفة أين يواجهون أكبر العثرات في الموقع الحالي؟

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

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

وقعنا في خطأ مماثل قبل سنتين. انخدعنا بالحركات الدقيقة (micro animations) في معرض الوكالة ووقعنا العقد. وعند تسليم المشروع اكتشفنا أن النظام لا يستطيع تقسيم البيانات التقنية القادمة من ربط ERP والتي تحتوي آلاف المواد إلى صفحات. المصمم رسم الشاشة بثلاثة أسطر من البيانات الوهمية، وعند ربط قاعدة البيانات الحقيقية تحولت الشاشة إلى فوضى عارمة.

زالت حيرتي، شكراً لكم. يجب ربط جدول المدفوعات بمراحل العمل، وليس بالتقويم.

لو كنت مكانك، لسلك هذا المسار.

أوافق.

كنت أفكر في نفس الشيء. النظام يستمر بعد التسليم؛ الصيانة بند منفصل.

اكتبوا إذا كانت لديكم أسئلة، سأجيب قدر استطاعتي.

أكتب هذا حتى لا تكرروا نفس الخطأ. كل بند غير مكتوب هو بند سيتذكره الطرفان بشكل مختلف لاحقًا.

مثبت بالتجربة.

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

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

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

أتمنى أن يفيدك هذا.

هناك فخ هنا، لا أريد المرور عليه دون ذكره. لا تترددوا في السؤال، فالسائل يدفع ثمناً أقل دائماً.

بالتوفيق.

سأجرب ذلك. كل من يستعجل في نماذج تصميم ux يتعثر في نفس النقطة.

معظم إضاعة الوقت تتراكم في المهام المنتظرة للموافقة.

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

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

لم أكن أعلم بهذا.