لماذا تحتاج تجربة المستخدم إلى صيانة بعد الإطلاق؟

لأن احتياجات المستخدمين والتقنية والقواعد تتغيّر. ويحذّر دليل GOV.UK من أن الخدمة التي لا تتحسّن باستمرار ستتوقّف مع الوقت عن تلبية احتياجات مستخدميها.

ما الجديد في WCAG 2.2؟

صارت WCAG 2.2 توصية رسمية من W3C في ٥ أكتوبر ٢٠٢٣، وأضافت تسعة معايير نجاح جديدة، منها الحدّ الأدنى لحجم الهدف، وحذفت المعيار 4.1.1 (Parsing).

ما هو دَين تجربة المستخدم؟

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

العودة إلى المدونة

لماذا هكذا؟١ نوفمبر ٢٠٢٦٥ دقائق قراءة

تجربة المستخدم لا تنتهي عند الإطلاق

لماذا تحتاج تجربة المستخدم إلى صيانة مستمرة بعد الإطلاق، وإيقاع بسيط يحافظ على منتجك مع تغيّر الناس والمنصّات والمعايير.

$غلاف «تجربة المستخدم\nلا تنتهي عند الإطلاق»: هاتف داخل حلقة من سهمين أصفر وبرتقالي يدوران حوله.$

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

احتياجات الناس تتغيّر

يقولها دليل الخدمات الحكومية البريطاني (GOV.UK Service Manual) بوضوح في معيار الخدمة: التحسين المستمر يتيح للفريق أن يستجيب لتغيّر احتياجات المستخدمين والتقنية والسياسات الحكومية. ويحذّر من أن الفريق الذي يكتفي بإصلاح الأعطال سيعالج «الأعراض لا المشكلات الأساسية»، وأن الخدمة مع الوقت «ستتوقّف عن تلبية احتياجات المستخدمين».

والأسباب عادية جدًّا. العميل الذي بدأ مبتدئًا يصبح مستخدمًا دائمًا ويريد طرقًا أقصر. وتصل فئات جديدة من العملاء بتوقّعات مختلفة. ولا يظهر شيء من هذا رسالةَ خطأ في سجلّات النظام.

المنصّات والمعايير تتغيّر

الأجهزة وأنظمة التشغيل التي يعمل عليها منتجك تتغيّر كل عام، وتتغيّر قواعدها معها.

Apple. في ٩ يونيو ٢٠٢٥ أعلنت Apple تصميمًا جديدًا لأنظمتها يقوم على مادّة سمّتها Liquid Glass، وهي طبقة شفّافة تعكس ما حولها وتكسره كالزجاج، على iOS 26 وiPadOS 26 وmacOS Tahoe 26 وwatchOS 26 وtvOS 26. ووفّرت للمطوّرين واجهات برمجية (APIs) محدَّثة في SwiftUI وUIKit وAppKit لتبنّي التصميم الجديد.
Android. على Android 15، تُعرض التطبيقات التي تستهدف Android 15 (المستوى ٣٥ من واجهة البرمجة) من حافة الشاشة إلى حافتها (edge-to-edge) افتراضيًّا، أي أن النافذة تملأ الشاشة كلها وترسم خلف أشرطة النظام مثل شريط الحالة وشريط التنقّل. وتحذّر وثائق Google من أن التطبيق غير المستعدّ قد تُحجب أجزاء منه. كان Android 15 يسمح بإلغاء هذا السلوك، أمّا التطبيقات التي تستهدف Android 16 (المستوى ٣٦) فلم يعد ذلك متاحًا لها. ومنذ ٣١ أغسطس ٢٠٢٦، يشترط متجر Google Play أن تستهدف تطبيقات الهواتف والأجهزة اللوحية الجديدة وتحديثاتها Android 16. أي أن أيّ تحديث تنشره اليوم يلزمك بالتعامل مع هذا التغيير في التخطيط.
إمكانية الوصول. معايير WCAG، أي إرشادات إمكانية الوصول إلى محتوى الويب، هي معيار W3C لجعل المحتوى الرقمي في متناول ذوي الإعاقة. صارت النسخة 2.2 توصية رسمية من W3C في ٥ أكتوبر ٢٠٢٣، وأضافت تسعة معايير نجاح جديدة. أربعة منها في المستوى AA، وهو الأوسط بين مستوياتها الثلاثة: ألّا يُحجب العنصر الذي عليه التركيز، وبدائل لحركات السحب، والحدّ الأدنى لحجم الهدف، وتسجيل الدخول دون اختبارات إدراكية صعبة. وحذفت معيارًا قديمًا هو 4.1.1 (Parsing) لأنه لم يعد ضروريًّا.
التشريعات. دخل القانون الأوروبي لإمكانية الوصول (European Accessibility Act) حيّز التطبيق في الاتحاد الأوروبي في ٢٨ يونيو ٢٠٢٥. ويشمل منتجات وخدمات مثل الهواتف الذكية والحواسيب والكتب الإلكترونية والخدمات المصرفية والاتصالات الإلكترونية. وبالنسبة إلى الشركات الخليجية والعربية التي تخدم عملاء في الاتحاد الأوروبي، صارت إمكانية الوصول في حالات كثيرة شرطًا قانونيًّا، لا مجرّد ممارسة جيّدة.

