مرحبًا بكم في سلسلة "خرافات UX"، حيث أفنّد مفاهيم التصميم الخاطئة الشائعة التي تتكرر في اجتماعات المنتج (وأحاول تصحيحها).

البيانات الوهمية مقابل بيانات الاختبار

عندما يتحدث الناس عن البيانات الوهمية (dummy data)، فهم يقصدون غالبًا مجموعة من الكلمات العشوائية التي لا تحمل أي بيانات ذات قيمة، بل تؤدي دور العنصر النائب. يلجأ المصممون عادة إلى البيانات الوهمية، مثل مقتطفات Lorem Ipsum التي ترونها في المواقع وقوالب التصميم، كلما كانوا غير متأكدين من المعلومات الواردة في المتطلبات (أو عند غيابها)، على أمل أن يصل المحتوى الفعلي (أو لا يصل) في مرحلة لاحقة.

أما بيانات الاختبار (test data) فهي معلومات مزيفة لكنها مرتبطة بسياق المكان الذي توضع فيه، فتنتج بيئة أقرب إلى بيئة الإنتاج الحقيقية.

كيف تُبطئ البيانات الوهمية المشروع

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

لإعداد هذه البيانات، لا يحتاج المرء إلا إلى الرؤى التي يقدمها أصحاب المصلحة. مثلًا: ماذا ستحتوي هذه المساحات؟ ما البيانات التي نستقبلها من الـ API؟ هل نأخذ في الحسبان الحالات المثالية (happy cases) والحالات الحدّية (edge cases) في رحلات المستخدم هذه؟

ويمكن لنقاش سريع في ورشة عمل واحدة أن يجنّب الجميع الصداع الذي ينتج لاحقًا عن سوء التواصل المسبق.

الحلول البديلة

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