Cómo implementar nuevas funciones sin perjudicar a los usuarios leales

“Sé ágil; liberación anticipada; liberar a menudo.” Conocemos el ejercicio. Pero, ¿ es estratégicamente inteligente seguir implementando funciones con frecuencia? Especialmente una vez que un producto que está creando alcanza cierto tamaño, probablemente no quiera arriesgar la integridad de su aplicación con cada nueva versión menor.

Lo peor que le puede pasar a su producto es que los usuarios leales, los clientes que han estado usando esa pequeña característica constantemente durante años, de repente no puedan usarla de la misma manera conveniente. El cambio puede empoderar más a los usuarios, pero la experiencia se vuelve menos sencilla. La frustración y la ansiedad ingresan a las redes sociales de manera rápida y repentina, y la presión sobre el servicio de atención al cliente para responder de manera significativa y a tiempo aumenta con cada minuto. Por supuesto, no queremos implementar nuevas funciones solo para darnos cuenta de que en realidad dañan a los usuarios leales.

Lectura adicional en SmashingMag: Enlace

• Cómo comenzamos a lanzar funciones el doble de rápido
• La lista de verificación de lanzamiento del sitio web: 15 verificaciones esenciales antes de lanzarlo
• Un enfoque centrado en el usuario para el diseño web para dispositivos móviles
• Cómo lanzar cualquier cosa

Podemos evitar esto siendo más estratégicos al lanzar nuevas versiones de nuestros productos. En este artículo, analizaremos una estrategia para que los diseñadores de productos y los ingenieros de front-end prueben e implementen una función a fondo antes de lanzarla a toda la base de usuarios, y cómo evitar que surjan problemas de UX en el futuro.

Antes de sumergirnos en una estrategia de prueba real, retrocedamos y examinemos los conceptos erróneos comunes sobre cómo se diseña, construye y eventualmente implementa una nueva función.

Conceptos erróneos sobre nuevas características

Cada vez que se diseña una nueva característica para un producto existente, el enfoque principal suele ser cómo se debe integrar exactamente en la interfaz existente. Para lograr la coherencia, los diseñadores a menudo analizamos los patrones existentes y aplicamos el lenguaje de diseño establecido para que la nueva función se adapte bien a la interfaz de usuario. Sin embargo, los problemas a menudo ocurren no porque los componentes no funcionen juntos visualmente, sino porque resultan confusos o ambiguos cuando se combinan de formas inesperadas .

Tal vez la copia de la interfaz es ambigua en áreas relacionadas pero distantes del sitio web, o el resultado de dos funciones que se usan activamente al mismo tiempo tiene sentido desde una perspectiva técnica pero no coincide con las expectativas del usuario o tiene implicaciones importantes en el rendimiento y daña la UX. .

De hecho, en el diseño, son estas numerosas combinaciones las que son tan difíciles de predecir y revisar a fondo. Una forma de abordar el problema mientras ya está en el proceso de diseño es considerar los valores atípicos: casos de uso en los que es más probable que las cosas salgan mal. ¿Cómo se vería un perfil de usuario si el nombre del usuario es muy largo? ¿Sigue siendo evidente una descripción general de los correos electrónicos no respondidos cuando se utilizan una docena de etiquetas de bandeja de entrada? ¿Tendría sentido un nuevo filtro para los usuarios que acaban de registrarse y solo tienen algunos correos electrónicos en su bandeja de entrada?

Diseño de valores atípicos: la pila de la interfaz de usuario

¿Cómo podemos diseñar exactamente los valores atípicos una vez que los hemos identificado? Una buena estrategia es estudiar los diferentes estados de la interfaz de usuario. La "pila de interfaz de usuario", una idea presentada por Scott Hurff, es versátil y complicada, y cuando diseñamos nuestras interfaces, por lo general no es suficiente para crear una maqueta de píxeles perfectos en Photoshop, Sketch o HTML y CSS, tenemos que considerar varios casos y estados de borde: el estado en blanco, el estado de carga, el estado parcial, el estado de error y el estado ideal. Estos no son tan sencillos como podríamos pensar.

El estado en blanco no tiene por qué estar vacío: podríamos usar trabajadores de servicio para brindar una mejor experiencia fuera de línea a los visitantes regulares. El estado parcial no tiene que romperse: podríamos mejorar la experiencia con imágenes rotas y JavaScript roto a través de una mejora progresiva.

