ابدأ مشروع إعادة تصميم بداية الاستخدام بتعريف أول نتيجة مفيدة، لا بهدف تقليل عدد الشاشات وحده. قد يحتاج تطبيق الحجز إلى اختيار خدمة وموعد صالح وتلقي تأكيد مفهوم. إنشاء حساب مكتمل أو مشاهدة جميع رسائل الترحيب ليس بالضرورة تلك النتيجة. لذلك يجب أن يحدد الموجز المهمة التي يريد الشخص إنجازها، والمعلومات الضرورية لها، وما يمكن تأجيله دون إرباك التشغيل.
تقليل الخطوات قد يجعل الرحلة أقصر، لكنه قد يخفي شروطاً يحتاج المستخدم فهمها. وفي المقابل، جمع كل تفضيلات العميل قبل عرض أي فائدة يحمّله عملاً لا يعرف سببه. المطلوب ترتيب القرارات بحسب وقت الحاجة إليها، مع بقاء الاختيار والرفض والتصحيح واضحاً.
ما الذي نعرفه عن التعثر؟
اجمع خريطة الرحلة الحالية، وتعريفات الأحداث إن وجدت، وشكاوى الدعم ذات الصلة بعد إزالة البيانات الشخصية غير اللازمة. افصل بين من لم يبدأ المهمة، ومن حاول وتعذر عليه الاستمرار، ومن اختار المغادرة لأن الخدمة لا تناسبه. هذه الحالات لا تعالج بالطريقة نفسها.
لا يكفي أن يقول الفريق إن «التسجيل طويل». اطلب أمثلة: هل يسأل التطبيق عن معلومة لا يملكها الشخص؟ هل يبدو إرسال الرمز كأنه إنشاء حجز؟ هل يختفي الموعد أثناء التسجيل؟ إذا لم تتوافر أدلة، اكتب هذه النقاط كفرضيات للبحث، لا كأسباب مؤكدة.
يمكن لـبحث المستخدمين مشاهدة تنفيذ مهمة أولى محددة. توصي إرشادات GOV.UK بصياغة مهام اختبار لا تكشف للمشارك طريقة الحل. لذلك قل «احجز زيارة مناسبة» بدلاً من «اضغط متابعة ثم أنشئ حساباً». دليل اختبار قابلية الاستخدام.
صنّف كل طلب قبل أن تحذفه
أنشئ جدولاً داخلياً لكل حقل أو إذن أو قرار، ثم اسأل:
- ما القرار التشغيلي الذي يعتمد عليه؟
- هل يلزم قبل عرض الخدمة، أم عند الحجز، أم بعده؟
- من يعتمد ضرورته وصياغة شرحه؟
- ماذا يحدث إذا رفضه الشخص أو لم يعرف الإجابة؟
- هل يمكن تعديل الإجابة لاحقاً، وأين؟
فريق المنتج يوضح الحاجة التشغيلية، ويؤكد مختص العميل المتطلبات النظامية أو المتعلقة بالخصوصية عند انطباقها. لا يُطلب من المصمم اختراع أساس لجمع البيانات أو حذف موافقة لازمة لتحسين رقم التحويل. كما لا تفترض أن طلب صلاحية الجهاز في شاشة مبكرة مناسب لكل منصة؛ تُراجع التفاصيل مع المطور وفق التنفيذ الفعلي.
مثال افتراضي: أول حجز لخدمة منزلية
لنفترض أن التطبيق يبدأ بست مجموعات: إنشاء الحساب، بيانات التواصل، اختيار الخدمة، الموعد، العنوان، وتفضيلات عروض مستقبلية. هذه أعداد توضيحية وليست معياراً مثالياً لعدد الخطوات أو دراسة حالة.
يضع الفريق أولاً تعريف النجاح: المستخدم يعرف الخدمة والموعد والعنوان، ويراجعها، ثم يرى تأكيداً يعكس حالة الحجز الفعلية. يقترح النموذج عرض الخدمات قبل مطالبة الشخص بإكمال حسابه. تُطلب بيانات التواصل عند الحاجة لتأكيد الحجز، ويُراجع العميل ما يلزم منها. تُفصل تفضيلات العروض بوصفها اختياراً مستقلاً، ولا توضع عقبة أمام المهمة الأساسية دون مبرر معتمد.
لكن النموذج لا يفترض حجز الموعد تلقائياً أثناء التسجيل. تُسجل هذه المسألة كاعتماد تقني: هل يمكن الاحتفاظ بالموعد؟ وكم تستمر صلاحيته وفق نظام الحجز؟ إن تغيّر التوفر، يجب أن تعيد الواجهة عرض البدائل دون إيهام الشخص بأن الحجز تأكد.
تتضمن التجربة شخصاً يعود بعد انقطاع، وشخصاً أدخل رقم تواصل غير صحيح، وشخصاً لا يريد التفضيلات الاختيارية. يُرصد أين احتاج كل مشارك مساعدة، وهل فهم الفرق بين «اختيار موعد» و«تأكيد الحجز». توفر النتيجة فهماً لهذه الرحلة في ظروف الاختبار، ولا تتنبأ بنسبة التحويل لجميع الزوار.
اطلب مخرجاً يصلح للاختبار والبناء
يُفترض أن يسلّم مشروع تصميم تجربة المستخدم تدفقاً يوضح المسار المعتاد والمسارات البديلة، مع سبب طلب كل معلومة. وتضيف خدمة تصميم تطبيقات الجوال حالات الشاشات الصغيرة والمقاطعات والنصوص في اللغتين ضمن النطاق.
ضع معايير قبول مثل:
- يمكن تمييز المطلوب من الاختياري قبل إرسال البيانات.
- الرجوع إلى خطوة سابقة لا يغيّر الاختيار بصمت.
- الخطأ يشرح ما يمكن تصحيحه، مع بقاء المدخلات السليمة وفق السياسة المتفق عليها.
- رفض خيار غير أساسي له مسار موثق لا ينتهي بطريق مسدود.
- التأكيد النهائي يوضح النتيجة الحالية والخطوة التالية، لا مجرد نجاح الضغط على زر.
هذه معايير مقترحة للمنتج، وتحتاج تحققاً على التنفيذ؛ الصورة والنموذج القابل للنقر لا يثبتان تكامل الحساب أو الحجز.
كيف نقيس دون خداع أنفسنا؟
عرّف بداية الرحلة ونهايتها، وافصل المحاولات المتكررة عن المستخدمين حيث تسمح البيانات. تابع إتمام المهمة والأخطاء وطلبات المساعدة، ومعها مؤشرات تمنع تحسناً ظاهرياً مثل زيادة الحجوزات غير الصالحة. إذا تغيّرت حملة الاستحواذ أو قواعد الحجز خلال الفترة، أظهر ذلك في التقرير.
تساعد خدمة تحسين معدل التحويل في اختيار طريقة تقييم تناسب الزيارات وجودة القياس. لا يشترط أن تكون تجربة تقسيم، ولا يحق للمشروع ضمان زيادة قبل معرفة البيانات. قرار الإصدار يمكن أن يستند إلى إزالة عائق موثق، مع استمرار متابعة النتيجة التجارية بدلاً من الادعاء بأنها ثبتت.
أسئلة شائعة
هل نحذف إنشاء الحساب تماماً؟
ليس بالضرورة. افحص الحاجة إلى الحساب وتوقيت طلبه وإمكان التعرف على الطلب لاحقاً. قد يكون المطلوب تأجيله أو توضيح فائدته، لا حذفه.
هل رحلة من شاشة واحدة أفضل؟
ليس دائماً. قد تصبح الشاشة مزدحمة أو تخفي قرارات مترابطة. قارن قدرة المستخدم على فهم المهمة وتصحيحها، لا عدد النقرات وحده.
هل يمكن اختبار نموذج غير مبرمج؟
نعم لفهم التسلسل والصياغة، بشرط توضيح الحدود. لا يمكن منه إثبات إرسال رمز حقيقي أو الاحتفاظ بموعد أو حفظ البيانات بعد الانقطاع.
ماذا لو لم تتوافر بيانات تحليلية؟
ابدأ بفحص الرحلة وملاحظة مستخدمين مناسبين، ثم حدد قياساً بسيطاً موثوقاً. لا تحوّل نقص البيانات إلى مبرر لاختراع أسباب المغادرة.
لصياغة موجز مناسب، جهّز أول مهمة تريد للمستخدم إنجازها وقائمة الطلبات الحالية ومالكي ضرورتها. عندها يصبح النقاش عن إزالة عبء محدد، لا عن إعادة تصميم كل التطبيق.
المصدر
- GOV.UK: استخدام اختبارات قابلية الاستخدام بإشراف باحث، راجع في 26 أكتوبر 2026.
