El código y la infraestructura de mis dos productos los escribió una IA. Las decisiones de producto y de diseño son mías.

Digo las dos cosas en la primera línea porque si no, la conversación se desvía. Hay quien oye «lo hizo la IA» y asume que no hubo trabajo. Y hay quien oye «diseñé dos productos yo solo» y asume más mérito del que hay.

Lo que no esperaba es que el cambio importante no fuera la velocidad. Cuando construir deja de ser caro, desaparece el filtro que tomaba muchas decisiones por ti. Antes proponías algo, desarrollo decía que costaba tres semanas, y la idea moría sin que nadie tuviera que valorar si era buena. El coste decidía. Ahora no decide nadie, salvo que decidas tú.

Este artículo va de tres decisiones donde tuve que hacerlo, y de lo que su existencia dice sobre qué parte del diseño se automatiza y cuál no.

Lo que sí hizo la IA, y lo que hice yo con lo que hacía

Nexo Suite son dos productos para el transporte sanitario: una historia clínica electrónica para ambulancias en servicio urgente y un sistema de gestión para transporte programado. Soy el único diseñador y quien toma las decisiones de producto.

La IA escribió todo el código. Las integraciones. La estructura de datos. La parte que en otro contexto habría necesitado un equipo y varios meses. No lo minimizo, porque minimizarlo sería falso: sin esas herramientas, Nexo sería un archivo de Figma con pantallas bonitas y ninguna forma de comprobar si funcionan.

Pero hay una pregunta que se hace todo el que lee esto, y conviene contestarla antes de seguir: cómo sé que lo que salía estaba bien.

No por leer el código. Por trabajar de otra manera. Cada tarea empieza con una fase de solo lectura donde se comprueba contra el producto real lo que se cree que hay, porque casi siempre falta algo o sobra. Cada cambio lleva escritos sus criterios de aceptación antes de existir. Y ninguno se da por bueno hasta que lo veo funcionando yo, en el producto real, buscando dónde está roto en vez de confirmar que va.

Esa última parte importa más de lo que parece. Trabajar solo con una herramienta que siempre te dice que sí multiplica el sesgo de confirmación. La disciplina no es revisar: es ir a buscar el fallo.

Decisión 1: un solo dispositivo por servicio

En Nexo Clinical, la opción evidente era permitir que varios miembros del equipo editaran el mismo registro desde distintos dispositivos. Es lo que espera cualquiera, es lo que hace casi todo el software, y es un problema técnico resuelto: se lo pides a la IA y lo implementa bien.

Decidí lo contrario. Y no lo decidí sobre el papel.

Durante el desarrollo apareció un caso que no había previsto. La tablet de una ambulancia no es de nadie: la usan varios profesionales, en turnos distintos, uno detrás de otro. Y la aplicación estaba recuperando en la sesión de uno el registro que había dejado el anterior, con los datos del paciente incluidos. Nadie hacía nada mal. Simplemente, alguien podía acabar escribiendo sobre el servicio de otro sin enterarse.

Lo que ese caso planteaba no era un fallo a corregir, era una pregunta de producto: quién es el dueño de un registro clínico mientras está abierto. La respuesta fue que uno solo, y que el traspaso tiene que ser un gesto explícito y no un efecto secundario de cambiar de sesión.

Esa decisión cierra puertas. Elimina el trabajo simultáneo, obliga a un traspaso a mano y complica escenarios que con edición compartida serían triviales.

Y tiene un límite que prefiero decir yo: hoy es una regla de producto, no una restricción que el sistema imponga. Si alguien abre la aplicación en un segundo terminal, todavía no hay nada que lo detecte. Cerrarlo bien obliga a decidir antes qué pasa cuando el segundo terminal es legítimo —un relevo, una avería, un cambio de vehículo a mitad de servicio—, y esa parte no la tengo resuelta.

Ninguna herramienta te va a decir que la opción técnicamente superior es la peor para tu contexto. Para eso hay que saber dónde se usa el producto.

Decisión 2: cuánto mide un botón dentro de un vehículo en marcha

Esta la cuento porque me equivoqué, y el error es más útil que el acierto.

Al diseñar los controles principales busqué cuál era el tamaño mínimo de área táctil. La respuesta es fácil de encontrar y hay consenso: unos 9 milímetros. Es lo que hay detrás de los 48 dp de Material Design, es lo que recomendaban las guías de Microsoft, y tiene investigación seria que lo respalda.

