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