تخيل معايا دلوقتي إن فريق منتج خلص تصميم تحديث جديد، وقبل ما يبدأ التطوير قرر يعمل UX Audit سريع.
الفريق فتح ملف التصميم، وحط مبادئ Nielsen العشرة في جدول، وبدأ يراجع:
Visibility of System Status موجودة.
Consistency and Standards موجودة.
Error Prevention موجودة.
User Control and Freedom موجودة.
بعد وقت قصير، معظم القواعد بقى قدامها علامة صح، والتقرير شكله منظم ومكتمل.
لكن خليني أسألك سؤال:
هل الفريق فعلًا حلل التجربة؟ ولا مجرد اتأكد إن فيه عنصر مرتبط بكل قاعدة؟
لأن وجود Loader لا يعني بالضرورة إن حالة النظام واضحة.
ووجود رسالة خطأ لا يعني إنها بتساعد المستخدم يفهم المشكلة ويحلها.
واستخدام نفس شكل الزر في كل الشاشات لا يعني إن سلوكه متسق.
هنا تحديدًا بيظهر الفرق بين استخدام مبادئ Nielsen كأداة للتحليل، وتحويلها إلى Checklist.
مبادئ Nielsen مش قائمة نجاح وفشل
تعالى ناخد مثال بسيط.
الفريق لقى Loader بيظهر بعد ما المستخدم يضغط على زر تنفيذ العملية، فحط علامة صح أمام:
Visibility of System Status.
لكن هل ظهور الـLoader كفاية؟
مش بالضرورة.
لازم نسأل:
هل ظهر مباشرة بعد الإجراء؟
هل المستخدم فاهم إن العملية لسه مستمرة؟
هل يعرف يعمل إيه لو الانتظار طال؟
هل فيه فرق واضح بين التحميل وفشل العملية؟
هل هيوصله تأكيد مفهوم بعد اكتمالها؟
ممكن العنصر يكون موجود، لكن القاعدة نفسها مش متحققة بالصورة المطلوبة.
مبادئ Nielsen هي مبادئ عامة تساعد المقيّم يكتشف مشكلات محتملة في التفاعل. لكنها مش متطلبات تفصيلية نجاوب عنها بـ«موجود» أو «مش موجود».
طيب، ما هي Heuristic Evaluation؟
ببساطة، هي طريقة فحص يراجع فيها عدد من المقيّمين الواجهة، ويقارنوها بمجموعة من مبادئ Usability المعروفة.
لكن التقييم مش المفروض ينتهي بجملة زي:
عندنا مشكلة في القاعدة الرابعة.
|
الجملة دي مش هتساعد فريق المنتج يفهم المشكلة أو يتعامل معاها.
خليني أحكيلك موقف ممكن يتكرر داخل أي منتج:
في شاشة، زر «إلغاء» بيرجع المستخدم للخطوة السابقة ويحافظ على البيانات.
وفي شاشة تانية، الزر نفسه بيمسح البيانات اللي المستخدم كتبها من غير تحذير.
لو التقرير كتب:
مشكلة في Consistency and Standards.
|
فالمعلومة صحيحة، لكنها ناقصة.
الصياغة الأوضح تكون:
زر «إلغاء» يعيد المستخدم إلى الشاشة السابقة في جزء من المنتج، لكنه يحذف البيانات المدخلة من غير تحذير في جزء آخر. اختلاف السلوك قد يجعل نتيجة الضغط على الزر غير متوقعة.
|
لاحظ الفرق؟
المشكلة بقى ليها:
إيه اللي لازم يتوثق؟
لما تكتشف مشكلة أثناء Heuristic Evaluation، حاول تجاوب عن الأسئلة دي:
المشكلة ظهرت فين؟
المستخدم كان بيحاول يعمل إيه؟
الواجهة بتتصرف إزاي حاليًا؟
أنهي مبدأ مرتبط بالمشكلة؟
ليه السلوك ده ممكن يسبب صعوبة؟
إيه أثره المحتمل على إكمال المهمة؟
إيه الدليل الموجود؟
إيه التوصية الأولية؟
كده التقييم يتحول من مجموعة ملاحظات عامة إلى تقرير يساعد في اتخاذ القرار.
بس خلي بالك: المقيّم مش هو المستخدم
تخيل إن المقيّم شاف زر باسم «متابعة الطلب»، لكنه حس إن التسمية مش بتوضح هل المستخدم هيراجع الطلب ولا هينفذه.
المقيّم يقدر يكتب:
التسمية قد لا توضح نتيجة الإجراء بصورة كافية.
|
لكن هل يقدر يقول:
معظم المستخدمين مش هيفهموا الزر؟
|
لا، إلا لو فيه بحث فعلي يدعم الكلام ده.
وهنا الفرق المهم:
الطريقتان بيدعموا بعض، لكن واحدة منهم مش بديل للتانية.
وليه نحتاج أكتر من مقيّم؟
تخيل إن شخصًا واحدًا فقط هو اللي راجع المنتج.
طبيعي خبرته وتوقعاته تأثر على الحاجات اللي هيلتقطها، وممكن مشكلات واضحة لشخص آخر تعدي من غير ما يلاحظها.
علشان كده، الأفضل إن المقيّمين يراجعوا الواجهة بشكل مستقل الأول، وبعد كده يجمعوا النتائج علشان:
الهدف مش إن التقرير يكون مليان ملاحظات.
الهدف إن التقييم ما يعتمدش على منظور شخص واحد فقط.
هل رقم القاعدة بيحدد خطورة المشكلة؟
خلينا نتخيل مشكلتين:
الأولى: اختلاف بسيط في شكل عنصر بين شاشتين.
الثانية: رسالة غامضة بعد تحويل مالي، والمستخدم مش عارف العملية نجحت ولا فشلت.
المشكلة الأولى ممكن تكون مرتبطة بـConsistency and Standards، والثانية بـVisibility of System Status.
لكن رقم القاعدة مش هو اللي بيحدد أيهما أخطر.
تحديد الأولوية يعتمد على:
نرجع للفريق اللي بدأنا معاه
بعد ما اكتشف الفريق إن علامات الصح مش كفاية، رجع للتقرير من جديد.
المرة دي، كل مشكلة اتوثقت من خلال:
موقعها داخل التجربة.
المهمة المرتبطة بها.
المبدأ المناسب.
وصف السلوك الحالي.
التأثير المحتمل.
الدليل المتاح.
التوصية الأولية.
التقرير بقى أقصر، لكنه بقى أكثر فائدة.
وده يخلينا نوصل لنقطة مهمة:
مبادئ Nielsen مش إجابات جاهزة، لكنها عدسة بتساعدنا نسأل الأسئلة الصحيحة ونكتشف المشكلات المحتملة.
|
استخدم Heuristic Evaluation علشان تعرف فين محتاج تحسين أو تحقيق إضافي، مش علشان تثبت إنك عرفت كل حاجة عن المستخدم.
الرحلة لسه مكملة
النشرة دي جزء من سلسلة مستمرة عن UX وتصميم المنتجات الرقمية.
شاركنا الموقف
هل قابلت قبل كده UX Audit بيتعامل مع المبادئ كـPass أو Fail؟
رد على الرسالة واحكي الموقف أو ابعت السؤال اللي حابب تشوفه في عدد قادم.
التعليقات