Hay un momento en la vida de casi todos los equipos de producto en el que alguien mira una pantalla ya desarrollada y dice: "eso no era exactamente lo que imaginaba". El código está listo, el sprint ha terminado y la conversación que debería haber ocurrido hace tres semanas ocurre ahora, con el costo multiplicado.
Este momento es evitable. Y lo que lo impide es que no haya más reuniones, no más documentos. Se trata de crear prototipos antes de construir, lo suficiente a menudo como para que se convierta en una rutina.
La creación de prototipos a menudo se trata como una fase: está la fase de descubrimiento, la fase de prototipo y la fase de desarrollo. Quiero defender lo contrario. Un buen prototipo es un hábito diario, barato y descartable que sirve para alinear entendimientos y eliminar dudas antes de que se conviertan en líneas de código.
¿Por qué crear prototipos todos los días, no solo al inicio?
Cuando la creación de prototipos se restringe al inicio del proyecto, se convierte en un ritual. El equipo diseña hermosas pantallas, aprueba todo en una reunión y luego descubre, durante la implementación, decenas de decisiones que nadie había tomado. ¿Qué pasa con un campo vacío? ¿Qué pasa si la lista no tiene elementos? ¿Qué pasa si la conexión se cae a mitad de camino?
Estos son los detalles que definen si un producto es bueno o mediocre. Y rara vez aparecen en un prototipo inicial, diseñado para impresionar y aprobar.
La alternativa es tratar el prototipo como una herramienta de conversación. Antes de abrir un ticket de desarrollo, alguien dibuja el flujo, incluso si está en papel o en un boceto de baja fidelidad. El objetivo no es la belleza, sino la alineación. Se trata de conseguir que quienes programan, quienes diseñan y quienes deciden hablen de lo mismo.
En el día a día, esto significa que la creación de prototipos deja de ser un hito en el cronograma y pasa a ser parte del refinamiento. Cada vez que hay ambigüedad sobre cómo debería funcionar algo, el prototipo responde más rápido que cualquier descripción textual.
La tesis: el prototipo es un instrumento de toma de decisiones, no una entrega
La mayor confusión sobre la creación de prototipos es tratarlos como entregables. Cuando el prototipo se convierte en entrega, gana peso, requiere aprobación y pasa a ser defendido por quienes lo realizaron. Entonces deja de cumplir su propósito.
Un prototipo existe para ser cuestionado y desechado. Es la forma más barata de cometer un error. Si descubre que el flujo es confuso incluso en el prototipo, ha perdido horas. Si se descubre en producción, pasan semanas, más confianza del usuario.
Por eso abogo por que el prototipo se mida con una única pregunta: ¿nos ayudó a decidir algo más seguro? Si es así, hizo su trabajo, sin importar lo pulido que estuviera. Si no, era decoración.
Este cambio de mentalidad es difícil porque va en contra del instinto de mostrar un trabajo bello. Pero los equipos maduros entienden que el valor está en la decisión que se toma, no en el expediente elaborado.
Fidelidad en la medida justa para cada pregunta
No todos los prototipos tienen que ser iguales. La fidelidad debe responder al tipo de duda que tengas.
Si la pregunta es sobre el flujo, en qué orden aparecen las pantallas, qué viene antes de qué, un boceto de baja fidelidad es la solución. Los cuadros y las flechas son suficientes. Invertir en píxeles aquí es un desperdicio.
Si la pregunta es sobre comprensión, el usuario entiende esta etiqueta, esta jerarquía, este botón, necesita algo más cercano a lo real, con textos reales y visuales mínimamente terminados. La gente reacciona ante lo que parece real.
Y si la pregunta es sobre comportamiento, este gesto es intuitivo, esta transición es confusa, tal vez necesites un prototipo interactivo o incluso un fragmento de código. Cada nivel de fidelización tiene un coste y gastarlo innecesariamente es el error más común que cometen los equipos que se enamoran de la herramienta.
La regla general que uso: comience siempre con la fidelidad más baja que responda a su pregunta. Sube de nivel sólo cuando la duda lo exija.
¿Cómo se conecta esto con el resto del equipo?
La creación diaria de prototipos cambia la dinámica entre el diseño, la ingeniería y los negocios. Cuando el prototipo circula temprano, el desarrollador puede señalar restricciones técnicas antes de que el diseño se convierta en una promesa. El propietario del producto puede ver cómo la hipótesis toma forma y ajustarla. Y quien dibuja recibe un contexto real, no sólo una sesión informativa.
En un proyecto de gobierno digital, por ejemplo, la creación temprana de prototipos es aún más valiosa. Los servicios públicos atienden a poblaciones diversas, con diferentes niveles de alfabetización digital, y muchas veces en situaciones de estrés, solicitan un duplicado, concertan una cita, solucionan un asunto pendiente. Un prototipo probado con ciudadanos reales revela barreras que ninguna reunión interna revelaría.
Lo mismo ocurre con una startup que intenta validar un flujo de registro. Mostrar un prototipo en el que se puede hacer clic a diez usuarios cuesta una tarde y puede ahorrar un mes de desarrollo que va en la dirección equivocada.
La creación de prototipos, en este sentido, es tanto una herramienta de comunicación como de diseño. Alinea a personas que piensan de diferentes maneras en torno a algo concreto.
Los riesgos de una mala creación de prototipos
La creación de prototipos también tiene sus riesgos, e ignorarlos es ingenuo.
El primero es el prototipo realmente hermoso. Cuando parece listo, los interesados piensan que el trabajo ha terminado y exigen la entrega inmediata, sin entender que la validación y la construcción aún están por llegar. La alta lealtad crea expectativas a corto plazo.
El segundo es el apego. Quienes han invertido horas en un prototipo tienden a defenderlo incluso cuando las pruebas muestran problemas. Se supone que el prototipo reduce el ego en el proceso, pero su mal uso produce lo contrario.
El tercero es confundir prototipo con especificación. Un prototipo muestra la intención, no cubre todos los estados, errores y excepciones. Los equipos que tratan el prototipo como un contrato completo descubren, durante la implementación, todos los agujeros que no cubrió.
Y el cuarto, quizás el más traicionero, es crear prototipos sin preguntar nada. El prototipo sin hipótesis es sólo un dibujo. Antes de abrir la herramienta, conviene anotar en una frase lo que quieres descubrir. Sin esta pregunta, se producen pantallas, no conocimientos.
Hacer de la creación de prototipos un hábito sostenible
Para que la creación de prototipos se convierta en una rutina, debe ser barata y rápida. Si cada prototipo requiere un proyecto aparte, nadie lo hará a diario. El secreto es tener componentes reutilizables, un estándar visual ya definido y la disciplina de aceptar el boceto feo cuando sea suficiente.
El liderazgo aquí marca la diferencia. Cuando el líder técnico o de producto valora el prototipo desechable y no requiere un pulido innecesario, el equipo se siente seguro para experimentar. Cuando la cultura sólo recompensa el producto final, la creación de prototipos muere ante la presión de la primera fecha límite.
La ganancia a largo plazo es silenciosa pero real: menos reelaboración, menos discusiones circulares, decisiones tomadas con evidencia en lugar de opinión. Un equipo que crea buenos prototipos comete errores más rápido y más barato, y cometer errores a bajo costo es una de las mayores ventajas competitivas que existen.
Al final, crear prototipos cada día es una forma de respetar el tiempo de todos. Se trata de preferir la conversación difícil ahora, en el borrador, a la conversación costosa más adelante, en el producto.
Si su equipo todavía trata el prototipo como una fase aislada y sigue descubriendo problemas demasiado tarde, podría valer la pena repensar este hábito. He estado escribiendo sobre creación de prototipos, validación y proceso de producto aquí en el blog, y estoy disponible para intercambiar ideas sobre cómo adaptar esto a su realidad.
Lea también
- Creación de prototipos de aplicaciones en la práctica: cómo probar ideas antes de desperdiciar código
- Prototipo de alta fidelidad: qué es y cuándo vale la pena el esfuerzo
- Prototipo de alta fidelidad: la lista de verificación antes de aprobar y construir
- ¿Vale la pena hacer una aplicación? La lista de verificación honesta antes de gastar su primer dólar
- Diseño de producto digital: lo que realmente significa diseñar productos que importen
- Creación de prototipos de aplicaciones: optimización con ejemplos