El estado ideal puede diferir significativamente de nuestras maquetas de "resultado perfecto", debido a las preferencias personalizadas del usuario y la elección del navegador del usuario; es posible que algunos contenidos y fuentes web no se muestren debido a la configuración de un navegador, por ejemplo.

Entonces, el panorama es, como siempre, complejo, intrincado e impredecible, y no podemos hacer que el riesgo de que las cosas salgan mal sea insignificante, pero esto no significa que no podamos minimizar el riesgo de manera efectiva. Al explorar los valores atípicos y toda la pila de la interfaz de usuario desde el principio, podemos evitar problemas comunes de UX en la etapa inicial de diseño. Sin embargo, no se vuelve más fácil en el aspecto técnico.

El efecto mariposa en el despliegue

Incluso los cambios menores tienden a provocar reacciones en cadena, introduciendo errores en áreas y situaciones que parecen no tener ninguna relación. La razón principal de esto es la gran cantidad de variables que influyen en la experiencia del usuario pero que están fuera de nuestro control. Conocemos nuestras maneras con los navegadores, pero eso no significa que sepamos más sobre el contexto en el que un usuario elige ver el sitio web que hemos diseñado tan incansable y minuciosamente.

Ahora, aunque los cambios menores como el relleno de un botón o un área de texto progresivamente mejorada pueden no parecer gran cosa, tendemos a subestimar el impacto de estos pequeños cambios o funciones brillantes a gran escala. Cada vez que tomamos una decisión de diseño o desarrollo, ese cambio tiene algún efecto en el sistema complejo que estamos construyendo, principalmente porque los componentes que estamos construyendo nunca existen de forma aislada.

La realidad es que nunca creamos simplemente un botón, ni escribimos simplemente una nueva función de JavaScript: los botones y las funciones pertenecen a una familia de componentes o bibliotecas, y todos funcionan dentro de una determinada configuración, y están inevitablemente conectados a otros. partes del sistema por sus propiedades o por su alcance o por su nombre o por las convenciones no escritas del equipo.

Estas conexiones "silenciosas", apenas perceptibles, son la razón por la cual implementar funciones es difícil y por qué predecir las consecuencias de largo alcance de un cambio a menudo resulta ser un ejercicio de visión aguda. Por eso es una buena idea evitar dependencias innecesarias en la medida de lo posible, ya sea en CSS o JavaScript; no te ayudarán con el mantenimiento o la depuración, especialmente si confías en una biblioteca que no entiendes completamente. .

Afortunadamente, para comprender mejor el impacto de un cambio, podemos usar recursos como las herramientas de desarrollo de un navegador. Podemos medir el alcance de un selector o el alcance de una función de JavaScript y, a veces, puede ser una buena idea volver a él durante el desarrollo para mantener el alcance del cambio lo más local y mínimo posible.

Esto es útil, pero también es solo una parte de la historia. Hacemos suposiciones, consciente e inconscientemente, en función de nuestra propia experiencia con la interfaz y nuestros propios hábitos, a menudo olvidando que las suposiciones pueden (y, por lo tanto, variarán ) variar significativamente de un usuario a otro. La mayoría de las aplicaciones tienen solo una interfaz, pero esta interfaz o sus configuraciones pueden tener docenas de estados, con vistas que cambian según la configuración y las preferencias del usuario.

Piense en paneles con tarjetas que se pueden personalizar (software de análisis), clientes de correo con vistas "compactas", "cómodas" y "detalladas" (Gmail), una interfaz de reserva que cambia para los clientes registrados y para los invitados, una experiencia de lectura. para personas que usan un bloqueador de anuncios o un filtro antivirus agresivo. El efecto mariposa tiene un impacto en algo más que la base del código; todos esos factores externos también influyen, y probarlos, a diferencia de las pruebas unitarias o el control de calidad en general, es muy difícil porque a menudo ni siquiera sabemos contra qué probar.

Validación de funciones y máximo local

Podemos usar diagnósticos y métricas para determinar qué cambios se deben realizar, pero siguiendo solo los datos, es posible que termine estancado en lo que tendemos a llamar un "máximo local", un estado de la interfaz con un diseño lo suficientemente bueno pero que carece por completo de innovación porque siempre sigue iteraciones lógicas y predecibles. Cuando trabajamos en un proyecto y exploramos los datos, tendemos a agrupar las características en los siguientes cuatro cubos:

• Características rotas. . Funciones que parecen estar rotas o son ineficientes; obviamente, debemos corregirlas;
• Funciones no utilizadas. . Funciones que funcionan según lo previsto pero que rara vez se usan, a menudo una señal de que deben eliminarse o necesitan innovación desesperadamente;
• Características de uso inesperado. . Características que se utilizan de una manera que es extremadamente diferente de lo que sus creadores imaginaron originalmente: un buen candidato para un refinamiento lento y continuo;
• Características del caballo de batalla. . Funciones que se usan mucho y parecen estar funcionando según lo planeado, en cuyo caso nos preguntamos si hay alguna forma de mejorar aún más su UX explorando tanto el proceso iterativo lento como conceptos innovadores completamente diferentes en paralelo.

Los dos primeros cubos son fundamentales para mantener una interfaz funcional y utilizable, mientras que los dos últimos son fundamentales para mantener a los usuarios comprometidos y encantados. Idealmente, queremos alcanzar ambos objetivos al mismo tiempo, pero las restricciones de tiempo, presupuesto y equipo tienen la ventaja.

Aún así, una vez que se elige una nueva iteración o una nueva idea, puede ser tentador comenzar a diseñar o construir la nueva función de inmediato. Pero incluso antes de pensar en cómo encajaría una función en una interfaz existente, es una buena estrategia validar la idea primero, con un prototipo rápido y una investigación del usuario. Una forma común de lograr esto es mediante un proceso iterativo rápido, como el sprint de diseño de Google Ventures. Al iterar dentro de un par de días, puede identificar cómo se debe implementar la nueva característica y/o si es útil en la forma en que la había imaginado inicialmente.

Con los sprints de diseño, exponemos la idea a la investigación de usabilidad desde el principio. En la metodología de Google Ventures, probarías un diseño con cinco usuarios al día; luego, iteraría y pasaría por otra ronda de pruebas del nuevo diseño. La razón por la que todos los mismos usuarios están involucrados es porque si prueba un diseño diferente con cada usuario ese día, no tendrá datos válidos para saber qué elementos deben cambiar. Necesita algunos usuarios para validar una iteración de diseño.

Aplicamos un modelo ligeramente diferente en nuestros sprints. Cuando comenzamos a trabajar en una nueva función, una vez que se construye un primer prototipo temprano, reunimos a los diseñadores, desarrolladores y el equipo de UX en la misma sala, invitamos a usuarios reales a probar y luego iterar en un cronograma ajustado. El primer día, los primeros evaluadores (dos o tres personas) pueden programar una entrevista de 30 minutos a las 9:00 a. m., el segundo grupo a las 11:00 a. m., el siguiente a las 2:00 p. m. y el último uno alrededor de las 4:00 pm. Entre las entrevistas con los usuarios, tenemos "ventanas de tiempo abiertas", en las que iteramos en el diseño y el prototipo hasta que en algún momento tengamos algo viable.

La razón de esto es que, al principio, queremos explorar rápidamente direcciones completamente diferentes, a veces incluso opuestas; una vez que recopilamos comentarios sobre diferentes interfaces, podemos converger hacia lo que se siente como la interfaz de "máximo absoluto" . Podemos obtener comentarios muy diversos sobre iteraciones de diseño muy diversas más rápido de esta manera. La retroalimentación se basa principalmente en tres factores: mapas de calor que registran los clics de los usuarios, el tiempo que los usuarios necesitan para completar una tarea y cuán placentera es la experiencia para ellos. Más adelante en la semana, seguimos trabajando constantemente con una mayor cantidad de usuarios, muy parecido a lo que hace Google, validando permanentemente el nuevo diseño a medida que avanzamos.

Hasta ahora todo bien, pero a veces una característica nueva aparentemente innovadora choca con una característica existente, y tener ambas en la misma interfaz desordenaría el diseño. En este caso, exploramos si una de las opciones podría considerarse una extensión de la otra. Si pudiera ser, empezamos por reiterar su funcionalidad y el diseño. Ahí es cuando tenemos que elegir un rediseño radical o un cambio incremental. El último es menos riesgoso y mantendrá un patrón de interacción familiar para los usuarios, mientras que el primero es necesario si los cambios críticos son imposibles de lograr de otra manera o si las ganancias de los cambios incrementales serían demasiado superficiales.

En cualquier caso, es fundamental mantener el enfoque en toda la experiencia del usuario del producto, en lugar de en el valor de una sola función dentro de ese producto. Y una vez que haya elegido la característica y haya diseñado y construido el primer prototipo, es hora de probar.

Los ocho niveles de prueba

