قد يتخذ الطفل قرارًا داخل تطبيق يبدو اختياريًا بينما الواجهة صممت كي تدفعه إليه: زر قبول ضخم مقابل رفض خافت، عداد يقول إن العرض ينتهي خلال دقائق، مكافأة تضيع إن أغلق التطبيق، أو خطوات كثيرة جدًا لإلغاء الاشتراك مقارنة بخطوة واحدة للشراء. تسمى هذه الممارسات أحيانًا Dark Patterns أو الأنماط التجارية المظلمة عندما تستخدم بنية الواجهة أو اللغة أو التوقيت للتوجيه أو الخداع أو الضغط بطريقة تضع مصلحة الخدمة فوق قرار المستخدم. بالنسبة للأطفال يزداد الخطر لأن القدرة على فهم النية التجارية والاحتمالات والتكلفة المستقبلية ما تزال تتطور، ولأن التصميم قد يستغل الحاجة للقبول الاجتماعي أو المكافأة الفورية. الهدف ليس منع كل nudge؛ يمكن للتصميم أن يشجع الخصوصية والسلامة. الفارق هو: هل تساعد الواجهة الطفل على قرار مفهوم وقابل للرفض، أم تجعل المسار المرغوب للشركة أسهل أو أكثر إغراءً أو أقل وضوحًا على نحو يضعف الاختيار؟

ما الأنماط المظلمة؟

تعرف OECD الأنماط التجارية المظلمة بأنها ممارسات في الواجهات الرقمية تقوّض اتخاذ القرار من خلال طريقة عرض الخيارات، وقد توجه أو تخدع أو تضغط المستخدم لاتخاذ قرار ضد مصلحته. لا يشترط أن يكون الزر كاذبًا حرفيًا؛ قد يكون التلاعب في الترتيب واللون والتكرار والتوقيت أو في جعل الرفض مكلفًا بالوقت والجهد. عند تقييم خدمة يستخدمها الأطفال، افحص الرحلة كاملة لا شاشة واحدة: التسجيل، الخصوصية، الشراء، الإشعارات، إلغاء الاشتراك، مشاركة الموقع، حذف الحساب، والعودة بعد الانقطاع.

الـNudge ليس شريرًا بطبيعته

يمكن للواجهة أن تدفع الطفل نحو حماية أفضل، مثل اقتراح إبقاء الحساب خاصًا أو تذكيره قبل مشاركة موقعه أو إعطائه استراحة بعد جلسة طويلة. المشكلة تظهر عندما تخدم الدفعة مصلحة تجارية على حساب فهم الطفل أو خصوصيته أو ماله أو رفاهه. لذلك لا يكفي سؤال هل يوجد nudge، بل: نحو ماذا؟ لمن تعود الفائدة؟ هل البديل متاح بالسهولة نفسها؟ وهل يستطيع الطفل تغيير رأيه من دون عقوبة أو فقد اجتماعي مصطنع؟

عدم تماثل الزر: نعم لامع ورفض مخفي

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

الافتراضات المسبقة التي تعمل ضد الطفل

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

False urgency: أسرع قبل أن يختفي العرض

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

المكافآت اليومية والخوف من فقد السلسلة

streaks والمكافآت اليومية قد تكون ممتعة، لكنها تصبح مشكلة عندما تجعل الطفل يشعر أن الغياب يومًا واحدًا خسارة اجتماعية أو تقدمًا لا يمكن تعويضه. راقب هل المنتج يعاقب الانقطاع أو يرسل إشعارات ذات لغة ضغط مثل أصدقاؤك ينتظرونك أو ستفقد كل شيء. يمكن الاحتفاظ بالتقدم، السماح بتجميد السلسلة، أو صياغة الرسائل باحترام. النجاح لا يقاس فقط بعدد الأيام المتتالية بل بقدرة الطفل على ترك التطبيق دون تكلفة مصطنعة.

Infinite scroll وAutoplay كجزء من هندسة الانتباه

التمرير اللانهائي والتشغيل التلقائي يزيلان نقطة التوقف الطبيعية. لا يعني ذلك أن كل استخدام لهما غير مناسب، لكن عند خدمة يستخدمها الأطفال يجب قياس أثرهما في مدة الجلسة، النوم، الانتقال إلى محتوى أكثر خطورة، والقدرة على الخروج. يمكن إضافة نقاط توقف أو controls واضحة أو تذكيرات اختيارية، وعدم إعادة تشغيل المحتوى بعد أن اختار الطفل التوقف. اربط المقاييس بالرفاه لا بالوقت على الخدمة وحده.

