كيفية طرح ميزات جديدة دون الإضرار بالمستخدمين الموالين

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

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

مزيد من القراءة على SmashingMag: Link

• كيف بدأنا في إصدار الميزات مرتين بالسرعة
• قائمة التحقق من إطلاق موقع الويب - 15 عملية تحقق أساسية قبل بدء البث المباشر
• نهج يركز على المستخدم لتصميم الويب للأجهزة المحمولة
• كيف تطلق أي شيء

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

قبل الغوص في استراتيجية اختبار فعلية ، دعنا نتراجع ونفحص المفاهيم الخاطئة الشائعة حول كيفية تصميم ميزة جديدة وبناؤها ونشرها في النهاية.

مفاهيم خاطئة عن الميزة الجديدة

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

ربما تكون نسخة الواجهة غامضة في المناطق ذات الصلة ولكن البعيدة من موقع الويب ، أو أن نتيجة استخدام ميزتين بنشاط في نفس الوقت تبدو منطقية من منظور تقني ولكنها لا تتطابق مع توقعات المستخدم أو لها آثار كبيرة على الأداء وتضر بتجربة المستخدم .

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

تصميم القيم المتطرفة: حزمة واجهة المستخدم

كيف يمكننا تحديد القيم المتطرفة بمجرد تحديدها؟ الإستراتيجية الجيدة هي دراسة الحالات المختلفة لواجهة المستخدم. تعد "حزمة واجهة المستخدم" ، وهي فكرة قدمها سكوت هيرف ، متعددة الاستخدامات ومعقدة ، وعندما نصمم واجهاتنا ، لا يكفي عادةً صياغة نموذج بالحجم الطبيعي للبكسل في Photoshop أو Sketch أو HTML و CSS - علينا التفكير حالات وحالات الحافة المختلفة: الحالة الفارغة ، وحالة التحميل ، والحالة الجزئية ، وحالة الخطأ ، والحالة المثالية. هذه ليست مباشرة كما نعتقد.

لا يجب أن تكون الحالة الفارغة فارغة - فقد نستخدم عمال الخدمة لتوفير تجربة أفضل في وضع عدم الاتصال للزوار العاديين. لا يجب كسر الحالة الجزئية - يمكننا تحسين تجربة الصور المكسورة وجافا سكريبت المكسور من خلال التحسين التدريجي.

قد تختلف الحالة المثالية بشكل كبير عن نماذج "النتيجة المثالية" - نظرًا لتفضيلات المستخدم المخصصة واختيار متصفح المستخدم ؛ قد لا يتم عرض بعض المحتويات وخطوط الويب بسبب تكوين المستعرض ، على سبيل المثال.

لذا ، فإن المنظر الطبيعي ، كما هو الحال دائمًا ، معقد ومعقد ولا يمكن التنبؤ به ، ولا يمكننا أن نجعل خطر حدوث أشياء خاطئة ضئيلًا ، لكن هذا لا يعني أننا لا نستطيع تقليل المخاطر بشكل فعال. من خلال استكشاف القيم المتطرفة ومكدس واجهة المستخدم بالكامل في وقت مبكر ، يمكننا منع مشكلات UX الشائعة في مرحلة التصميم المبكرة. ومع ذلك ، لا يصبح الأمر أسهل من الناحية الفنية.

تأثير الفراشة في الانتشار

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

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

الحقيقة هي أننا لا نبني زرًا فحسب ، ولا نكتفي أبدًا بكتابة وظيفة JavaScript جديدة - تنتمي الأزرار والوظائف إلى مجموعة من المكونات أو المكتبات ، وتعمل جميعها ضمن إعداد معين ، وهي متصلة حتما بأخرى أجزاء من النظام حسب خصائصها أو نطاقها أو باسمها أو باتفاقيات الفريق غير المكتوبة.

