Usa tu producto como un cliente que no tiene nada adentro
Antes de publicar una versión de una herramienta de gestión de ventas, recorrimos cada página dos veces: como una empresa nueva sin datos y como una ya establecida. Las pruebas automáticas estaban en verde. El recorrido igual encontró resultados sobre la nada, números que no coincidían y textos que mandaban a la gente al lugar equivocado.
El equipo que construye un producto casi nunca lo ve como lo ve un cliente nuevo. Nuestras cuentas están llenas de datos, nuestras costumbres nos llevan por fuera de las partes ásperas, y la cuenta de demostración se armó para verse bien. Un cliente en su primer día tiene una pantalla vacía y ninguna costumbre.
Antes de publicar una versión reciente de una herramienta de gestión de ventas que construimos, recorrimos cada página del cliente dos veces: una como empresa nueva sin nada adentro, y otra como empresa ya establecida. Luego las dos otra vez en una pantalla del tamaño de un teléfono. Todas las pruebas automáticas habían pasado. El recorrido igual encontró más de treinta cosas por arreglar.
Si lideras el equipo: qué preguntar
- ¿Cuándo fue la última vez que alguien se registró como cliente nuevo y usó todas las páginas?
- ¿Qué muestra cada pantalla cuando todavía no hay datos?
- Después de la última publicación, ¿quién abrió el producto en producción y revisó que las tareas programadas estén corriendo?
Resultados sobre la nada
Estos son los que un cliente nuevo encuentra en el primer minuto.
- El resumen de una cuenta nueva mostraba como mejor puntaje semanal menos infinito por ciento.
- Un reporte semanal entregaba un trofeo verde por un conteo de cero, y le advertía a una empresa en su primer día que su actividad comercial se había detenido.
- Una página que compara dos juegos de puntajes calificaba qué tanto coincidían antes de que se hubiera medido nada.
Nada de esto es una caída del sistema. Cada cálculo corrió bien con los números que recibió. No recibió nada, y nadie había decidido qué debía decir la pantalla en ese caso. Cada uno es ahora una frase clara de lo que realmente hay.
Números que no coincidían entre sí
- Las fechas de distintas páginas diferían en una hora, porque unas páginas usaban el reloj del servidor y otras el del navegador.
- Una cifra de “la semana anterior” contaba todo lo que la persona había hecho en su vida.
- Una página interna mezclaba cifras de toda la empresa con cifras de una sola cuenta, sin decir cuál era cuál.
Un usuario que ve dos fechas distintas deja de confiar en las dos, y después en el resto de la página. Ahora todas las fechas pasan por un solo formateador, y la compilación falla si una página nueva formatea las suyas.
Textos que mandaban a la gente al lugar equivocado
- Una página señalaba un ajuste que no existe.
- Otra decía que una revisión nocturna había salido limpia cuando no había corrido.
- Una tercera le pedía a un equipo que ya había hecho el trabajo que fuera a hacerlo.
Un texto así se escribe temprano, cuando la función es un plan, y nadie lo vuelve a leer cuando la función cambia.
Por qué las pruebas no encontraron nada de esto
Las pruebas automáticas responden la pregunta que se les hizo: con esta entrada, ¿el código devuelve aquella salida? Lo hacía, siempre. Nadie había preguntado “¿qué debería ver aquí una persona que no tiene nada?” ni “¿esta frase todavía describe el producto?”. Esas preguntas solo aparecen cuando alguien mira la pantalla.
Por eso el recorrido es ahora una etapa obligatoria de cada publicación, al lado de las automáticas: cada página como cuenta vacía, cada página como cuenta llena, en computadora y en teléfono. Cuando un hallazgo puede convertirse en un control automático, se convierte. El formateador de fechas es un ejemplo. Mirar lo sigue teniendo que hacer alguien.
Y luego otra vez en el producto en producción
Apenas salió la versión entramos a producción y la recorrimos ahí. Todas las páginas cargaron y nada estaba roto. El recorrido igual encontró lo más importante de la semana: algunas tareas programadas no estaban haciendo su trabajo en el sistema real. Un resumen llevaba semanas sin generarse. Una sincronización con otro sistema nunca se había programado ahí, mientras su página de ajustes decía que corría cada pocas horas.
Ningún ambiente de pruebas podía mostrar eso. El código estaba bien y las páginas se dibujaban. Solo el sistema real sabía que las tareas no habían corrido. Es de la misma familia que un control que reporta “todo bien” cuando no pudo revisar.
Cómo hacerlo en tu propio producto
- Crea una cuenta nueva como lo haría un cliente. No una copia de una cuenta de pruebas. Regístrate, y no toques nada más antes.
- Abre todas las páginas antes de agregar datos. Anota cada número, insignia, gráfico y frase que afirme algo. Sin datos, cada una de esas afirmaciones es sospechosa.
- Agrega un solo registro y mira otra vez. Uno es el otro caso para el que nadie diseña: promedios, tendencias y “comparado con la semana pasada” se comportan raro.
- Hazlo en un teléfono. Uno de verdad, si puedes.
- Lee cada instrucción y síguela al pie de la letra. Si nombra un botón o un ajuste, ve y búscalo.
- Después de cada publicación, repite la versión corta en producción, y revisa que todo lo programado tenga una ejecución reciente.
Toma unas horas. En esta versión encontró más problemas que cualquier otra etapa.
Dónde encaja
El estado vacío es una de las cosas que un prototipo se salta, porque un prototipo siempre se muestra con datos adentro. Encontrarlas antes que los clientes es buena parte de llevar un producto de prototipo a producción. Una ronda anterior del mismo tipo de revisión a mano en este producto está en Prueba los caminos que nunca han corrido.
Este artículo se basa en un proyecto real. Datos del cliente reservados; cada cifra proviene de los datos del propio cliente.
Leer el caso de estudio completo →