الإشعارات التي تصنع شعورًا زائفًا بالضرورة

ليس كل إشعار عاجلًا. red badges والصوت والعبارات الاجتماعية قد تجعل الطفل يفتح التطبيق دون قرار واعٍ. اجعل الإشعارات غير الضرورية قابلة للإيقاف بسهولة، ولا تفعّل عشر فئات دفعة واحدة. افصل إشعار أمان أو رسالة مباشرة حقيقية عن إشعار تسويقي أو تذكير بالعودة. لا تستخدم push لإجبار الطفل على استعادة streak أو شراء عنصر قبل انتهاء عداد مصطنع.

Confirmshaming: هل أنت متأكد أنك لا تريد حماية أصدقائك؟

يمكن للغة أن تجعل الرفض يبدو أنانيًا أو غبيًا: لا، لا أريد أفضل تجربة، أو تخطَّ وخسر المكافأة. هذه صياغة تضغط اجتماعيًا وعاطفيًا. استخدم خيارات وصفية مثل تشغيل التخصيص أو المتابعة دون تخصيص. لا تجعل الطفل يختار بين الحفاظ على كرامته وبين رفض مشاركة بيانات أو شراء خدمة. راجع النصوص مع أطفال من أعمار مختلفة للتأكد من أنهم يفهمون الخيار كما يقصده المصمم.

Roach motel: الدخول سهل والخروج معقد

إذا كان إنشاء الحساب أو الاشتراك يتم بنقرة بينما الإلغاء يحتاج صفحات واتصالًا بالدعم، فهناك عدم تماثل واضح. الطفل والأسرة يجب أن يستطيعا إيقاف التجديد أو حذف الحساب أو إلغاء feature عبر مسار مفهوم ومقارب في الجهد لمسار التفعيل. لا تجعل المستخدم يشرح سبب المغادرة في سلسلة شاشات قبل السماح له بالاستمرار. يمكن طلب feedback بعد الإلغاء لا قبله.

الحذف ليس اختبار ولاء

بعض الواجهات تستخدم صورًا حزينة أو رسائل تخويف مبالغًا فيها عند حذف الحساب. الرسالة المفيدة يوضح ما سيحذف وما يمكن استرجاعه والمدة. لا يضغط عاطفيًا على الطفل أو يوحي أن أصدقاءه سيتضررون. إذا كانت هناك بيانات يجب الاحتفاظ بها قانونيًا، اشرح الفئة والمدة بدل الادعاء أن كل شيء سيختفي أو سيبقى. وفر export مناسبًا قبل الحذف دون تحويله إلى عقبة.

الشراء داخل الألعاب والعملات الوسيطة

تحويل المال إلى gems أو coins قد يجعل التكلفة الحقيقية أقل وضوحًا، خصوصًا عندما تجمع الحزمة عدة عملات أو تستخدم احتمالات للحصول على عنصر نادر. اعرض السعر الحقيقي بوضوح، واحتمالات الجوائز عندما تنطبق، ولا تدفع الطفل للشراء عبر مؤقت أو ضغط الأقران. قضية FTC المتعلقة بـGenshin Impact في 2025 أبرزت مزاعم عن تضليل أطفال ومراهقين بشأن التكلفة الحقيقية واحتمالات الحصول على جوائز نادرة، ما يوضح أن تصميم الشراء نفسه جزء من الحماية لا مجرد مسألة مالية.

Loot boxes: عندما يختلط الشراء بالاحتمال

إذا دفع الطفل مقابل فرصة غير مؤكدة، يجب أن يفهم أنه يشتري احتمالًا لا نتيجة مضمونة. لا تستخدم رسومًا أو مؤثرات تجعل الاحتمال الصغير يبدو شائعًا، ولا تخفِ odds خلف صفحات بعيدة. وفر حدود إنفاق وإشعارات واضحة وسجل مشتريات يمكن للطفل والولي فهمه. لا تعتمد على parental control وحده إذا كانت الواجهة نفسها مصممة لإحداث شراء متكرر أو إحساس بالخسارة عند التوقف.

طلب بيانات إضافية مقابل تجربة أفضل

