La reunión de aprobación de un prototipo de alta fidelidad es engañosa. Los lienzos se ven hermosos, todos asienten con la cabeza, alguien dice "queda genial" y el proyecto avanza. Semanas más tarde, el desarrollo se estanca debido a preguntas que nadie hizo en esa sala: ¿qué sucede cuando la lista está vacía? ¿Qué pasa con el estado de error? ¿Y sin conexión?
La diferencia entre un prototipo que hace el trabajo y uno que oculta problemas no es la belleza. Está en el rigor de la reseña. Aprobar basándose en la apariencia es el error más común y costoso que cometen quienes trabajan con productos.
Este texto es para quienes están cerca de decidir: ¿vamos a construir esto? En lugar de explicar qué es un prototipo de alta fidelidad, ofrece una lista de verificación de revisión, las preguntas que separan un prototipo listo para convertirse en un producto de uno que generará reelaboración.
Por qué es arriesgado aprobar basándose en la apariencia
La alta fidelidad engaña al cerebro. Cuando algo parece real, asumimos que está completo. Es un sesgo conocido: el realismo visual crea una sensación de preparación que a menudo no se corresponde con la profundidad de lo que se pensaba.
El resultado es que las decisiones importantes se vuelven invisibles. El prototipo muestra el camino feliz, el usuario hace todo bien, la conexión funciona, los datos existen. Pero el producto real vive de maneras desafortunadas: campos incorrectos, conexiones inestables, listas vacías, permisos denegados.
Un prototipo de alta fidelidad que sólo cubre el camino feliz no está listo para su aprobación. Está listo para ser cuestionado. Y el cuestionario estructurado es lo que garantiza la lista de verificación.
La tesis: la lista de verificación protege contra el optimismo
Abogo por que cada aprobación de un prototipo de alta fidelidad pase por una revisión deliberada, con preguntas fijas, por muy convincente que parezca. No por desconfianza, sino porque el optimismo es el estado natural de quien acaba de producir algo bello.
La lista de verificación no es burocracia. Es la manera de transferir la atención del "¿se ve bien?" a "¿está completo y se puede construir?". Obliga a una conversación difícil antes de comprometerse, cuando todavía es barato.
Los equipos que adoptan esta disciplina ven una caída real en el retrabajo. Los problemas que aparecerían en el sprint 3 aparecen en la revisión del prototipo, costando una conversación en lugar de rehacer.
La lista de verificación de estados y excepciones.
El primer frente de revisión es el más descuidado: los estados que no son el camino feliz.
Para cada pantalla importante, pregunte: ¿Cómo aparece vacía, sin datos? ¿Cómo aparece cargando? ¿Cómo aparece cuando hay un error? ¿Qué pasa cuando hay demasiados datos, una lista con cientos de elementos, un nombre demasiado largo, un texto que abruma el diseño?
Vaya más allá y cubra las excepciones de conexión: ¿qué ve el usuario sin conexión? ¿Qué sucede cuando la operación falla en el medio? ¿Qué pasa cuando no tiene permiso para lo que intentó hacer?
Si el prototipo no responde a estas preguntas, no está mal, está incompleto. Y aprobar un prototipo incompleto como si estuviera listo transfiere el problema al desarrollador, quien inventará respuestas bajo la presión de los plazos.
La lista de verificación de contenido y claridad
El segundo frente es el contenido. Los prototipos de alta fidelidad suelen utilizar texto cuidadosamente elegido para que encaje perfectamente. El producto real no tiene ese lujo.
Compruebe que los textos sean reales y verosímiles, no optimizados para la maquetación. Pruebe con el nombre más largo, el valor más alto, el título más largo. Confirme que las etiquetas de los botones digan lo que hacen, que los mensajes de error guíen en lugar de asustar y que los términos técnicos no se hayan filtrado a la interfaz del usuario final.
En un servicio público digital, esta preocupación es aún más grave. El ciudadano necesita entender lo que se le pregunta sin conocer el vocabulario interno de la agencia. Una etiqueta ambigua en un formulario de beneficios puede provocar errores masivos de cumplimentación y servicio cara a cara que los servicios digitales deberían haber evitado.
El contenido es parte de la experiencia, no un adorno. Un prototipo aprobado sin revisión de texto pospone un problema garantizado.
La lista de verificación de viabilidad técnica
El tercer frente requiere que la ingeniería participe en la revisión, no sólo el diseño y los negocios.
Pregunte: ¿se puede construir este flujo dentro del plazo previsto? ¿Hay interacciones que parecen simples en el prototipo pero que son costosas de implementar? ¿Los datos que aparecen en la pantalla realmente existen en el sistema o fueron inventados para que el prototipo se viera bien?
Esa última pregunta anula muchos prototipos. Es común diseñar pantallas con información que el sistema no puede proporcionar, o que dependen de integraciones que no existen. Descubrir esto en la revisión cuesta una conversación. Descubrirlo en la implementación cuesta un rediseño.
Llevar la ingeniería a la aprobación no es desconfiar del diseño. Es reconocer que la viabilidad es parte de la calidad de un prototipo. Un prototipo hermoso e imposible de construir es un documento de frustración futura.
La lista de verificación de expectativas y alcance
El cuarto frente trata sobre las personas en la sala, no sobre las pantallas.
Antes de cerrar la homologación, dejar claro: ¿qué cubre este prototipo y qué no cubre? ¿Representa la versión final o solo una parte? ¿Cuánto tiempo separa realmente este prototipo del producto entregado?
Esta alineación evita el clásico desgaste en el que las partes interesadas ven el prototipo realista y comienzan a tratarlo como un producto casi terminado. Cuando lo que se entrega no coincide con la brillantez del prototipo, la percepción es de fracaso, cuando en realidad fue solo la distancia natural entre la simulación y la construcción.
Registrar el alcance del prototipo, incluso en una frase, protege al equipo y protege la relación con quien patrocina el proyecto.
Convertir la lista de verificación en un hábito
Una lista de verificación sólo funciona si se utiliza todo el tiempo, no sólo cuando el proyecto es grande. La tentación es saltarse la revisión cuando el prototipo "parece obvio". Es precisamente en estos casos donde los estados olvidados pasan desapercibidos.
La mejor manera de incorporar esto es hacerlo liviano: una lista breve, revisada juntos, con diseño, producto e ingeniería en la misma conversación. No es necesario que sea un formulario largo. Tiene que haber una pausa deliberada antes de "pasar".
El liderazgo define si esto se mantiene. Cuando los líderes hacen preguntas difíciles durante la revisión, el equipo comprende que aprobar es una responsabilidad, no una formalidad. Cuando el liderazgo aprueba basándose en la apariencia, el equipo aprende a centrarse en el escaparate e ignorar el fondo.
Al final, la lista de control es un acto de honestidad con el futuro. Cambia el consuelo de "queda bonito, aprobado" por el trabajo de hacer que lo bello sea también completo, claro y edificable. Este trabajo no es glamoroso, pero es lo que separa a los equipos que cumplen con los que rehacen.
Si está configurando un proceso de aprobación de prototipos y desea estructurar una revisión como esta, hay otros textos aquí en el blog sobre creación de prototipos y calidad del producto. Y si quieres discutir cómo adaptar la lista de verificación a tu contexto, simplemente llama para hablar.
Lea también
- Prototipo de alta fidelidad: qué es y cuándo vale la pena el esfuerzo
- Prototipo de alta fidelidad: guía rápida para hacerlo sin perder tiempo
- Descubrimiento de productos: marcos con lista de verificación
- Creación de prototipos de aplicaciones en la práctica: cómo probar ideas antes de gastar código
- Creación de prototipos de aplicaciones: cómo transformar prototipos en rutinas de producto
- Creación de prototipos de aplicaciones: optimización con ejemplos