Bueno, entonces, ¿cómo podemos prevenir de manera efectiva que los errores y las fallas se filtren en un entorno real en vivo? ¿Cuántas verificaciones, revisiones y pruebas ejecutamos antes de que se implemente una característica? ¿Y en qué secuencia ejecutamos estas pruebas? En otras palabras, ¿cómo sería la estrategia definitiva para implementar funciones?

Andrew Sumin, jefe de desarrollo de Mail.ru, un importante proveedor de correo electrónico en Rusia, propuso una de las mejores estrategias para implementar funciones. La estrategia no sería aplicable a todos los proyectos, pero es un enfoque razonable y completo para las empresas que ofrecen productos medianos y grandes a miles de clientes.

Veamos la estrategia en detalle y cubramos los ocho pasos del despliegue de una función, cubriendo el proceso de desarrollo de productos de Mail.ru:

1. prueba con desarrolladores,
2. prueba con usuarios reales en un entorno controlado,
3. prueba con usuarios de toda la empresa,
4. prueba con probadores beta,
5. prueba con usuarios que opten manualmente,
6. prueba dividida y retención de cheques,
7. liberar lenta y gradualmente,
8. medir las secuelas.

En el caso de Mail.ru, la característica más importante para mantener intacta sin importar lo que está redactando un mensaje (obviamente). Esa es la parte más utilizada de la interfaz, y permitir que no esté disponible o que funcione incorrectamente incluso por segundos sería absolutamente imposible. Entonces, ¿qué pasaría si quisiéramos ampliar la funcionalidad de un área de texto, tal vez agregando algunas funciones inteligentes de autocompletado, un contador o una vista previa lateral?

1. Prueba con desarrolladores

Cuanto más tiempo pasa en el desarrollo, más caro se vuelve solucionar un problema. Nuevamente, piense en cuán conectadas están todas las decisiones en el desarrollo de productos; cuanto más refinado es el producto, más decisiones hay que revertir, lo que cuesta tiempo y recursos. Por lo tanto, identificar y resolver problemas desde el principio es importante tanto desde una perspectiva comercial como desde una perspectiva de diseño y desarrollo.

Sin embargo, no se puede depurar una idea, por lo que las pruebas iniciales deben realizarse durante la producción, en los primeros prototipos. Los primeros evaluadores en Mail.ru, entonces, son los desarrolladores que realmente escriben el código. La empresa anima a sus empleados a utilizar el producto para la comunicación interna (e incluso para la comunicación privada); por lo tanto, los desarrolladores podrían considerarse usuarios incondicionales del producto.

El primer paso es bastante obvio: diseñe y cree la función, y luego pruébela, revísela e implemente localmente en el servidor de prueba. Aquí es donde entran las pruebas de control de calidad, con herramientas integrales y ejecutores de tareas que intentan bloquear la función y la interfaz, potencialmente automatizadas con herramientas de prueba mono como Gremlins.js.

Los resultados se monitorean y luego se retroalimentan al circuito de retroalimentación para la próxima iteración de la función. En algún momento, los desarrolladores se sentirán bastante seguros con la compilación: el cambio parece estar funcionando como se esperaba y se han cumplido los requisitos. Ahí es cuando entran en juego las pruebas de usuarios reales.

2. Prueba con usuarios reales en un entorno controlado

Cuando se termina el primer prototipo funcional, la función se prueba con usuarios reales en entrevistas. Se invita a los clientes a completar tareas y, mientras lo hacen, el equipo de UX supervisa los callejones sin salida y los problemas que surgen y los aborda en el acto.

Sin embargo, no solo se está probando la nueva función; el objetivo de la prueba de usabilidad es garantizar que la nueva función no afecte los componentes críticos de la interfaz, razón por la cual los usuarios completan tareas rutinarias, como redactar un mensaje y abrir, responder y buscar correos electrónicos en su bandeja de entrada. Si tanto la característica nueva como las antiguas se entienden bien, el proceso puede continuar.

3. Prueba con usuarios de toda la empresa

Obviamente, los comentarios de la prueba de usabilidad incitan a los desarrolladores a introducir cambios, que luego retroalimentan a los evaluadores de usabilidad, yendo y viniendo hasta que el resultado parece tener valor para una audiencia más amplia. Entonces, el siguiente paso es que la función se destaque dentro de la empresa: se envía un correo electrónico a toda la empresa animando a todos los colegas a verificar la función y enviar informes, errores y sugerencias en un rastreador.