Lo apliqué y me quedé tranquilo. Estaba siguiendo el estándar.

El problema es de dónde sale ese estándar. Los estudios que lo sustentan se hicieron con el dedo desnudo, el dispositivo en la mano y la persona quieta. Ninguno contempla un vehículo en marcha.

Y la diferencia está medida. Schachner y Doyon-Poulin publicaron en 2024, en el International Journal of Human-Computer Interaction, un trabajo sobre selección de objetivos en pantallas táctiles de cabina bajo vibración. Encontraron una tasa media de error del 10,3% en condiciones estáticas frente al 16,6% con vibración.

Conviene decir qué mide exactamente ese estudio, porque no es mi caso: la vibración es la de un helicóptero en vuelo nivelado, y las dianas iban de 0,8 a 2 centímetros. Una ambulancia por carretera no es un helicóptero. Lo que el estudio establece no es mi cifra, es que el movimiento del vehículo degrada la precisión lo bastante como para que el mínimo estático deje de servir de referencia.

Yo estaba aplicando la cifra correcta según la documentación, a un contexto que la documentación no contempla.

Lo corregí. El sistema de diseño de Nexo Clinical fija ahora 52 píxeles como área táctil mínima y 72 en las acciones que no se pueden deshacer, además de más separación entre elementos. El mínimo estándar pasó a ser un suelo, no un objetivo.

Y tuvo su precio, que es la parte que suele faltar cuando alguien cuenta esto: cabe menos en pantalla. Cada aumento de área táctil es contenido que sale de la vista o que baja un scroll. Subir los tamaños obligó a decidir qué información deja de estar delante, y esa decisión no la resuelve ninguna guía.

Lo cuento porque la IA me dio la respuesta correcta a la pregunta que le hice. Darme cuenta de que estaba haciendo la pregunta equivocada es la parte que no delegué, y la que más tardé en hacer.

Decisión 3: no construir

La tercera es la menos visible y probablemente la más difícil.

Nexo Clinical no tiene notificaciones. No porque no supiera implementarlas —eso ahora es la parte fácil— sino porque no he encontrado un caso donde el beneficio compense interrumpir a alguien que está atendiendo a un paciente. Lo desarrollé aquí, con las razones y con lo que no tengo resuelto.

En Nexo Ops pasó algo parecido con el alcance: la primera versión empieza en la recepción de la demanda y deja fuera la prescripción del transporte. Incluirla habría ampliado el producto hacia un proceso clínico con responsabilidades distintas. Era construible. No tocaba.

Cuando construir era caro, la disciplina de no construir te la imponía el presupuesto. Ahora hay que ponerla uno mismo, y cuesta más de lo que parece. La tentación de añadir algo porque es barato es constante, y no se nota como una mala decisión: se nota como un producto que hace muchas cosas y ninguna bien.

Lo que esto dice del oficio

No creo que la IA haya eliminado el trabajo de diseño. Creo que ha eliminado la parte del trabajo que servía de coartada.

Cuando la ejecución era lenta y cara, se podían pasar meses ocupado sin haber decidido gran cosa. Producir pantallas, mantener el sistema de diseño, documentar componentes. Todo eso es trabajo real y sigue haciendo falta, pero llenaba el calendario de una forma que hacía difícil distinguir a quien decidía de quien ejecutaba.

Si quitas buena parte de la ejecución, lo que queda a la vista es el criterio. Y el criterio se nota enseguida: en si sabes qué problema estás resolviendo, en si puedes explicar qué pierdes con la opción que elegiste, y en si eres capaz de no construir algo que técnicamente podrías tener esta tarde.

Y entonces

Si lo que aportas es convertir requisitos en pantallas, esa parte se está automatizando, y rápido.

Si lo que aportas es decidir qué construir y qué no para un contexto concreto, entender dónde se usa el producto y poder defender por qué elegiste una cosa en lugar de otra, entonces la IA no te sustituye: te quita de encima el trabajo que te impedía dedicarte a eso.

Yo hasta hace poco no habría podido comprobarlo. Ahora sí, y la conclusión es incómoda en un sentido y tranquilizadora en otro. Lo difícil nunca fue construirlo.

---

El caso completo de Nexo Clinical, con las decisiones de diseño y sus consecuencias, está en Casos.