Construir ya es fácil. Saber qué construir, no
Hace poco leí a una diseñadora de producto que contaba algo que seguro que te suena. Un amigo suyo está enganchado al vibe coding, es decir, a construir aplicaciones pidiéndoselas a una IA en lenguaje normal. En unas horas tiene algo que se ve bien, funciona y parece magia. Se lo enseña a gente que no es diseñadora y todos se quedan impresionados.
Ella también lo entiende. Pero cuando mira esa pantalla, ve todo lo que hay detrás y que nadie ha resuelto todavía:
- ¿Por qué estamos resolviendo este problema?
- ¿Para quién?
- ¿Qué pasa antes y después de esta pantalla?
- ¿Qué debería ver primero el usuario?
- ¿Qué pasa cuando algo sale mal?
- ¿Cómo encaja esto en el negocio?
- ¿Cómo sabremos si ha funcionado?
«La pregunta ya no es solo si puedes construirlo, sino si sabes qué merece la pena construir.»
Lo ilustraba con una imagen muy clara: para quien no es diseñador, el diseño de producto son dos piezas, la interfaz y "que quede bonito". Para quien lo es, es una torre de quince: investigar a los usuarios, plantear bien el problema, la estrategia, la arquitectura de la información, los flujos, las pruebas, el trabajo con desarrollo, los datos, la salida al mercado y, al final de todo, el impacto en el negocio. La interfaz es solo una de esas piezas.
Lo que se ve desde fuera
- Diseño de interfaz
- Que quede bonito
Lo que es de verdad
- Investigación de usuarios
- Plantear el problema
- Estrategia y hoja de ruta
- Arquitectura de la información
- Flujos y bocetos
- Diseño de interfaz
- Diseño de interacción
- Sistema de diseño
- Prototipos y pruebas
- Gestión de interesados
- Trabajo con desarrollo
- Datos y métricas
- Iterar con feedback
- Salida al mercado
- Impacto en el negocio
Lo he vivido desde el otro lado
Yo no soy diseñador, pero me reconozco en las dos partes de la historia. Soy de los que se emocionan construyendo cosas con IA: esta misma web la he hecho así. Y es verdad que la primera versión sale en una tarde.
Pero en BMW aprendí que la mejor pieza no sirve de nada si el proceso que la rodea no funciona. Y en Laborai lo vi a diario. Construir herramientas internas con IA era rápido. Lo difícil era decidir cuál merecía la pena: qué tarea le quitaba más tiempo al equipo, qué pasaba cuando la IA se equivocaba con la declaración de un cliente y cómo medíamos si de verdad habíamos ahorrado algo. Las herramientas que fallaron no fallaron por el código. Fallaron porque resolvían un problema que nadie tenía, o lo resolvían para la persona equivocada.
Y hay un problema que llega justo después y que se va a multiplicar. Cuando construir es tan fácil, cada persona acaba haciéndose sus propias herramientas: una hoja de cálculo con macros aquí, un script allá y ahora una aplicación hecha con IA en una tarde. Cada una tiene sentido para quien la hizo. Pero nadie decide, con visión de conjunto, cuáles son las mejores, cuáles merecen seguir desarrollándose y cuáles deberían centralizarse para todo el equipo o toda la empresa. El resultado son diez versiones del mismo esfuerzo, ninguna mantenida y ninguna compartida.
Eso fue justo lo que me tocó resolver en MEWS Partners. Investigué el ecosistema de herramientas que ya existía, quién usaba qué y para qué, y propuse un modelo de gobierno: unas reglas claras para decidir qué herramientas se apoyan y se siguen desarrollando, cuáles se centralizan para todos y cuáles se retiran. No se trataba de prohibir que la gente construyera, sino de que lo mejor de lo que construía llegara a todos.
Hacia dónde creo que va esto
Creo que en los próximos meses vamos a ver cuatro cosas:
- Una avalancha de prototipos. Construir una demo costará casi cero, así que habrá muchísimas. Enseñar algo que funciona dejará de impresionar, igual que hoy nadie se impresiona porque una presentación tenga gráficos.
- El valor se mueve hacia arriba de la torre. Las preguntas de antes, por qué, para quién y cómo sabremos si funciona, valdrán más que nunca. Los perfiles que sepan hacerlas, sean diseñadores, ingenieros o gente de operaciones, serán los más buscados.
- Gobernar lo que se construye. Las empresas pasarán de tener unas pocas herramientas oficiales a cientos hechas por sus propios empleados. Las que mejor lo aprovechen tendrán a alguien mirando ese ecosistema entero y decidiendo qué se convierte en el estándar de todos.
- Más productos abandonados. Si lanzar es barato, también lo es lanzar lo que no hacía falta. Las empresas que ganen no serán las que construyan más rápido, sino las que descarten antes lo que no merece la pena.
Para mí la conclusión es sencilla: la IA nos ha dado un motor potentísimo. Pero un motor sin piloto, sin plan de vuelo y sin destino no es un avión.
Te dejo una pregunta: la última vez que construiste algo con IA, ¿cuánto tiempo dedicaste a pensar qué construir y cuánto a construirlo?
La idea y la imagen de la torre no son mías: las compartió una diseñadora de producto. La opinión y las previsiones son mías.
← Volver al blog