قد يقول التطبيق فعّل جهات الاتصال لتجد أصدقاءك أو شارك موقعك لتحصل على محتوى محلي أو أخبرنا بجنسك واهتماماتك للتخصيص. اسأل هل البيانات ضرورية حقًا. إذا كانت الخاصية اختيارية، يجب أن تبقى الخدمة الأساسية قابلة للاستخدام دون مشاركة غير لازمة. لا تعاقب الطفل بخفض مصطنع للجودة لأنه اختار الخصوصية. استخدم pro-privacy nudges التي تجعل الخيار الأكثر حماية مفهومًا وسهلًا.

طلب إذن نظام التشغيل في اللحظة الخطأ

نافذة إذن الكاميرا أو الميكروفون أو الموقع تظهر غالبًا بخيارات النظام، لكن التطبيق يقرر متى يستدعيها. لا تطلب كل الأذونات عند أول تشغيل بلا سياق. اطلب الإذن عندما يستخدم الطفل الوظيفة واشرح قبل نافذة النظام لماذا تحتاجه وما الذي يحدث إذا رفض. لا تكرر الطلب في كل جلسة حتى يستسلم المستخدم، ولا تستخدم شاشة pre-permission مضللة توحي أن القبول إلزامي.

Social proof المصطنع

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

التخصيص المتلاعب بحسب ضعف المستخدم

مع الذكاء الاصطناعي يمكن للواجهة تغيير التوقيت واللغة والعرض وفق سلوك المستخدم. إذا اكتشف النظام أن طفلًا يستجيب أكثر للندرة أو للمكافأة الاجتماعية ثم استغل ذلك لزيادة الإنفاق أو البيانات أو الوقت، يصبح الخطر أكبر من dark pattern ثابت. ضع قيودًا على personalization التجاري للقاصرين، وافصل نماذج السلامة عن نماذج زيادة conversion. لا تستخدم مؤشرات الضيق أو الوحدة أو الاندفاع لاستهداف عرض تجاري.

العمر والمرحلة النمائية

الواجهة المناسبة لمراهق أكبر قد تكون مربكة لطفل أصغر. اختبر فهم الاحتمالات والتكلفة والتجديد والخصوصية مع فئات عمرية مختلفة. لا تعتبر القراءة السريعة للنص دليلًا على فهمه. استخدم أمثلة وأرقامًا ملموسة عندما يحتاج القرار لذلك. إذا كانت الخدمة لا تعرف العمر بدقة، استخدم افتراضات آمنة أو تصميمًا يصلح للأصغر بدل إعطاء تجربة عالية الضغط لكل المستخدمين.

الإتاحة تمنع التلاعب غير المقصود

زر رفض منخفض التباين أو غير مسمى لقارئ الشاشة قد يصبح عمليًا غير متاح حتى لو كان موجودًا بصريًا. اختبر tab order وlabels وحجم الهدف والتكبير واللغة السهلة. لا تجعل countdown غير قابل للإيقاف للمستخدم الذي يحتاج وقتًا إضافيًا. الطفل الذي يستخدم AAC أو صعوبات تعلم يحتاج خيارات واضحة لا نصوصًا قانونية. التصميم العادل يجب أن يبقى عادلًا مع اختلاف القدرات.

التصميم العادل يقيس الفهم لا النقر فقط

ارتفاع conversion لا يثبت أن المستخدم أراد النتيجة. اختبر comprehension: ماذا اعتقد الطفل أنه سيحدث؟ هل عرف أن الاشتراك يتجدد؟ هل عرف أن الموقع سيصبح ظاهرًا؟ هل استطاع العثور على الرفض؟ اجمع feedback دون توجيه وراقب regret بعد القرار والإلغاء السريع. قد يكون انخفاض معدل القبول بعد جعل الواجهة أكثر حيادًا علامة نجاح في حماية الاختيار لا فشلًا تجاريًا.

A/B testing لا يبرر تجربة التلاعب على الأطفال

لا تختبر نسختين بهدف معرفة أيهما ينتزع بيانات أو شراء أكثر إذا كانت إحداهما تستغل ضغطًا أو غموضًا. حدد guardrails قبل التجربة: لا زيادة في مشاركة بيانات حساسة، لا إخفاء للرفض، لا ضغط مالي، ولا إضعاف للخصوصية. راجع التجارب ذات التأثير على القاصرين عبر privacy وsafety وethics، وليس growth فقط. احتفظ بقرار مكتوب يشرح لماذا التجربة في أفضل مصالح الطفل أو على الأقل لا تقوضها.

