ملايين المستخدمين… وواجهة لا تنجح في اختبار مستخدم واحد! - عندما تصبح UX/UI قضية جودة وأمان، لا مجرد ألوان وأزرار جميلة
يتناول المقال تحوّل UX/UI من عنصر تجميلي إلى جزء أساسي من جودة البرمجيات وأمانها. فالتطبيق الجيد لا يكفي أن يكون سريعاً ومستقراً، بل يجب أن يحترم المستخدم، ويتوقع أخطاءه، ويحفظ حالته وبياناته، ويقدم تنقلاً واضحاً ورسائل مفهومة وإمكانية للتراجع عن العمليات الحساسة. ومع اعتماد حياتنا على التطبيقات، أصبحت جودة تجربة الإنسان معياراً يجب اختباره بصرامة مثل الكود والأمان.

عندما بدأت البرمجة في منتصف الثمانينيات، لم نكن نتحدث عن UX/UI بالمفهوم المهني الواسع المعروف اليوم.
كنا نهتم بأن يعمل البرنامج.
هل الحساب صحيح؟
هل الملف حُفظ؟
هل البرنامج انهار؟
هل النتيجة التي ظهرت هي النتيجة المطلوبة؟
أما أن نجلس لنناقش شعور المستخدم، ومسار إصبعه، وعدد الخطوات التي يحتاجها لإنجاز مهمة، وما إذا كان الزر يبعث الطمأنينة أو يسبب جلطة صغيرة… فلم يكن هذا تخصصاً مستقلاً كما أصبح اليوم.
ولسنوات طويلة كنت أرى أن المبالغة في UX/UI نوع من الترف، وأن مطور Frontend جيداً يفترض أن يكون قادراً على ترتيب هذه الأمور بنفسه.
ثم تغيّر العالم.
وأعترف أنني غيّرت رأيي معه.
عندما أصبحت حياتنا داخل التطبيق
اليوم لا نستخدم البرامج فقط لكتابة رسالة أو إجراء حساب.
نستخدمها لتحويل الأموال، وحجز الطائرات، وإدارة الحسابات البنكية، وشراء الأدوية، واستلام الوثائق الحكومية، ومتابعة صحتنا، وفتح أبواب السيارات، ودفع الفواتير، والتواصل مع العمل.
أصبحت الواجهة هي الباب الذي يدخل منه الإنسان إلى النظام كله.
وعند هذه النقطة لم تعد UX مجرد تجميل.
إنها جزء من Software Quality.
بل إنها تلامس الأمان أيضاً، لأن التصميم السيئ للعمليات الحساسة، ورسائل التأكيد الغامضة، والصلاحيات التي تظهر بلا تفسير، والاختيارات المضللة، كلها ترفع احتمال أن يتخذ المستخدم قراراً لم يكن يقصده.
Apple نفسها تتحدث اليوم عن منح المستخدم القدرة على التحكم، وعن سهولة التراجع والتأكيد قبل الإجراءات ذات العواقب الخطرة أو التي يصعب عكسها. المصدر
أي أننا لم نعد نتحدث عن «لون الزر».
نحن نتحدث عن سلامة العلاقة بين الإنسان والبرنامج.
حركة إصبع… وعقوبة إعادة تسجيل الدخول
قبل أيام كنت أستخدم تطبيقاً مهماً، وسجلت الدخول بصورة طبيعية.
ثم تحرك إصبعي خطأ من طرف الشاشة ونفذت حركة الرجوع.
وفجأة خرجت من المسار الذي كنت فيه، وأصبحت مضطراً للعودة وإعادة تسجيل الدخول.
توقفت للحظة وسألت نفسي:
كيف يمكن لتطبيق يستخدمه عدد هائل من البشر أن يجعل حركة إصبع عابرة حدثاً يستحق العقوبة؟
المستخدم لم يقدم استقالته من التطبيق.
لم يقل:
«أرجو تدمير جلستي الحالية وإعادتي إلى نقطة البداية، وشكراً لحسن تعاونكم».
لقد حرّك إصبعه!
وهنا تظهر أهمية فهم UX بصورة صحيحة.
ليس الحل أن يقفز التطبيق في وجهك كل ثلاث ثوان:
هل أنت متأكد؟
هل أنت متأكد أنك متأكد؟
هل ترغب في تأكيد أنك ما زلت راغباً في التأكيد؟
هذا أيضاً تصميم سيئ.
الحل أن تكون نتيجة الحركة متوقعة وقابلة للاسترجاع وغير مكلفة قدر الإمكان.
Android نفسه يتحرك في هذا الاتجاه من خلال Predictive Back، الذي يسمح للمستخدم بمعاينة المكان الذي ستقوده إليه حركة الرجوع قبل إكمالها، لتقليل النتائج المفاجئة وجعل التنقل أكثر وضوحاً. المصدر
فإذا كان نظام التشغيل نفسه يحاول أن يخبر المستخدم: «انظر إلى أين ستذهب قبل أن تكمل الحركة»، فمن الطريف أن تجد تطبيقاً يتصرف وكأن Gesture واحدة تصريح رسمي بهدم الجلسة بالكامل.
تطبيقات ذكية جداً… حتى يأتي المستخدم
لدينا اليوم مفارقة مضحكة.
يمكن أن يحتوي التطبيق على Cloud Infrastructure ضخمة، وMicroservices، وKubernetes، وAI، وتحليلات لحظية، وتشفير متقدم…
ثم تصل إلى شاشة التسجيل فتجد خانة OTP لا تسمح بلصق الرقم.
ستة أرقام وصلتك في رسالة.
والتطبيق يقول لك عملياً:
احفظها يا بطل. نحن نؤمن بقدراتك العقلية.
وتجد تطبيقاً آخر يسمح لك بملء نموذج طويل لمدة عشر دقائق، ثم تستقبل مكالمة، تعود إليه، فتجد النموذج فارغاً.
شكراً لك.
لقد منحك التطبيق فرصة مجانية لتطوير مهاراتك في الكتابة من جديد.
وفي تطبيق ثالث تضغط زر «إرسال»، فيظهر:
Something went wrong.
رائع.
ما الذي حدث؟
لا ندري.
ماذا أفعل؟
لا ندري.
هل وصلت العملية؟
ربما.
هل أعيدها؟
جرّب حظك.
هذه ليست مشكلة رسومية.
هذه مشكلة جودة برمجية.
زر الحذف بجوار زر الحفظ… لأن الحياة تحتاج بعض الإثارة
من روائع التصميم أيضاً وضع عملية خطرة بجوار عملية يومية، باللون نفسه تقريباً، ثم الاعتماد على دقة إصبع الإنسان.
أو السؤال:
Are you sure?
ثم إعطاء المستخدم زرين:
Yes | No
متأكد من ماذا بالضبط؟
ولهذا توصي إرشادات Apple بأن تكون رسائل الإجراءات المهمة واضحة، وأن تعبّر الأزرار عن الفعل نفسه بدلاً من إجابات غامضة. ففي عملية إلغاء اشتراك مثلاً، «إلغاء الاشتراك» و«الاحتفاظ بالاشتراك» أوضح بكثير من «نعم» و«لا». المصدر
الجودة هنا ليست أن النافذة جميلة.
الجودة أن المستخدم يستطيع اتخاذ القرار الصحيح من دون أن يحل لغزاً لغوياً أولاً.
والأسوأ: مخالفة نظام التشغيل نفسه
هناك تطبيقات تبدو وكأن مطوريها قرروا أن Android وiOS مجرد اقتراحات.
النظام يضيف نمط تنقل جديداً؟
لا يهم.
تتغير أحجام الشاشات؟
ليتأقلم المستخدم.
هاتف قابل للطي؟
ليفتحه على مسؤوليته.
تكبير الخط بسبب ضعف البصر؟
لماذا يفسد المستخدم تصميمنا الجميل؟
الوضع الداكن؟
ليس ضمن ميزانية القرن الحالي.
Google أصبحت صريحة جداً في هذا الأمر. إرشادات Android الحالية تعتبر اتباع أنماط التفاعل القياسية جزءاً من الحد الأساسي لجودة التطبيق، وتطلب التكيف مع أحجام الشاشات والأجهزة القابلة للطي والنوافذ المختلفة. المصدر
وهذا منطقي.
المستخدم تعلم لغة نظام التشغيل.
لا تجبره داخل تطبيقك على تعلم لغة جديدة لأن المصمم أراد أن «يبدع».
الإبداع الذي يحتاج معه المستخدم إلى دورة تدريبية ليس إبداعاً دائماً.
أحياناً يكون مجرد مشكلة.
UX ليس رساماً يجلس بعد انتهاء البرمجة
واحدة من أكبر الأخطاء التنظيمية هي هذا السيناريو:
ينتهي الفريق من التطبيق.
قاعدة البيانات جاهزة.
APIs جاهزة.
الوظائف جاهزة.
ثم يقول المدير:
الآن أحضروا شخص UX ليجمله قليلاً.
كأن UX هو الشخص الذي يأتي بعد انتهاء بناء المنزل ليختار لون الستائر.
لا.
UX الحقيقي يبدأ قبل ذلك بكثير.
كيف يصل المستخدم إلى المهمة؟
ماذا يحدث إذا أخطأ؟
ماذا يحدث إذا انقطع الإنترنت؟
ماذا يحدث إذا أغلق التطبيق؟
ماذا لو وصلته مكالمة؟
ماذا لو عاد للخلف؟
ماذا لو كان ضعيف البصر؟
ماذا لو ضغط الزر مرتين؟
ماذا لو تأخر الخادم خمس ثوانٍ؟
ماذا لو فشل الدفع بعد خصم المبلغ؟
ماذا لو لم يفهم رسالة الخطأ؟
هذه أسئلة هندسة برمجيات بقدر ما هي أسئلة UX.
وهل ستجبر المتاجر المطورين على الجودة؟
الخبر الجيد أن الاتجاه بدأ بالفعل، وإن لم يصل بعد إلى المستوى الذي أتمناه.
Google Play لا تعتبر الجودة اليوم مجرد غياب Crash. لديها تصور يشمل القيمة التي يقدمها التطبيق، وتجربة المستخدم، والجودة التقنية، والخصوصية والأمان، وتقول صراحة إن التطبيق الجيد يجب أن يكون سهل الاستخدام. المصدر
والأكثر إثارة للاهتمام أن Google تستخدم بالفعل إشارات مثل فقدان المستخدمين، والنشاط، وقابلية الاستخدام، والاستقرار والأداء عند تقييم جودة التطبيقات وبعض فرص ظهورها داخل Play. المصدر
أي أن الفكرة بدأت تنتقل من:
«ننصحك بأن تصمم تطبيقاً جيداً».
إلى:
«جودة تجربتك قد تؤثر في مكانك داخل المنصة».
وهذه بداية جيدة.
لكنني أتمنى أن نذهب أبعد.
نحتاج إلى ثورة Quality Experience
أتمنى أن يأتي يوم لا يكفي فيه أن يجتاز التطبيق اختبارات Security وCrash وAPI Compatibility فقط.
أريد مجموعة صارمة من اختبارات Human Interaction Quality أيضاً.
- هل يحتفظ التطبيق بحالة المستخدم بطريقة منطقية؟
- هل النتائج الخطرة قابلة للتراجع أو التأكيد؟
- هل يدعم أنماط التنقل القياسية؟
- هل رسائل الأخطاء مفهومة؟
- هل يستطيع الإنسان معرفة ما حدث بعد فشل العملية؟
- هل يحترم Accessibility؟
- هل يعمل بصورة سليمة مع Gesture Navigation؟
- هل يتعامل جيداً مع تغيير حجم الشاشة؟
- هل يمنع فقدان البيانات بسبب خطأ بسيط؟
- وهل جُرّب فعلاً على بشر حقيقيين، وليس فقط على المطور الذي يعرف مكان كل زر لأنه هو الذي وضعه؟
ليس من المنطقي أن نرفض تطبيقاً لأن أيقونته لا تطابق بعض شروط المتجر، ثم نتسامح مع تجربة استخدام تجعل مليون إنسان يسبّ التطبيق كل صباح.
الاختبار الحقيقي: أعطه لإنسان لا يعرف عنه شيئاً
هناك اختبار أحب أن أتخيله.
بعد أن ينتهي الفريق من التطبيق، لا تعطوه للمطور.
ولا لمدير المشروع.
ولا لمصمم الواجهة.
أحضِر شخصاً لم يره في حياته وقل له:
أنجز هذه المهمة.
ثم اصمتوا.
لا تقولوا له:
«لا، اضغط هناك».
«المقصود بهذه الأيقونة هو…»
«هذه الحركة معروفة عندنا».
إذا احتاج المستخدم إلى مهندس التطبيق واقفاً خلفه ليشرح له التطبيق، فقد تم بالفعل اكتشاف Bug.
اسمه:
التصميم.
أخيراً: الكود الذي لا يحترم الإنسان ليس عالي الجودة
استغرقت مني البرمجة عقوداً حتى أصل إلى هذا الاقتناع.
كنت أرى جودة البرنامج أساساً في داخله:
الخوارزمية، والبنية، والأداء، والذاكرة، والاستقرار، والأمان.
واليوم أرى أن هناك طبقة لا تقل أهمية:
اللحظة التي يلتقي فيها هذا النظام كله بإنسان.
يمكن أن يكون خلف الشاشة واحد من أفضل الأنظمة البرمجية التي بُنيت على الإطلاق.
لكن إذا احتاج المستخدم إلى خمس دقائق ليعرف كيف يعود إلى الصفحة السابقة، أو فقد عشر دقائق من العمل بسبب Swipe، أو خاف من الضغط على زر لأنه لا يعرف ماذا سيفعل…
فإن جزءاً مهماً من جودة هذا النظام قد فشل.
لقد أصبح UX/UI تخصصاً حقيقياً لأن البرمجيات لم تعد تعيش داخل الحواسيب.
نحن الذين أصبحنا نعيش جزءاً كبيراً من حياتنا داخل البرمجيات.
ولهذا ربما حان الوقت لأن نتوقف عن اعتبار سهولة الاستخدام «ميزة جميلة».
يجب أن تصبح معيار جودة.
وفي بعض التطبيقات الحساسة، ربما يجب أن تصبح شرطاً للنشر أصلاً.
فالمستخدم لم يشتر هاتفاً حديثاً بمعالج خارق وشاشة مذهلة واتصال سريع…
كي يهزمه زر الرجوع.
مقالات ذات صلة
حين يتحول حب لغة البرمجة إلى تعصب
من الطبيعي أن يحب المبرمج لغةً رافقته وصنعت جزءًا من خبرته، لكن هذا الحب لا يبرر احتقار اللغات الأخرى. فكل لغة، من C وC++ إلى Rust وAda وPython وغيرها، تملك نقاط قوة وحدودًا وتناسب مشروعات مختلفة. المبرمج الناضج يبدأ من المشكلة ثم يختار الأداة الأنسب، أما المتعصب فيفرض أداته على كل شيء. فالبرمجة أوسع من لغة واحدة، والإنصاف هو سيد الأحكام، واحترام اختيارات الآخرين دليل خبرة وثقة لا ضعف ولا انتقاص.
ما بعد الصفر والواحد: هل يمكن أن تصبح الحوسبة ثلاثية أو رباعية؟
الحوسبة لا تقتصر نظريًا على الصفر والواحد؛ فقد بُني حاسوب Setun السوفييتي بمنطق ثلاثي، وتستخدم ذاكرات SSD الحديثة عدة مستويات كهربائية، كما تعتمد اتصالات PAM4 أربع حالات للإشارة. لكن زيادة الحالات تقلل هامش مقاومة الضوضاء، وتزيد تعقيد البوابات واستهلاك الطاقة. لذلك تبقى الثنائية الأنسب للمعالجات العامة، بينما قد يظهر المنطق متعدد القيم مستقبلًا في الذاكرة والذكاء الاصطناعي والمسرعات المتخصصة.
هل يعيد الذكاء الاصطناعي التوازن إلى سوق البرمجة والتصميم؟
يناقش المقال تجربة شخصية في استخدام الذكاء الاصطناعي لبناء مواقع إلكترونية وتصميمات بتكلفة محدودة ونتائج فاقت التوقعات، بعد مواجهة أسعار مرتفعة ومبالغات في تقدير الأعمال. ويؤكد أن الذكاء الاصطناعي لا يلغي المبرمج والمصمم، بل يعيد ضبط السوق، ويمنح الأفضلية لمن يجمع بين الخبرة وحسن التوجيه والمراجعة، ويقدم قيمة حقيقية بسعر عادل دون تهويل أو هدر، مع بقاء الحاجة إلى المتخصصين في المشاريع المعقدة والحساسة.
