إنّ إطلاق خاصيّة ناجحة يتطلب نفس المهارات لإطلاق منتجٍ ناجح، والفرق هو أنّك يجب أن تتعامل أيضًا مع القرارات السابقة، وترضي العملاء الحاليين كذلك. الأمر صعب.
إنّ غالبية الخصائص الجديدة تتخبّط أو تُخفق، ولكنّك لا تُلاحظ ذلك. ينتهي المطاف بالخصائص الجديدة بكونها غير مقدّرة، غير مستخدمة، وسرعان ما يتم نبذها؛ وهذا هو بيت القصيد. عليك أن تعرف أنّ التطوير والتحسين صعب في عالم البرمجيّات.
قد تقوم بإجراء الأبحاث لعدّة أشهر، تقوم بتحليل التّركيبية البشرية للمُستخدمين demographics، المقاييس metrics، البيانات الخاصة بتفهم عادات وثقافات الأفراد ethnographics، التحليلات، خواصّ التكوين النفسي للأفراد psychographics، تستطيع تسميتها ما شئت. كما تقوم بمقابلة العملاء لعدة أيام، أسابيع، أو أشهر في محاولة لفهم احتياجاتهم الحقيقية. ليس ما يقولون إنّهم بحاجة إليه، ليس ما يقولون إنّهم يُريدونه، وليس ما يطلبونه، بل ما يحتاجون إليه حقًّا. ثم تبدأ أنت ببناء ذلك، ومع ذلك ما تزال تُخفق؛ هذه هي المهمّة الصعبة.
الحقيقة هي أنّ الخاصيّة لا تُعتبر موجودة ما لم تُستخدم من قبل العميل، وهذا الأمر غالبًا ما يتم نسيانه عند الاندفاع لإتاحة الخاصيّة بشكل سريع. إنّ الأمر لا يتعلّق بإنهاء برمجة الخصائص ودفعها إلى الخادوم، ولا بالتحقق من أنّك قمت بجميع الخطوات اللازمة، الأمر يتعلّق بالوصول إلى منتج يُستخدم من قبل العملاء. لذلك قبل أن تقوم بتقديم الخاصيّة التالية، اسأل نفسك هذه الأسئلة:
1.هل سيراها ويفهمها الجميع؟
عندما قامت شركة مايكروسوفت بعمل استطلاع لمعرفة الخصائص التي يرغب المستخدمون في أن تقوم الشركة بإضافتها إلى Office، وجدوا أنّ 90% من الخصائص هي موجودة أصلًا في البرنامج. افترضت مايكروسوفت أنّ هذا هو تحدّي الوعي بالبرنامج، وبالتالي أطلقت شريط الأدوات الجديد ribbon toolbar الذي يقوم بإبراز جميع الخصائص، وبالتالي لا يتم إبراز أي شيء كما قلت سابقًا، الأمر صعب ومعقّد.
بالتأكيد أنت تريد أن يبدو المنتج متكاملًا عندما تصمّم النسخة الأولى منه، وبذلك قد لا تخطط لتوسيعه بالضّرورة، أو تترك مجالًا للخصائص الإضافيّة. وعندما تقوم بإضافة تلك الخصائص ستتيح لها مجالًا، وسيسبب ذلك المشاكل للمستخدمين في قابلية اكتشاف discoverability خصائص المنتج. فإذا وجدت نفسك تجيب على أسئلة حول مكان الخاصيّة باستمرار، اعلم أنّك تواجه مشكلة في قابلية الاكتشاف، وأنّ جميع الخصائص الجديدة ستخفق، أو على الأقل ستتطلب الكثير من الممارسة للعثور عليها واعتمادها.
2. هل تعرض على المستخدمين ما قمت به، أم ما يمكنهم القيام به؟
عندما تقوم بإخبار العملاء أنه تمّت إعادة برمجة المُنتج من الصّفر "ground up rewrite، "معتمد على HTML5"، أو "ذو تصميم متجاوب" أو أي شيء من هذا القبيل، ستفشل في الوصول إلى النتيجة المقصودة، إلّا إذا كنت تبيع للمطوّرين. لا أحد يهتم بما قمت به، أو كيف قمت به، يهتم العملاء بما يستطيعون القيام به من خلال المنتج فحسب.
ركّز رسالتك على ما يمكن للمستخدمين تحقيقه الآن مع الخاصيّة الجديدة، وبذلك تستطيع جذب اهتمامهم.
3. هل تقوم بالإعلان عن الخاصية في السياق المناسب؟
إنّ الخصائص الجديدة، خصوصًا الإضافات الصغيرة، تُضاف إلى المنتج ويُعلن عنها في السياق غير المناسب عندما لا يكون العميل يستخدم المُنتج بالفعل. يجب ألّا يكون هدفك "إطلاق الخاصيّة" وإنّما "استخدام الخاصيّة" من قبل العملاء. إنّ البريد الإلكتروني هو وسيلة خاطئة لهذا النوع من الإعلانات؛ حيث أنّه يعتبر مبالغ فيه، وعادةً ما يصل في الوقت الخطأ وفي المُناسبة الخطأ. وبذلك يكون أفضل وقت للترويج للتحسينات الجديدة هو عندما يكون أحدهم يعرف منتجك ويستخدمه بالفعل.
4. كيف سيسمع عملاء الغد عن الخاصية الجديدة؟
طالما يتطوّر المنتج فهو يتوسّع أبعد مما يمكن تعلّمه خلال فترة قصيرة من الزمن. وهذه ليست مشكلة، حيث أنّه ليس من الضرورة أن تكون الخصائص معقولة ومفهومة منذ البداية. تكون الخصائص ملائمة فقط عندما تحل المشاكل. ولتبسيط الموضوع، أنت لا تحتاج إلى إضافة وسوم إلى الملفات ما لم تنتهي عملية رفعها. كما أنّك لا تحتاج إلى دمج الوسوم ما لم يكن لديك العديد من الوسوم المختلفة. لذلك من الطبيعي أن يكون توقيت الرسالة خاطئًا عندما تخبر المستخدمين الجدد عن طريقة دمج الوسوم.
هنالك أوقات مناسبة لتقديم الخصائص للعملاء، وعندها تصبح الرسائل الموجّهة مهمّة. مثلًا، قمنا بالترويج لخاصيّة حفظ الردود في Intercom عندما أصبح لدينا عددًا من الردود المُرسلة. كما قمنا بالترويج لخاصيّة اختصارات لوحة المفاتيح الخاصّة بـ Intercom بعد أن استخدم العملاء المنتج لمدة كافية تجعلهم يهتمون بالاختصارات. هذه هي طريقة جعل الرسائل مهمّة.
5. هل تخطط للمتابعة مع المستخدمين وغير المستخدمين؟
يجب عليك بعد أن تطلق الخاصيّة أن تقوم بمتابعة مستخدميها لفهم ومعرفة كيف، لماذا ومتى تُستخدم. ابحث عن طرق لزيادة استخدامها. إليك بعض الأسئلة التي وجّهتها للعملاء حول الخاصيّة الجديدة:
- متى قمت بملاحظتها؟ ما رأيك فيها؟ هل استخدمتها مباشرةً؟ ما الذي جذبك إليها؟
- هل احتجت إلى دليل استخدام الخاصيّة؟ هل كان ذلك الدليل كافيًا؟
- هل كانت هنالك عوائق لاستخدامها؟
- هل هنالك أوقات تريد استخدام الخاصيّة فيها ولكنّك لا تستطيع؟
- هل أخبرت أحدًا عن سبب استخدامك للخاصيّة؟ ما الذي قلته؟
إنّ متابعة الأشخاص الذي لا يستخدمون الخاصيّة وفهم السبب الذي يمنعهم من ذلك له القدر نفسه من الأهميّة، إن لم يكن أكثر أهميّة، من متابعة مستخدميها. ستجد أحيانًا أن الحواجز التي تعيقهم سهلة الكسر. مثلًا؛ "أنسى دائمًا أن أراجع المنتج"، "لا أعرف إذا كان هنالك أحدًا آخر يستخدمها في الشركة"، "أنا بحاجة إلى الحصول على ملف CSV للبيانات"، إلخ. جميع هذه المشاكل قابلة للحل فيما إذا فهمتها بصورة جيّدة.
يجب أن تعرف أنّه خلال عملية التصميم قد تخطئ في أشياء معيّنة، وهذه الحقيقة يتم تجاهلها في العديد من المخططات التفصيلية للمنتج. يخطئ المصمّمون في أحيانٍ كثيرة، وعندها يصبح لديهم خياران؛ تحسين الخاصيّة، أو تجاهلها والانتقال إلى الخاصيّة التالية.
إذا اخترت الخيار الثاني، فهذا يعني أنّك ستقع في الفخ الذي وقعت فيه ميكروسوفت: إضافة خصائص لا يعرف أحد بوجودها.
ترجمة-وبتصرّف-للمقال: Why New Features Usually Flop لصاحبه: Des Traynor.
أفضل التعليقات
لا توجد أية تعليقات بعد
انضم إلى النقاش
يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.