تدقيق تجربة المستخدم في أسبوعين: القائمة التي نستخدمها قبل أي إعادة تصميم

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

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

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

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

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

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

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

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

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

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

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

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

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

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

كم مستخدماً تكفيهم الجلسات؟ خمسة إلى ثمانية لكل شريحة. هذا يكفي للمشكلات المتكررة، وليس دراسة إحصائية.

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

هل تشمل إمكانية الوصول؟ نعم، بمعيار WCAG 2.2 AA، مع فحص يدوي للوحة المفاتيح وقارئ الشاشة.

ماذا لو كنا نعرف المشكلة مسبقاً؟ نختبر السبب المفترض قبل أن نبني الحل. كثير من الفرق تعرف العَرَض وتخطئ في السبب.

هل التدقيق كافٍ لبدء البناء؟ نعم إذا كان النطاق مساراً واحداً. المنتج الكامل يحتاج تعريفاً وتصميماً بعده.

• W3C: ما الجديد في WCAG 2.2 — تسعة معايير نجاح أضيفت في 5 أكتوبر 2023.
• Baymard: قابلية استخدام الدفع — 11.3 حقلاً في المتوسط، و22% تخلّوا بسبب التعقيد.
• McKinsey: القيمة التجارية للتصميم — لماذا يستحق التصميم قياساً لا رأياً.
• تصميم وبحث تجربة المستخدم في رصد — كيف ننفّذ التدقيق والتصميم.