كيف تدقق واجهة حالية؟

  1. اختر عشر رحلات عالية الأثر: التسجيل والخصوصية والشراء والإلغاء والحذف والموقع والإشعارات والرسائل والتخصيص والعودة.
  2. قارن عدد الخطوات والوضوح بين القبول والرفض.
  3. سجل الافتراضات المسبقة واللغة العاطفية والضغط الزمني.
  4. اختبر الشاشة بقارئ شاشة وتكبير ولغة عربية.
  5. اطلب من أطفال ضمن منهج أخلاقي شرح ما يتوقعون حدوثه قبل النقر.
  6. راجع conversion مع regret والإلغاء السريع والشكاوى.
  7. افحص ما إذا كانت personalization تغير الضغط حسب السلوك.
  8. حدد كل nudge ومالك القرار والغرض منه.
  9. أزل ما لا تستطيع تبريره بمصلحة المستخدم.
  10. أعد الاختبار بعد التغيير ولا تفترض أن التصميم الجديد محايد تلقائيًا.

مقاييس يجب أن تتجاوز Conversion Rate

قِس وقت العثور على خيار الرفض، الفرق في الخطوات بين المسارين، نسبة المستخدمين الذين فهموا التجديد أو مشاركة البيانات، regret rate، الإلغاء خلال 24 أو 72 ساعة، refunds، شكاوى الضغط، إيقاف الإشعارات بعد تفعيلها، واستعادة privacy settings. افصل القاصرين عن البالغين. إذا ارتفع conversion لكن ارتفع معه الندم أو الاسترجاع أو الشكاوى، فالواجهة ربما حسنت قدرة الشركة على الدفع لا جودة القرار.

دور الأسرة

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

دور المدرسة

يمكن إدخال dark patterns ضمن التربية الإعلامية والمالية والخصوصية. استخدم شاشات نموذجية مصطنعة لا حسابات الطلاب الحقيقية، واطلب منهم مقارنة خيارين. عندما تختار المدرسة تطبيقًا، لا تنظر إلى الوظائف فقط؛ افحص الشراء والإشعارات والتتبع والحذف والnudges. إذا كان منتج تعليمي يضغط الطالب لإعطاء بيانات أو تفعيل ميزة غير ضرورية، فهذا عيب مشتريات وسلامة لا مهارة يجب على الطالب تحملها.

خطة 90 يومًا للمنتج

خلال أول 30 يومًا أنشئ inventory للnudges والافتراضات والاشتراكات والإشعارات ومواطن الضغط، واربط كل عنصر بمالك وغرض. خلال 31 إلى 60 يومًا أعد تصميم أعلى الرحلات أثرًا، وأدخل مراجعة privacy/safety قبل A/B tests واختبر الفهم والإتاحة. خلال 61 إلى 90 يومًا أضف metrics للندم والإلغاء والفهم، راجع personalization، وانشر مبادئ داخلية تمنع الواجهات التي تزيد البيانات أو الإنفاق عبر الخداع أو الإكراه. كرر المراجعة عند كل redesign كبير.

نموذج روافد المفاهيمي: اختبار الاختيار الحقيقي

تقترح روافد خمسة أسئلة مفاهيمية: هل يفهم الطفل النتيجة؟ هل الرفض متاح بالسهولة نفسها؟ هل هناك ضغط زمني أو اجتماعي مصطنع؟ هل يمكن التراجع من دون عقوبة؟ وهل تستفيد الخدمة من نقطة ضعف أو نقص فهم؟ إذا فشل التصميم في أكثر من محور، يحتاج مراجعة قبل الإطلاق. النموذج conceptual وغير متحقق، ويمكن اختباره بمهام فهم ومقاييس regret والفرق في زمن الوصول للقبول والرفض ومعدلات التراجع بعد القرار.

أسئلة شائعة

أسئلة شائعة

ما معنى Dark Patterns؟

أنماط تصميم توجه أو تخدع أو تضغط المستخدم لاتخاذ قرار لا يخدم مصلحته، مثل إخفاء الرفض أو خلق ندرة مصطنعة أو تعقيد الإلغاء.

هل كل Nudge سيئ؟

لا. يمكن استخدام nudges لتعزيز الخصوصية والسلامة. المشكلة عندما تستغل الواجهة الانحيازات لإضعاف اختيار الطفل أو زيادة البيانات أو الإنفاق.