هذه الروابط "الصامتة" التي لا تكاد تُلاحظ هي السبب في صعوبة طرح الميزات ، ولماذا غالبًا ما يثبت التنبؤ بالنتائج بعيدة المدى للتغيير على أنه تمرين في بصر شديد. هذا هو السبب في أنها فكرة جيدة لتجنب التبعيات غير الضرورية قدر الإمكان ، سواء كان ذلك في CSS أو JavaScript - فهي لن تساعدك في الصيانة أو تصحيح الأخطاء ، خاصة إذا كنت تعتمد على مكتبة لا تفهمها تمامًا .

لحسن الحظ ، لفهم تأثير التغيير بشكل أفضل ، يمكننا استخدام الموارد مثل أدوات مطور المتصفح. يمكننا قياس مدى وصول المحدد أو مدى وصول وظيفة JavaScript ، وفي بعض الأحيان قد يكون من الجيد الاستمرار في العودة إليها أثناء التطوير للحفاظ على نطاق التغيير محليًا وبأقل قدر ممكن.

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

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

التحقق من صحة الميزة والحد الأقصى المحلي

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

• الميزات المكسورة. . الميزات التي تبدو معطلة أو غير فعالة - من الواضح أننا بحاجة إلى إصلاحها ؛
• الميزات غير المستخدمة. . الميزات التي تعمل على النحو المنشود ولكنها نادرًا ما تُستخدم - غالبًا ما تكون علامة على أنه يجب إزالتها أو أنها بحاجة ماسة إلى الابتكار ؛
• ميزات الاستخدام غير المتوقع. . الميزات التي تُستخدم بطريقة مختلفة تمامًا عما تصوره مبدعوها في الأصل - مرشح جيد للتحسين البطيء والمستمر ؛
• ميزات العمود الفقري. . الميزات التي يتم استخدامها بكثرة ويبدو أنها تعمل كما هو مخطط لها - وفي هذه الحالة نسأل أنفسنا ما إذا كان هناك أي طريقة لتحسين تجربة المستخدم الخاصة بهم من خلال استكشاف كل من العملية التكرارية البطيئة والمفاهيم المبتكرة المختلفة تمامًا بالتوازي.

تعتبر المجموعتان الأوليان مهمتان للحفاظ على واجهة وظيفية وقابلة للاستخدام ، بينما تعد المجموعتان الأخيرتان مهمتين للحفاظ على تفاعل المستخدمين وإسعادهم. من الناحية المثالية ، نريد الوصول إلى كلا الهدفين في نفس الوقت ، لكن الوقت والميزانية وقيود الفريق لها اليد العليا.

ومع ذلك ، بمجرد اختيار تكرار جديد أو فكرة جديدة ، قد يكون من المغري القفز إلى تصميم أو بناء الميزة الجديدة على الفور. ولكن قبل التفكير في كيفية ملاءمة ميزة ما في واجهة موجودة ، فمن الإستراتيجية الجيدة التحقق من صحة الفكرة أولاً - باستخدام نموذج أولي سريع وبحث المستخدم. من الطرق الشائعة لتحقيق ذلك استخدام عملية تكرارية سريعة ، مثل سباق تصميم Google Ventures. من خلال التكرار في غضون يومين ، يمكنك تحديد كيفية تنفيذ الميزة الجديدة و / أو ما إذا كانت مفيدة بالطريقة التي كنت تتخيلها في البداية.

من خلال عمليات التصميم السريعة ، نعرض الفكرة على أبحاث قابلية الاستخدام في وقت مبكر. في منهجية Google Ventures ، ستختبر تصميمًا مع خمسة مستخدمين يوميًا ؛ بعد ذلك ، ستقوم بالتكرار والمرور بجولة أخرى من اختبار التصميم الجديد. السبب وراء مشاركة جميع المستخدمين هو أنك إذا اختبرت تصميمًا مختلفًا مع كل مستخدم في ذلك اليوم ، فلن يكون لديك بيانات صالحة لمعرفة العناصر التي يجب تغييرها. أنت بحاجة إلى عدد قليل من المستخدمين للتحقق من صحة تكرار تصميم واحد.

