تعتمد إستراتيجية منتج الحد الأدنى MVP على إطلاق منتجات بمزايا قليلة، إذ تساعد هذه المنتجات على الكشف عن آراء المستخدمين، حيث أن تكلفة إطلاق منتج ما بمزايا محدودة هي أقل من تكلفة إطلاق منتج بمزايا كاملة.
تواجه معظم فرق المنتجات في الشركات الناشئة مشكلة الميزانيات المحدودة والمواعيد النهائية الضيقة، إضافةً إلى شُح الموارد المتوفرة، لذا من الصعب عليهم إنشاء منتجات جديدة كاملة المزايا دون وجود عدد مضمون من المستخدمين.
لحسن الحظ، يمكن معالجة المشكلة السابقة من خلال إستراتيجية منتج الحد الأدنى MVP، إذ يحتوي منتج الحد الأدنى على عدد قليل من المزايا، مما يقلل من تكلفة إطلاقه، مع إمكانية إضافة مزايا أخرى مستقبلًا لتطوير المنتج وتحسينه، كما يساعد منتج الحد الأدنى فرق المنتجات على معرفة جمهورهم المستهدف جيدًا، مع بذل جهد أقل في عملية التصميم والتطوير.
سنتحدث في هذا المقال عن الخطوات الرئيسية لإتقان عملية تطوير منتج الحد الأدنى، وسندعم تلك الخطوات بمثال عملي لكي يُوضَح الأمر جيدًا للقراء، وهذا المثال هو تطبيق لتوصيل الطعام، مثل تطبيق Grubhub أو تطبيق Uber Eats.
تحديد متطلبات المنتج
تتمثل الخطوة الأولى في عملية تطوير منتج الحد الأدنى في تحديد غرض المنتج ومزاياه ووظائفه باستخدام مستند متطلبات المنتج PRD الذي يجب أن يشتمل على:
- بيان المشكلة.
- شخصيات المستخدمين.
- قصص المستخدمين.
- الافتراضات.
- القيود.
- مقاييس النجاح.
وإليك ما يجب أن يبدو عليه مستند متطلبات المنتج لتطبيق توصيل الطعام:
بيان المشكلة
يحدد بيان المشكلة مشكلة المستخدم الواقعية التي يهدف المنتج إلى حلها، ويجب ألا تكون المشكلة أكثر من جملة واحدة وتتضمن فهمًا واضحًا لهدف المنتج، حيث يمكن القول على سبيل المثال: "نهدف إلى ربط العملاء الجائعين بمطاعم رائعة يمكنها توصيل طلباتهم في أسرع وقت ممكن".
شخصيات المستخدمين
شخصية المستخدم هي شخصية خيالية تمثل نوعًا من المستخدمين وتقوم بمجموعة من الإجراءات الفريدة، كل شخصية تساهم في حل التحدي المحدد في بيان المشكلة، وشخصيات تطبيق توصيل الطعام لدينا هي:
- أنس وهو اسم صاحب المطعم.
- أحمد وهو مسؤول التسليم.
- سليم وهو الزبون.
- ياسر وهو مسؤول الدعم.
يساعد استخدام الشخصيات في منتج الحد الأدنى على فهم المستخدمين النهائيين والتعاطف معهم، وبالتالي استهداف تصميماتهم وفقًا لاحتياجاتهم.
قصص المستخدمين والإجراءات
قصة المستخدم هي شرح موجز لكيفية تفاعل الشخصية مع منتج ما وتحقيق أحد أهداف المنتج النهائية، فعلى سبيل المثال، بالنسبة إلى أنس صاحب المطعم، فإنه يمكن أن يقول: "عندما يقدم العميل طلبًا (السياق)، أريد أن أُعلَم بذلك وأن أطّلع على تفاصيل الطلب (الإجراء) لكي أتمكن من مراجعته والرد عليه في أقل من 30 ثانية (الهدف)".
يمكن أن يساعد إنشاء شخصيات وقصص للمستخدمين فرق المنتج على معرفة المزيد عن جمهورهم المستهدف، إذ تساعد قصص المستخدم الواضحة والقابلة للتنفيذ على توجيه قرارات التصميم حول احتياجات المستخدم.
أما الإجراءات فهي مجموعة كبيرة من قصص المستخدمين التي يمكن تقسيمها إلى قصص أصغر، وإجراءات تطبيق توصيل الطعام لدينا هي:
- طلب وجبة.
- الإبلاغ عن عنصر مفقود.
- تقييم تجربة التسليم.
- إرجاع عنصر.
الافتراضات
الافتراضات هي ما نتوقع أن يفعله أحد الأقسام أو كيفية تصرف المستخدم، فعلى سبيل المثال، قد نفترض أن أحمد مسؤول التسليم سيعمل خلال ساعات عمل المطعم، ومع ذلك، قد لا يكون جدوله الزمني وساعات عمل المطعم متوافقة.
القيود
تحدد القيود قيود المنتج المحتملة، فعلى سبيل المثال، لن يتلقى الزبون سليم تحديثات عن حالة طلبه في حالات ضعف الشبكة، فمن خلال تحديد الافتراضات والقيود في مستند متطلبات المنتج، فإنه يمكن معالجتها في وقت مبكر من العملية وتوفير تجربة مستخدم أفضل.
مقاييس النجاح
تُعَد مقاييس النجاح القابلة للتنفيذ -مثل المشاركة ومعدل التغيير ومدة الجلسة- ضروريةً لقياس أداء منتج الحد الأدنى، كما يساعدنا تطوير هذه المقاييس على التحقق من صحة مفهوم المنتج الأصلي وتوجيه عملية التطوير، وبالنسبة إلى تطبيق توصيل الطعام فقد أدرجنا:
- عدد التنزيلات.
- معدل تسجيل الدخول.
- معدل قضاء الوقت في التطبيق.
تنظيم المحتوى الرقمي لمنتج الحد الأدنى
تتمثل الخطوة التالية في عملية تصميم منتج الحد الأدنى في تصنيف وتنظيم المحتوى الرقمي للتطبيق، مثل الأقسام والصفحات والمزايا، ويُطلق على نتيجة هذه العملية "بنية المعلومات IA" ويمكن تقسيمها إلى جزأين:
- تحديد محتوى التطبيق.
- تحديد التسلسل الهرمي للمحتوى.
يُعَد تعريف بنية المعلومات أمرًا أساسيًا لبناء تطبيقات غنية بالمحتوى من خلال التنقل السهل.
تحديد محتوى التطبيق
من أجل تحديد محتوى التطبيق مثل الصور والموسيقى والنصوص ومقاطع الفيديو وما إلى ذلك، فيجب أن نبحث أولًا عن التوجهات والمنافسين والجمهور المستهدف، وبعد ذلك، ننشئ خريطةً ذهنيةً تشمل الفروع والمواضيع الرئيسية والفرعية، إذ تساعدنا هذه الخرائط على تصور كامل محتوى التطبيق في مكان واحد وربط الموضوعات المتعلقة مع بعضها البعض.
ستتضمن خريطتنا الذهنية للتطبيق ما يلي:
- الموضوع الرئيسي: وهو المطعم مع مواضيع فرعية أخرى، مثل القائمة وسجل الطلبات وصفحات قاعدة بيانات العملاء.
- الموضوع الفرعي للقائمة: والذي يتكون من خيارات الأطعمة والمشروبات والعروض الخاصة.
تحديد التسلسل الهرمي للمحتوى
نحتاج بعد ذلك إلى تحديد كيفية تقديم محتوى تطبيقنا، أي ماهية التسلسل الهرمي للمحتوى، وتُعَد طريقة فرز البطاقات من أفضل الطرائق لترتيب المحتوى، إذ ينظم المستخدمون الموضوعات في مجموعات منطقية، مما يضمن تنظيم البيانات وفقًا لتوقعات المستخدم، عوضًا عن تنظيمها وفقًا لافتراضات فريق المنتج.
يمكنك اتباع الخطوات التالية لإجراء فرز البطاقات:
- اختيار الموضوعات التي تمثل المحتوى الرئيسي للمنتج.
- تنظيم الموضوعات في مجموعات مع المستخدم.
- تسمية كل مجموعة مع المستخدم ومناقشة الأساس المنطقي وراء كل قرار.
- تكرار الخطوات الثلاث الأولى مع مستخدمين إضافيين.
- تحليل النتائج والبحث عن الأنماط المشتركة بين المجموعات.
إنشاء النماذج الأولية
من خلال تحديد المحتوى وتنظيمه، يمكنك إنشاء مخطط واجهة المستخدم الأساسية للتطبيق باستخدام أداة التخطيط الشبكي التي لها العديد من الفوائد، فهي تسمح لنا بتصور منتجنا. وبالنسبة إلى تطبيق توصيل الطعام، سنعمل على إنشاء نموذج أولي على مرحلتين:
- اُرسم تخطيط كل شاشة، بما في ذلك الأحجام، وتحديد الأماكن.
- أنشئ مكونات واجهة المستخدم الأساسية، بما في ذلك العناوين وكتل المحتوى والقوائم. ستعمل مكونات واجهة المستخدم هذه مثل خطوط أساسية حتى نحول النموذج الأولي البسيط إلى نموذج أولي عالي الدقة.
لدينا الآن نموذج أولي يمكننا من خلاله تصور هيكل التطبيق ووظائفه الأساسية.
عادةً ما تتضمن النماذج الأولية منخفضة الدقة المحتوى الأساسي وهيكل التطبيق ومتطلبات المنتج، حيث أنها سهلة الإنشاء ويمكن تعديلها بسرعة مع كل تكرار للتصميم.
اختبار النموذج الأولي مع المستخدمين
تتضمن عملية تصميم منتج الحد الأدنى عملية الاختبار مع المستخدم، وذلك من أجل تحديد نقاط الضعف المحتملة وإصلاحها في وقت مبكر.
فعلى سبيل المثال، نلاحظ في تطبيقنا الخاص بتوصيل الطعام أن المستخدمين لا يطبقون مُرشِّحات التطبيق لتحسين أنواع الطعام أو الأسعار أو المسافة، لذا سنجري نوعين من الاختبارات، اختبارات كمية واختبارات نوعية، وذلك بغية جمع معظم تعليقات المستخدمين لفهم السبب.
- الاختبارات الكمية: توفر الاختبارات الكمية تقييمًا غير مباشر لقابلية الاستخدام من خلال قياس أداء المستخدمين في مهمة معينة، وتكمن فائدة هذا النوع من الاختبارات في أننا نحصل على عدد من تعليقات المستخدمين حول مشكلة ما دون وجود نتائج "عشوائية" قد تؤثر على استجابتنا لتلك المشكلة، فعلى سبيل المثال، يُظهر اختبار النقر انخفاضًا حادًا في مكان زر تصفية البحث ومعدل إكمال منخفض لهذه المهمة، وبالتالي يمكننا أن نرى أن المستخدمين يواجهون مشكلةً مع المُرشِّحات، دون تحديد ماهية المشكلة.
- الاختبارات النوعية: تعمل هذه الاختبارات على مراقبة المستخدمين لفهم كيفية إكمالهم للمهمة وطرح أسئلة تساعد على فهم مشكلتهم، إذ تقدم الاختبارات النوعية تقييمًا مباشرًا لقابلية الاستخدام من خلال البيانات النوعية، وتكمن فائدة هذا النوع من الاختبارات في أنه يمكننا تحديد الجوانب التي تسبب المشكلات للمستخدمين. فعلى سبيل المثال، قد تكشف الاختبارات النوعية عن صعوبة فهم المستخدم لكيفية عمل المُرشِّحات لأن نص المرشح صغير جدًا وغير واضح للمستخدمين. وباستخدام هذه التعليقات الجماعية، يمكننا إجراء التعديلات على النموذج الأولي لبناء ميزة تصفية سهلة الاستخدام.
تطوير نموذج أولي عالي الدقة
بعد التحقق من صحة النموذج الأولي البسيط، فقد حان الوقت لترقية المنتج لإنشاء نموذج أولي عالي الدقة، إذ تستفيد النماذج الأولية عالية الدقة من تصميم واجهة المستخدم والرسوم المتحركة المثالية، حيث أنها أقرب بكثير في المظهر الخارجي والوظائف إلى المنتج النهائي. ويمكننا تحويل النموذج الأولي البسيط إلى نموذج أولي تفاعلي عن طريق:
- صقل العلامة التجارية لواجهة المستخدم، مثل التدرجات اللونية واللوحات والطباعة.
- تطبيق الرسوم المتحركة المتقدمة، مثل التمرير والنقر والتفاعلات الدقيقة.
التصميم النهائي
يجب علينا أخيرًا أن نتأكد من أن كل شيء يسير وفق الخطة المتوقعة من خلال النقر على النموذج الأولي والتحقق مما يلي:
- يتوافق منتج الحد الأدنى مع مفهوم المنتج الأولي.
- انتقال المستخدم بين محتوى المنتج طبيعي وسلس.
- تم النظر في جميع المشكلات التي واجهت المستخدمين.
- تم إصلاح جميع أخطاء التطوير.
يمكننا بعد ذلك أن نلخص أي مشكلات متبقية ونرسلها إلى فريق التطوير لضمان تحسين الجودة، ومن ثم يمكننا معالجة هذه المشكلات في فترة تتراوح بين أسبوع إلى أسبوعين قبل إطلاق منتج الحد الأدنى.
في الختام
يمكننا أن نلاحظ ندرة موارد التصميم في عالم تطوير التطبيقات، لذا فإن الحل الأمثل في هذه الحالة هو الاعتماد على منتجات الحد الأدنى التي تتيح للمصممين إمكانية بناء وإطلاق منتجات سهلة الاستخدام دون تحمل عبء الميزانيات الضخمة.
ترجمة -وبتصرّف- للمقال 4 Steps to Mastering the MVP Development Process لصاحبه Calin Balea.
أفضل التعليقات
لا توجد أية تعليقات بعد
انضم إلى النقاش
يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.