هل Infinite Scroll نمط مظلم دائمًا؟

ليس دائمًا؛ يعتمد على الغرض والضوابط والأثر. لكنه يزيل نقطة توقف طبيعية ويحتاج تقييمًا خاصًا لدى الأطفال.

كيف أعرف أن الشراء داخل اللعبة متلاعب؟

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

هل يمكن للمدرسة تقييم Dark Patterns؟

نعم ضمن المشتريات والتربية الرقمية، عبر فحص الخصوصية والإشعارات والشراء والحذف والافتراضات لا الوظائف التعليمية فقط.

ماذا يعني Confirmshaming؟

صياغة خيار الرفض بطريقة تشعر المستخدم بالخجل أو الغباء أو الأنانية كي يدفعه التصميم إلى القبول.

ما أفضل مقياس للتصميم العادل؟

لا يوجد رقم واحد؛ قِس الفهم وسهولة الرفض والندم والإلغاء والشكاوى إلى جانب conversion.

كيف نستخدم A/B testing بأمان مع الأطفال؟

ضع guardrails تمنع اختبار الخداع أو الضغط أو إضعاف الخصوصية، وراجع التجارب عالية الأثر عبر privacy وsafety لا growth فقط.

المصادر والمنهجية

تعتمد الصفحة على تعريف OECD للأنماط التجارية المظلمة، ومعايير ICO الخاصة بالnudges والخصوصية الافتراضية للأطفال، وتحديثات Children’s Code خلال 2025، وإجراء FTC في 2025 بشأن ممارسات الشراء في Genshin Impact، وإرشادات UNICEF عن أفضل مصالح الطفل والممارسات التجارية الرقمية، وموقف eSafety لعام 2026 بشأن أنظمة التوصية وميزات الانخراط مثل autoplay والإشعارات. جرى تحويل هذه الأطر إلى اختبار عملي للواجهة دون افتراض أن كل تقنية إقناع محظورة أو أن كل زيادة في الاستخدام ضرر بحد ذاتها.

Parental controls قد تتحول هي نفسها إلى ضغط على الطفل

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

Forced action: لن تستخدم الخدمة إلا إذا أعطيتنا شيئًا لا نحتاجه

قد يطلب المنتج رقم الهاتف أو جهات الاتصال أو الموقع أو موافقة تسويقية كشرط للاستمرار رغم أن الوظيفة الأساسية لا تحتاج ذلك. هذا forced action يضع الطفل أمام تبادل غير متكافئ. افصل المتطلبات الحقيقية عن التحسينات الاختيارية، واسمح باستخدام الخدمة الأساسية بأقل بيانات. إذا كان هناك سبب أمني أو قانوني للبيان، اشرحه بوضوح. لا تجمع موافقة الإعلانات والاتصال بالغرباء والنسخ الاحتياطي داخل زر واحد باسم متابعة.

بعد تحديث التطبيق: راقب عودة الأنماط المظلمة

قد يصلح الفريق شاشة الخصوصية ثم يعيد redesign لاحقًا زرًا أكبر أو default أقل حماية. لذلك أضف regression tests للتجارب الحساسة: هل بقي الرفض مساويًا للقبول؟ هل عادت geolocation أو notifications إلى on؟ هل حذف الحساب ما يزال في المكان نفسه؟ هل تغيرت ترجمة العربية فصارت أكثر ضغطًا؟ اجعل هذه الاختبارات جزءًا من release gate، لا مراجعة سنوية فقط. أي تغيير في paywall أو onboarding أو privacy center يحتاج مقارنة قبل وبعد.

حوكمة النمو: من يستطيع الموافقة على تجربة عالية الضغط؟

حدد أنواع التغيير التي تحتاج مراجعة مشتركة من product وprivacy وsafety وlegal: paywalls للقاصرين، loot boxes، طلب بيانات حساسة، تغيير default، إخفاء خيار رفض، أو personalization تجاري مبني على الضعف. لا يكفي أن يقول فريق النمو إن التجربة رفعت conversion. يجب أن يسجل الغرض، المخاطر، guardrails، نتائج الفهم، وخطة rollback. إذا ظهرت زيادة في regret أو refunds أو شكاوى الأطفال، توقف التجربة أو عدلها حتى لو حققت هدفًا ماليًا.

علامة الجودة: يستطيع الطفل شرح القرار بعد الشاشة

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