نطبق نموذجًا مختلفًا قليلاً في سباقاتنا. عندما نبدأ العمل على ميزة جديدة ، بمجرد بناء نموذج أولي مبكر ، نجمع المصممين والمطورين وفريق UX معًا في نفس الغرفة ، وندعو مستخدمين حقيقيين للاختبار ثم التكرار وفقًا لجدول زمني ضيق. في اليوم الأول ، قد يتم تحديد موعد للمختبرين الأوائل (من شخصين إلى ثلاثة أشخاص) لمقابلة مدتها 30 دقيقة في الساعة 9:00 صباحًا ، والمجموعة الثانية في الساعة 11:00 صباحًا ، والمجموعة التالية في الساعة 2:00 مساءً ، والأخيرة واحد حوالي الساعة 4:00 مساءً. بين مقابلات المستخدم ، لدينا "نوافذ زمنية مفتوحة" ، عندما نكرر في الواقع التصميم والنموذج الأولي حتى نحصل في مرحلة ما على شيء قابل للتطبيق.

والسبب في ذلك هو أننا نريد في وقت مبكر استكشاف اتجاهات مختلفة تمامًا ، وأحيانًا معاكسة ، بسرعة ؛ بمجرد أن نجمع التعليقات على واجهات مختلفة ، يمكننا الالتقاء نحو ما يشبه واجهة "الحد الأقصى المطلق" . يمكننا الحصول على تعليقات متنوعة للغاية حول تكرارات التصميم المتنوعة بشكل أسرع بهذه الطريقة. تستند التعليقات في الغالب إلى ثلاثة عوامل: الخرائط الحرارية التي تسجل نقرات المستخدم ، والوقت الذي يحتاجه المستخدمون لإكمال مهمة ، ومدى إمتاعهم بالتجربة. في وقت لاحق من الأسبوع ، نواصل العمل باستمرار مع عدد أكبر من المستخدمين ، مثلما تفعل Google إلى حد كبير ، حيث نتحقق بشكل دائم من صحة التصميم الجديد مع تقدمنا.

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

في كلتا الحالتين ، من الأهمية بمكان الحفاظ على التركيز على تجربة المستخدم الكاملة للمنتج ، بدلاً من التركيز على قيمة ميزة واحدة داخل هذا المنتج. وبمجرد اختيار الميزة وتصميم وبناء النموذج الأولي الأول ، فقد حان الوقت للاختبار.

المستويات الثمانية للاختبار

حسنًا ، إذن ، كيف نمنع بشكل فعال الأخطاء والفشل من التسلل إلى بيئة حية فعلية؟ كم عدد عمليات التحقق والمراجعات والاختبارات التي نجريها قبل نشر الميزة؟ وفي أي تسلسل نجري هذه الاختبارات؟ بمعنى آخر ، كيف ستبدو الإستراتيجية النهائية لنشر الميزات؟

إحدى أفضل الإستراتيجيات لنشر الميزات اقترحها أندرو سومين ، رئيس التطوير في Mail.ru ، وهو مزود بريد إلكتروني رئيسي في روسيا. لن تكون الإستراتيجية قابلة للتطبيق على كل مشروع ، لكنها نهج معقول وشامل للشركات التي تقدم منتجات متوسطة الحجم وكبيرة لآلاف العملاء.

لنلقِ نظرة على الاستراتيجية بالتفصيل ونغطي الخطوات الثماني لطرح الميزة ، والتي تغطي عملية تطوير المنتج في Mail.ru:

1. اختبار مع المطورين ،
2. اختبار مع مستخدمين حقيقيين في بيئة خاضعة للرقابة ،
3. اختبار مع المستخدمين على مستوى الشركة ،
4. اختبار مع مختبري بيتا ،
5. اختبار مع المستخدمين الذين اشتركوا يدويًا ،
6. اختبار الانقسام والتحقق من الاحتفاظ ،
7. الافراج ببطء وتدريجيا ،
8. قياس التداعيات.