المنتج الذي صُمّم جيّدًا عام ٢٠٢٢ قد يقصر في هذه الجوانب الأربعة كلها دون أن يتغيّر سطر واحد من الكود.

الدَّين يتراكم بهدوء

تصف Nielsen Norman Group، وهي شركة أبحاث واستشارات في تجربة المستخدم، ما تسمّيه دَين تجربة المستخدم (UX debt) بأنه مشكلات في التجربة تتراكم وتضرّ بالمستخدمين. يتكوّن هذا الدَّين حين يختار الفريق مرّة بعد مرّة الطريق المختصر بدل الحلّ الأفضل، غالبًا تحت ضغط المواعيد. وكالدَّين التقني، تزداد كلفته كلما طال تأجيله، لأن الناس يعتادون التصميم المعيب ويفقدون ثقتهم بالمنتج.

ودَين التصميم هو الجزء الظاهر منه: ثلاثة أشكال للأزرار حيث يكفي شكل واحد، ونموذج رُقِّع مرّتين، وشاشة لم تعد تطابق نظام التصميم (design system). وتوصي آنا كيلي من Nielsen Norman Group بأن تحدّد شدّة المشكلة وتكرارها وموقعها في رحلة المستخدم ترتيب أولويتها، وبأن يراجعها فريق المنتج كله بانتظام، بمن فيه المطوّرون.

قِس عبر الزمن

القياس الواحد لا يخبرك بالكثير. تعرّف كيت موران من Nielsen Norman Group المقارنة المرجعية (benchmarking) بأنها تقييم أداء المنتج بمقاييس تُقارَن «بمعيار ذي معنى»، كنسختك السابقة أو منافس لك، وتنبّه إلى أن «الرقم الواحد بلا معنى» وحده. والأساليب الأنجح عادةً هي التحليلات (analytics) والاستبيانات واختبارات قابلية الاستخدام الكمّية. قد تناسب الدراسة الكمّية الكبيرة إيقاعًا سنويًّا، أمّا التحليلات فيمكن مراجعتها بعد كل إصدار كبير.

ويقدّم دليل GOV.UK نصيحة مشابهة لخدماته: أن يُقاس الأداء باستمرار قدر الإمكان بدل الاكتفاء بلقطات متفرّقة، وأن تتطوّر المقاييس نفسها مع تغيّر الخدمة.

الأرقام تُريك أين يتعثّر الناس، واختبار قابلية الاستخدام، حين تشاهد أشخاصًا حقيقيين يؤدّون مهام حقيقية، يُريك لماذا.

إيقاع بسيط للصيانة

لا تحتاج إلى فريق كبير كي يبقى منتجك سليمًا. تحتاج إلى تقويم.

كل أسبوعين: جولة قصيرة من البحث أو اختبار قابلية الاستخدام. يهدف دليل GOV.UK إلى جولة واحدة على الأقل كل أسبوعين، وتقترح Nielsen Norman Group اختبار الرحلات الأساسية بمهام واقعية مرّة في الشهر على الأقل.
كل شهر: راجع اتجاهات التحليلات ورسائل الدعم وقائمة دَين التجربة مع فريقي المنتج والهندسة، وأصلح أهمّ البنود قبل أن تضيف جديدًا.
مع كل إصدار جديد لنظام التشغيل: اقرأ ما تغيّر في إرشادات Apple وGoogle وفي متطلّبات المنصّات، واختبر رحلاتك الأساسية على النسخ الجديدة.
كل عام: مراجعة لإمكانية الوصول وفق أحدث نسخة من WCAG، ودراسة مقارنة مرجعية تقارن نتائجها بنتائج العام السابق.

ما تأخذه معك

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