Con las pruebas, no hay una diferencia particularmente grande entre los usuarios en departamentos "remotos" dentro de la empresa y los usuarios en general. Incluso los usuarios internos no saben qué cambios esperar ni saben exactamente qué hace una función o cómo se supone que debe funcionar o verse. La única diferencia principal es que se puede solicitar a los colegas que envíen comentarios rápidamente o dejen un comentario. Es entonces cuando se introducen los formularios de votación. Los evaluadores no solo pueden jugar con la función, sino también agregar un comentario y votarlo a favor o en contra. La votación debe sopesarse con la estrategia del producto y los requisitos comerciales, pero si los usuarios claramente encuentran una característica inútil o útil, esa es una forma simple y efectiva de recopilar comentarios y probar si el producto funciona como se esperaba.

4. Prueba con probadores beta

Si una característica ha pasado una verificación técnica, una verificación de usabilidad y una revisión dentro de la empresa, el siguiente paso lógico es presentarla a algunos segmentos de la audiencia. Sin embargo, en lugar de implementarlo en un segmento aleatorio de usuarios, el equipo envía una función para su revisión entre los probadores beta, usuarios que han optado por participar en las pruebas y enviar comentarios sobre las funciones experimentales. Pueden votar a favor o en contra de una característica, así como informar errores y confirmar fragmentos de código.

Pero, ¿cómo elige los probadores beta apropiados? Bueno, si desea alentar a los evaluadores a romper la interfaz, puede centrarse en usuarios leales avanzados con habilidades técnicas: usuarios que podrían proporcionar detalles técnicos sobre un error si es necesario, y usuarios que conocen la interfaz existente lo suficientemente bien como para ser capaz de anticipar problemas que otros usuarios puedan tener.

Sin embargo, necesita criterios para determinar si un usuario es lo suficientemente avanzado para ser un probador beta. En el caso de un cliente de correo electrónico, podría ser alguien que usa Chrome o Firefox (es decir, sabe cómo cambiar su navegador predeterminado), que ha creado más de tres carpetas en su bandeja de entrada y que también ha instalado la aplicación móvil.

5. Prueba con usuarios que se inscriben manualmente

Hasta este punto, las pruebas han involucrado una cantidad manejable de usuarios, configuraciones e informes de prueba. Sin embargo, la diversidad de usuarios, sistemas y configuraciones, incluidos el sistema operativo, el navegador, los complementos, la configuración de red, el software antivirus y otras aplicaciones instaladas localmente, puede ser un poco más abrumadora en escala.

En el caso de Mail.ru, el siguiente paso es implementar la función en una interfaz en vivo, detrás de una bandera, y enviar un correo electrónico a este segmento más grande de usuarios activos, presentando la nueva función e invitándolos a activarla en su propio en la interfaz, generalmente con un brillante botón "Actualizar". Para medir el valor de la función para los usuarios reales, el equipo nuevamente usa un sistema de votación, con algunas indicaciones aquí y allá, básicamente preguntando a los usuarios si encuentran la función útil o útil. Tenga en cuenta que la diferencia entre este nivel y el nivel anterior es que la suscripción manual involucra a una audiencia mucho más grande, muchos de los cuales no son técnicos en absoluto, a diferencia de los probadores beta.

Por lo tanto, el tiempo y la coordinación son importantes . Probablemente no elegiría un día aleatorio para enviar el correo electrónico a los usuarios activos, porque querrá que el equipo de atención al cliente y los desarrolladores estén disponibles cuando comience a llegar el flujo de informes de errores. Es por eso que el correo electrónico se envía a el comienzo de la semana, cuando todos (o la mayoría) de los desarrolladores estén disponibles y el equipo de soporte esté listo para entrar en acción, después de haber sido informado y conectado activamente con los desarrolladores a través de Skype o Slack. En una empresa más pequeña, incluso podría hacer que los desarrolladores se sentaran durante unas horas en los escritorios de soporte para llegar al núcleo de un problema más rápido al hablar directamente con los clientes.

6. Prueba dividida y retención de cheques

En los pasos hasta el momento, a excepción de las pruebas de usabilidad, todos los evaluadores han utilizado la nueva función de forma voluntaria. Sin embargo, si habilita la función de forma predeterminada, de repente los usuarios tendrán que usarla, y este es un tipo de grupo muy diferente, uno que no hemos probado en absoluto.