في حالة Mail.ru ، أهم ميزة هي الحفاظ على سلامتها بغض النظر عن ما يؤلف رسالة (من الواضح). هذا هو الجزء الأكثر استخدامًا من الواجهة ، والسماح لها بأن تكون غير متاحة أو تعمل بشكل غير صحيح حتى لثوانٍ سيكون أمرًا غير وارد على الإطلاق. لذا ، ماذا لو أردنا توسيع وظائف منطقة النص ، ربما عن طريق إضافة بعض وظائف الإكمال التلقائي الذكية ، أو العداد ، أو المعاينة الجانبية؟

1. اختبر مع المطورين

كلما مر الوقت في التطوير ، زادت تكلفة إصلاح المشكلة. مرة أخرى ، فكر في مدى ارتباط جميع القرارات بتطوير المنتج ؛ كلما كان المنتج أكثر دقة ، زادت الحاجة إلى التراجع عن القرارات ، الأمر الذي يكلف الوقت والموارد. لذلك ، تحديد المشكلات وحلها مبكرًا من منظور الأعمال ومن منظور التصميم والتطوير.

لا يمكنك تصحيح فكرة ما ، لذلك يجب إجراء الاختبار الأولي أثناء الإنتاج على النماذج الأولية. إذن ، المختبرين الأوائل في Mail.ru هم المطورون الذين يكتبون الكود بالفعل. تشجع الشركة موظفيها على استخدام المنتج للاتصال الداخلي (وحتى الاتصالات الخاصة) ؛ لذلك ، يمكن اعتبار المطورين مستخدمين فاضحين للمنتج.

الخطوة الأولى واضحة تمامًا: تصميم وبناء الميزة ، ثم اختبارها محليًا ومراجعتها ونشرها على الخادم المرحلي. هذا هو المكان الذي يأتي فيه اختبار ضمان الجودة ، مع أدوات شاملة ومتسابقي المهام الذين يحاولون تعطل الميزة والواجهة ، والتي يحتمل أن تكون مؤتمتة باستخدام أدوات اختبار القرود مثل Gremlins.js.

تتم مراقبة النتائج ثم إعادة إدخالها في حلقة التغذية الراجعة للتكرار التالي للميزة. في مرحلة ما ، سيشعر المطورون بثقة تامة في التصميم: يبدو أن التغيير يعمل كما هو متوقع ، وقد تم استيفاء المتطلبات. وذلك عندما يبدأ اختبار المستخدم الحقيقي.

2. اختبر مع مستخدمين حقيقيين في بيئة خاضعة للسيطرة

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

ومع ذلك ، لا يتم اختبار الميزة الجديدة فقط ؛ هدف اختبار قابلية الاستخدام هو التأكد من أن الميزة الجديدة لا تؤثر على المكونات الهامة للواجهة ، وهذا هو سبب إكمال المستخدمين للمهام الروتينية ، مثل كتابة رسالة وفتح رسائل البريد الإلكتروني والرد عليها وتصفحها في صندوق الوارد الخاص بهم. إذا تم فهم كل من الميزة الجديدة والميزات القديمة جيدًا ، فيمكن للعملية المضي قدمًا.

3. اختبر مع المستخدمين على مستوى الشركة

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

