ابدأ بتدقيق تجربة المستخدم عندما تكون الصعوبة موجودة لكن سببها أو الإجراء التالي غير محسوم. وابدأ إعادة التصميم عندما تدعم الأدلة تغيير المسار أو البنية أو التفاعل. وإذا أمكن تكرار خلل محدّد وكان السلوك المطلوب واضحًا، فقد يكون إصلاحه هو المهمة الأولى المناسبة.
هذه قرارات تخص النطاق. قد تشمل إعادة التصميم بحثًا، وقد يقود التدقيق إلى نموذج تفاعلي. حدّد ما يحتاج الفريق إلى تعلّمه أو تغييره قبل مقارنة عروض تحمل هذه المسميات.
صف المشكلة من خلال مهمة وصعوبة ملحوظة. عبارة «لا يستطيع العميل إكمال نموذج الاستفسار بعد ظهور خطأ» تمنح المراجع شيئًا يفحصه. أما «نريد موقعًا أكثر حداثة» فتصف تفضيلًا، لكنها لا تحدّد أين يتعثر المستخدم أو ما العمل الذي يساعده.
سجّل مصدر الملاحظة. محادثة الدعم والخلل التقني القابل للتكرار والتغيّر في تقرير التحليلات أنواع مختلفة من الأدلة. احتفظ بالمصدر والتاريخ واللغة والجهاز مع كل ملاحظة.
إذا بدأ القلق من لوحة مؤشرات، فتحقق من عمل القياس نفسه. قد يبدو غياب حدث التأكيد كأنه انخفاض في الاستفسارات المكتملة. وإذا كانت المشكلة أن الطلبات المرسلة لا تتلقى ردًا، فافحص انتقالها إلى الفريق المسؤول إلى جانب النموذج. تغيير شكل الشاشة لن يعالج طلبًا لا يصل إلى صاحبه.
الجدول التالي أداة قرار تقترحها تكنوستاك. لا يحدّد ميزانية أو مدة ثابتة لكل خيار.
| الحالة | الخطوة الأولى المناسبة | ما المطلوب قبل توسيع النطاق؟ |
|---|---|---|
| خلل محدّد يمكن تكراره وسلوك مطلوب متفق عليه | أصلحه وتحقق من المهمة كاملةً | إثبات عمل التصحيح وسلامة الحالات المجاورة |
| يتعثر الناس في مسار ويختلف الفريق حول السبب | دقّق المسار وحدّد فجوات البحث | ملاحظات مرتبطة بأدلة وقرار تالٍ واضح |
| تغيّرت أدوار المستخدمين أو طريقة العمل الأساسية | ارسم المسار الجديد واختبر نموذج إعادة التصميم | دليل على أن الخطوات المقترحة تخدم المهمة الجديدة |
| تغيّرت الهوية البصرية بينما يعمل المسار | حدّد نطاق التحديث البصري والمحتوى | مراجعة المقروئية والحالات والاتساق بعد التطبيق |
| يشير تقرير إلى مشكلة لكن بياناته غير موثوقة | راجع القياس قبل الاستنتاج التصميمي | تعريف وسجل موثوقان للحدث الذي تراجعه |
قد يجمع المنتج أكثر من حالة. تستطيع إصلاح خطأ واضح بينما تبحث مسارًا آخر. اربط كل عمل بأدلته ومسؤوله، وحدّد مدى التغيير وفق ما وجدتموه.
اتفق على المسار والمستخدمين والأجهزة واللغات والحالات التي ستُراجع. قد تفيد مراجعة محدّدة أكثر من قائمة طويلة بملاحظات سطحية على منتج كامل. أدرج نقطة الدخول وحالة الاكتمال المقصودة ومسارات تصحيح الخطأ بينهما.
قد تستخدم مراجعة الخبير مبادئ قابلية الاستخدام لتحديد المشكلات المحتملة. تشرح NN/g أن التقييم الاستدلالي مراجعة وفق إرشادات، وأنه يكمّل البحث مع المستخدمين. وتؤكد أهمية السياق؛ فمخالفة إرشاد لا تعني تلقائيًا أن الاختيار التصميمي خاطئ. طريقة التقييم الاستدلالي لدى NN/g
اطلب من المراجع التمييز بين ما أعاد إنتاجه، وما أظهره المستخدمون، وما بقي فرضية. ينبغي أن تُظهر التوصية الشاشة أو الحالة المعنية، وتشرح الصعوبة، وتقترح إجراءً يمكن تقييمه. عبارة «تحسين تجربة المستخدم» أوسع من أن تقدّر عملها أو تقبله.
تحتاج أعمال الإتاحة نطاقًا واضحًا أيضًا. تغطي فحوص W3C الأولية مشكلات مختارة ولا تثبت إجراء تقييم شامل. المراجعة السريعة والفحص الآلي والتقييم وفق المعايير مخرجات مختلفة. توضيح W3C للفحوص الأولية للإتاحة
استخدم سجلًا لكل ملاحظة. يصف المثال التالي نموذج استفسار افتراضيًا، وليس نتيجة من مشروع عميل لتكنوستاك.
| حقل السجل | مثال افتراضي |
|---|---|
| المهمة والحالة | إرسال استفسار بعد تصحيح حقل البريد الإلكتروني |
| الملاحظة | يبقى زر الإرسال معطّلًا بعد تصحيح الحقل |
| الدليل | خطوات إعادة الإنتاج وتسجيل من بيئة الاختبار المتفق عليها |
| الأثر على المهمة | لا يستطيع المراجع إكمال الاستفسار عبر هذا المسار |
| التفسير | قد لا تتحدّث حالة صلاحية الحقل بعد التصحيح؛ يحتاج الأمر فحص المطوّر |
| الإجراء المقترح | تكرار تغيّر الحالة وتصحيحه وإعادة اختبار الإرسال كاملًا |
| القبول | تُرسل البيانات الصحيحة المتفق عليها ويطابق التأكيد الطلب المستلم |
| المسؤول والمتابعة | تعيين مسؤول التنفيذ والشخص الذي يتحقق من النتيجة |
يساعد السجل في تحقيق محدّد. لكنه لا يثبت عدد العملاء الذين واجهوا المشكلة أو مقدار الإيراد المتأثر بها؛ فهذه الاستنتاجات تحتاج أدلة مستقلة.
رتّب الملاحظات حسب أثرها على المهمة وقوة دليلها ومتطلبات التغيير المقترح. سجّل ما إذا كان الشخص يستطيع المتابعة أو يتوقف تمامًا. استخدم تعريفًا مشتركًا لشدة المشكلة، حتى يفهم الفريق كلمة «حرجة» بالمعنى نفسه.
تفيد إعادة التصميم عندما يتطلب تحسين التجربة تغيير تنظيم المهمة. فقد يصبح للمنتج مستخدم يعتمد الطلب إلى جانب الشخص الذي يرسله. وإذا احتاج الدوران إلى معلومات وصلاحيات مختلفة، فقد يمتد العمل إلى ما هو أبعد من تسمية أو لون.
اكتب المسار الجديد قبل تنقيح الشاشات. أدرج حالات الفراغ والتحميل والخطأ والانقطاع والاكتمال حيث تنطبق. حدّد السلوك الذي يستطيع النموذج إظهاره وما يحتاج إلى شيفرة إنتاج أو تكامل فعلي.
اختبر المسار المقترح حول قرار محدّد. تتضمن خطة اختبار قابلية الاستخدام ورقة للمهام والملاحظات. وإذا كان المنتج ثنائي اللغة، فاستخدم قائمة مراجعة الواجهة العربية للنص المختلط والنماذج والتسليم. لا تمثّل نتيجة النموذج الإنجليزي دليلًا على مهمة عربية لم تُختبر.
أدخل مراجعة المطوّر ضمن عملية التصميم. قد يفترض النموذج معلومات لا يستطيع التطبيق جلبها أو إجراءً لا يسمح به نظام الصلاحيات الحالي. اكتشاف هذا الاعتماد قبل الموافقة يوضّح نطاق البناء اللاحق.
اطلب من كل جهة الإجابة عن الموجز نفسه. اذكر المهمة والأدلة المتاحة والقرار الذي تريد الوصول إليه. شارك ملفات التصميم أو ترتيبات الوصول المرتبطة بالمهمة؛ لا تحتاج محادثة تحديد النطاق عادةً إلى وصول غير مقيّد لسجلات العملاء.
في التدقيق، اسأل عن تغطية المراجعة وصيغة الأدلة وطريقة ترتيب الأولويات وما يقع خارج النطاق. وفي إعادة التصميم، أضف المسارات وحالات الشاشات وسلوك النموذج واللغات وصيغة التسليم. وإذا شمل العمل بحثًا، فاتفق على مسؤول استقطاب المشاركين ومسؤول اعتماد التغييرات.
ينبغي أن توضّح المخرجات الإجراء التالي. حدّد لكل ملاحظة أو مسار مقترح صاحب القرار ومتطلبات التنفيذ وطريقة التحقق من النتيجة. وهنا يفصل الفريق بين أعمال التصميم والتطوير وتعديلات التحليلات والتحسين المستمر.
إذا غيّرت إعادة التصميم روابط الموقع أو محتواه المنشور، فأدرج قائمة إعادة تصميم الموقع وSEO في خطة التنفيذ. لهذه الأعمال معايير قبول إضافية إلى جانب اعتماد الواجهة.
تفصل نطاقات تصميم الواجهات وتجربة المستخدم بين مراجعة المسار وتصميم النموذج وأعمال نظام التصميم. أرسل المنتج والمهمة التي تسبب صعوبة والأدلة المتاحة. نستطيع الاتفاق على أول قرار مفيد والنطاق اللازم للوصول إليه.