Para asegurarse de no romper los hábitos de los usuarios pasivos, puede dividir la prueba con tres pequeños segmentos de usuarios y medir la retención . Después de todo, desea asegurarse de que una nueva versión funcione al menos tan bien como la anterior. Identifique la actividad más importante en la interfaz y mida no solo cuánto tiempo pasan los usuarios en ella antes y después del lanzamiento, sino también cuánto tiempo pasa hasta que regresan. En el caso de Mail.ru, la retención implica que los usuarios revisen su correo electrónico y redacten un mensaje. Cuanto más a menudo regresa un usuario, mayor es la retención, lo que es un indicador de una mejor UX.

Cada segmento obtiene una vista ligeramente diferente , lo que nos permite probar cómo mostrar la nueva función a todos los usuarios más adelante. Para el primer segmento, agregamos la nueva característica y brindamos un tutorial sobre cómo usarla. Para el segundo segmento, solo agregamos la nueva función. Para el tercer segmento, podríamos dejar la característica como está. Para todos estos segmentos, podríamos implementar el cambio al mismo tiempo, seleccionar un marco de tiempo razonable para ejecutar la prueba, medir la retención y luego comparar los resultados. Cuanto mayor sea la retención de un segmento, más probable es que el diseño se promocione a todos los usuarios más adelante.

7. Liberar lenta y gradualmente

Si una característica ha llegado hasta este punto, probablemente ya funcione bien para un gran segmento de la audiencia. Aquí es cuando podría implementarlo gradualmente para todos los usuarios, con un aviso de votación para recopilar comentarios. Si los comentarios son en su mayoría positivos, puede seguir implementando la función y eventualmente se convertirá en una parte integral de la interfaz. De lo contrario, evaluaría los comentarios y regresaría al laboratorio para la siguiente iteración.

Sin embargo, implementar la función no es suficiente: debe comunicarse a los usuarios. Una forma común de hacerlo es a través del correo electrónico y las redes sociales. Aún así, un tutorial rápido que explique el valor de la función en escenarios de la vida real también podría ser útil. Además, no olvides integrar un buzón de sugerencias para recopilar comentarios de inmediato.

8. Mide las consecuencias

Una vez que se implementó la función, podemos monitorear cómo funciona y probar diferentes métodos para llamar la atención sobre ella, de modo que los usuarios puedan realizar sus tareas de manera más eficiente. Puede realizar un seguimiento de las tareas más comunes o las páginas más visitadas y luego mostrar una pequeña nota en línea recomendando una forma un poco más inteligente y rápida para que el usuario logre su objetivo, y luego medir si el usuario prefiere esta nueva función o el método habitual.

No olvide enviar los comentarios a todo el equipo, no solo a los desarrolladores o diseñadores, para que estén motivados y comprometidos y vean cómo las personas usan una función que inicialmente no era más que una idea aproximada. Nada es más motivador que ver a personas felices y encantadas usando una aplicación exactamente de la manera que la imaginó, o de maneras completamente diferentes. También nutrirá el crecimiento de las funciones posteriores del equipo.

El proceso de revisión parece complejo y minucioso, pero a veces solo el tiempo y una amplia red de pruebas de usuarios descubrirán un problema. Por ejemplo, si un cambio afecta la apariencia general de los mensajes entrantes, ninguna prueba unitaria podría descubrir las dificultades que podrían encontrar los usuarios de software de asistencia. En una interfaz de correo, ¿qué desea que lea primero el dispositivo de accesibilidad: la fecha, el remitente, la línea de asunto o el mensaje en sí? La forma en que reorganiza las columnas en la descripción general puede cambiar la forma en que los usuarios eligen acceder a la información; por lo tanto, permitirles desactivar la nueva función también sería fundamental.

Conclusión

Entonces, ¿cómo es una estrategia de despliegue? Puede comenzar explorando el gráfico de dependencias para comprender el alcance de su cambio. Luego, podría probar la función con desarrolladores y con usuarios reales en un entorno controlado. Luego, puede pedirles a sus colegas que revisen la función antes de enviarla a un grupo selecto de probadores beta. Finalmente, puede hacer que la función esté disponible como una opción para los usuarios. Y, antes de habilitar la función para todos, puede ejecutar una prueba dividida para descubrir la mejor manera de presentar la función y luego medir las tasas de retención para tareas críticas.

Obviamente, el despliegue no es un proceso lineal . A lo largo del proceso, es posible que deba retroceder dos pasos para avanzar un paso, hasta que finalmente tenga un candidato de lanzamiento. El flujo de trabajo cubierto anteriormente puede parecer bastante lento y no particularmente ágil, pero minimiza drásticamente el riesgo de que los usuarios se enfrenten repentinamente a un problema inesperado y, como resultado, tengan una experiencia inferior. En algunas situaciones, podría valer la pena.