مع الاختبار ، لا يوجد فرق كبير بشكل خاص بين المستخدمين في الأقسام "البعيدة" داخل الشركة والمستخدمين في البرية. حتى المستخدمون الداخليون لا يعرفون ما هي التغييرات التي يجب توقعها أو معرفة بالضبط ما تفعله الميزة أو كيف من المفترض أن تعمل أو تبدو. الاختلاف الوحيد هو أنه يمكن مطالبة الزملاء بإرسال ملاحظات أو ترك تعليق بسرعة. هذا عندما يتم تقديم استمارات التصويت. لا يمكن للمختبرين اللعب بالميزة فحسب ، بل يمكنهم أيضًا إضافة تعليق والتصويت بالإيجاب أو التصويت ضدها. يجب موازنة التصويت مقابل إستراتيجية المنتج ومتطلبات العمل ، ولكن إذا وجد المستخدمون بوضوح ميزة غير مفيدة أو مفيدة ، فهذه طريقة بسيطة وفعالة لجمع التعليقات واختبار ما إذا كان المنتج يعمل كما هو متوقع.

4. اختبار مع مختبري بيتا

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

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

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

5. اختبر مع المستخدمين الذين يختارون الاشتراك يدويًا

حتى هذه النقطة ، تضمنت الاختبارات عددًا يمكن التحكم فيه من المستخدمين والتكوينات وتقارير الاختبار. ومع ذلك ، فإن تنوع المستخدمين والأنظمة والتكوينات في البرية ، بما في ذلك نظام التشغيل والمتصفح والمكونات الإضافية وإعدادات الشبكة وبرامج مكافحة الفيروسات والتطبيقات الأخرى المثبتة محليًا ، يمكن أن يكون أكثر صعوبة من حيث الحجم.

في حالة Mail.ru ، تتمثل الخطوة التالية في طرح الميزة في واجهة مباشرة ، خلف علامة ، وإرسال بريد إلكتروني إلى هذه الشريحة الأكبر من المستخدمين النشطين ، وتقديم الميزة الجديدة ودعوتهم لتنشيطها على في الواجهة ، عادةً باستخدام زر "تحديث" لامع. لقياس قيمة الميزة للمستخدمين الفعليين ، يستخدم الفريق مرة أخرى نظام التصويت ، مع بعض المطالبات هنا وهناك ، بشكل أساسي يسأل المستخدمين عما إذا كانوا يجدون الميزة مفيدة أو مفيدة. لاحظ أن الاختلاف بين هذا المستوى والمستوى السابق هو أن الاشتراك اليدوي يتضمن جمهورًا أكبر بكثير - وكثير منهم ليسوا تقنيين على الإطلاق ، على عكس مختبري الإصدارات التجريبية.

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

6. انقسام الاختبار والتحقق من الاحتفاظ

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

للتأكد من أنك لا تكسر عادات المستخدمين السلبيين ، يمكنك تقسيم الاختبار مع ثلاث شرائح صغيرة من المستخدمين وقياس الاحتفاظ . بعد كل شيء ، تريد التأكد من أن الإصدار الجديد يعمل على الأقل مثل الإصدار السابق. حدد النشاط الأكثر أهمية في الواجهة وقياس ليس فقط مقدار الوقت الذي يقضيه المستخدمون عليه قبل وبعد طرحه ، ولكن أيضًا مقدار الوقت الذي يمر حتى عودتهم. في حالة Mail.ru ، يستلزم الاحتفاظ المستخدمين التحقق من بريدهم الإلكتروني وإنشاء رسالة. كلما عاد المستخدم كثيرًا ، زاد معدل الاحتفاظ به ، وهو مؤشر على تجربة مستخدم أفضل.

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

7. حرر ببطء وتدريجي

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

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

8. قياس التداعيات

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

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

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

خاتمة

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

من الواضح أن النشر ليس عملية خطية . طوال العملية ، قد تحتاج إلى التراجع خطوتين للمضي قدمًا خطوة واحدة - حتى تحصل أخيرًا على مرشح الإصدار. قد يبدو سير العمل المغطى أعلاه بطيئًا جدًا وغير رشيق بشكل خاص ، لكنك تقلل بشكل كبير من مخاطر مواجهة المستخدمين فجأة لمشكلة غير متوقعة والحصول على تجربة رديئة نتيجة لذلك. في بعض الحالات ، قد يكون الأمر يستحق كل هذا العناء.