Prototipar productos legales antes de construirlos: el error más barato

Cuando un equipo legal decide crear algo nuevo —un portal de autoservicio, una plantilla inteligente, una guía interactiva— la tendencia natural es planificarlo completo antes de mostrarlo. Es coherente con la formación profesional: no se entrega nada hasta que está bien. Aplicado a productos, es un error costoso.

El motivo es que las suposiciones sobre cómo alguien usará algo casi nunca sobreviven al contacto con el uso real. No por falta de análisis, sino porque el comportamiento depende de detalles imposibles de anticipar: en qué momento del día se usa, con cuánta prisa, desde qué dispositivo, con qué conocimiento previo.

Un prototipo no es una versión reducida del producto. Es un instrumento para responder una pregunta concreta. Si la duda es si la gente entenderá la estructura, basta con papel. Si la duda es si usarán la herramienta en lugar de escribir un correo, hace falta algo que puedan usar en su flujo real, aunque por detrás lo resuelva una persona manualmente.

Esa última técnica es la más subestimada. Ofrecer el servicio con una fachada simple y ejecutar todo a mano detrás, durante unas semanas, permite validar la demanda y afinar las reglas antes de automatizar nada. Si nadie lo usa cuando funciona con esfuerzo humano, tampoco lo usará cuando esté automatizado. La diferencia es que en el primer caso se perdieron dos semanas y en el segundo, seis meses de desarrollo.

La resistencia habitual no es de tiempo, es de imagen. Mostrar algo tosco a un cliente interno se siente poco profesional, sobre todo en una función que se define por el rigor. Ayuda encuadrarlo con claridad: esto es un borrador para decidir juntos la dirección, no un entregable. La gente colabora bien cuando entiende el encuadre, y de hecho opina mejor sobre algo evidentemente inacabado que sobre algo que parece terminado.

Sobre la escala de la prueba: con cinco personas se detecta la mayoría de los problemas graves de comprensión y uso. No hace falta una muestra grande para saber que un flujo confunde. Sí hace falta observar en silencio, sin explicar, porque la explicación del creador tapa exactamente el problema que se quería encontrar.

Y conviene definir de antemano qué resultado haría abandonar la idea. Un prototipo que no puede fallar no es una prueba, es una demostración. Si el equipo no está dispuesto a matar el proyecto, mejor ahorrarse el ejercicio y asumir que se está construyendo por convicción, no por evidencia.

Felipe Besnier — Legalmente Ágil