Un prototipo es una aproximación funcional de un producto o característica, creada para responder a una pregunta antes de la construcción del producto final. Los prototipos abarcan desde bocetos en papel realizados a mano, pasando por pantallas interactivas vinculadas en una herramienta de diseño, hasta código funcional que se ejecuta con datos reales. Lo que los une es su propósito: un prototipo existe para ser evaluado, descartado o revisado, no para ser lanzado al mercado.
La disciplina fundamental consiste en decidir qué pregunta debe responder el prototipo, ya que esto determina la fidelidad requerida. Para saber si los usuarios comprenden una estructura de navegación, basta con un conjunto de pantallas estáticas vinculadas. Para saber si una interacción resulta suficientemente fluida, es necesario un prototipo codificado con sincronización real, puesto que ningún artefacto estático puede transmitirla. Para saber si una tabla de datos compleja es utilizable, es esencial trabajar con volúmenes de datos realistas, ya que una tabla que funciona con diez filas puede resultar inutilizable con diez mil. Construir un prototipo con mayor fidelidad de la que requiere la pregunta supone una pérdida de tiempo; construir uno con menor fidelidad produce respuestas que no son transferibles.
Los prototipos son especialmente valiosos para cuestiones que no se pueden resolver mediante el debate. Los equipos pueden discutir indefinidamente sobre si un flujo es demasiado largo, si un concepto es comprensible o si una interacción es fácil de descubrir, y ningún debate lo resuelve porque cada uno razona desde su propio modelo mental. Presentar una aproximación a cinco personas que se ajustan al público objetivo suele zanjar la discusión en un día y, con frecuencia, revela que ambas posturas eran erróneas por razones que nadie había previsto.
El principal riesgo es que un prototipo se convierta en el producto final. Un prototipo convincente genera presión para su lanzamiento, especialmente bajo presión de tiempo, y el código escrito para responder una pregunta rara vez se escribe para ser mantenido: sin manejo de errores, sin accesibilidad, sin casos límite, sin pruebas. Las organizaciones que promueven repetidamente los prototipos a producción acumulan deuda técnica de la forma menos visible posible. Tratar el código del prototipo como explícitamente desechable, y decirlo claramente antes de compilarlo, es la única protección confiable.
Un segundo riesgo es la sobreinversión. Los prototipos que tardan semanas en construirse tienen el mismo peso emocional que el trabajo terminado, y los equipos se muestran reacios a abandonar una dirección en la que han invertido un esfuerzo considerable. El valor de la creación de prototipos reside en la posibilidad de descartarlos a bajo costo, lo que significa que la velocidad es una propiedad funcional, no una conveniencia. Si un prototipo tarda más en construirse que la funcionalidad en sí, la pregunta debería haberse abordado de otra manera.
También es útil distinguir entre prototipos para explorar y prototipos para comunicar. Un prototipo exploratorio es preliminar, de uso exclusivo del equipo y se descarta una vez que se responde la pregunta. Un prototipo de comunicación se crea para demostrar una dirección propuesta a las partes interesadas o para especificar el comportamiento a implementar, y debe ser más completo y estar más pulido, ya que se interpretará literalmente. Confundir ambos tipos de prototipos genera problemas previsibles: el trabajo exploratorio que se muestra a los ejecutivos se interpreta como un compromiso, y los prototipos de comunicación con un enfoque exploratorio poco riguroso dejan a los desarrolladores con dudas sobre estados y casos límite que nunca se consideraron. Decidir qué tipo de prototipo se está creando y especificarlo al presentarlo evita la mayor parte de esta confusión.
En la práctica, el prototipado se sitúa en la intersección entre el diseño y la entrega, y su resultado es una decisión más que un artefacto. En un diseño de producto En el compromiso, los prototipos se utilizan para validar conceptos con usuarios reales antes de la especificación, mientras que en desarrollo de productos También se utilizan para mitigar los riesgos asociados a las suposiciones técnicas sobre viabilidad, rendimiento e integración antes de definir una arquitectura. Es importante mantener diferenciados estos dos propósitos, ya que un prototipo que responde a una pregunta de usabilidad y otro que responde a una pregunta técnica rara vez tienen por qué ser lo mismo.