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