UX no es cuestión de estética, gustos, opiniones, ni te lo resuelve una IA. Es el resultado de decisiones informadas por evidencia.

La experiencia de usuario, es lo que el usuario experimenta.
Ocurre delante de la pantalla, no dentro de ésta.
Por eso, hasta que no observás a usuarios reales interactuando con tu producto, no tenés más que hipótesis, no UX.

Y como una LLM no tiene visceralidad, no se cansa, no se aburre, ni vive la presión del tiempo, puede “aprobar” lo que jamás podría funcionar en la vida real.

De hecho, los miles de SaaS vibecodeados que no lograron ingresos ni para pagar su propio dominio, muestran que una inteligencia artificial es absolutamente incapaz de producir por sí sola, productos económicamente viables.

Pero sí es muy buena manipulando a quien la usa, para hacerle creer que “su sitio” (igual a todos los que todos los demás están haciendo) es oro puro. Y así es como la IA puso a sus usuarios en una rueda de hamster, a gastar tiempo y tokens en inundar la web y los stores con productos que no le interesan a nadie.

Ahora, vayamos a lo técnico:

El principal problema de la interfaz de un POS, no es la estética. Es que “Ágil e intuitivo” son requerimientos en conflicto.

Para un operador que necesita rapidez, no es cuestión de cómo “luzca” la interfaz. Sino de diseñar la interacción con KLM-GOMS (Keystroke-Level Model), descomponiendo la interacción y calculando el costo por cada operación elemental:

Recién una vez definido el modelo de operación, corresponde plantear la UI que le corresponde, para finalmente iterar, validar y refinar con usuarios reales. Es lo mismo que en arquitectura, definir la circulación de los clientes, antes de ubicar las paredes y escaleras de un shopping. Y hasta que la gente no usa la interfaz ni circula por el shopping, no existe ninguna “experiencia” ni podés decir que hayas logrado nada.

El conflicto entre “ágil” (o más técnicamente, efectivo, productivo) vs. “intuitivo” (visible, evidente) parte de que el dispositivo de input más rápido es el teclado, no el mouse.

Como ejemplo concreto:

• Mover una pieza de ajedrez usando el teclado: tipear Ae2 + Enter. Eso es, 0,1 segundo por tecla = 0,4 segundos de costo motriz.
• Usando el mouse: agarrar el mouse, mover el mouse hasta la pieza, mousedown, mover el mouse, mouseup. De esa secuencia, tan sólo el primer paso (agarrar el mouse, homing en KLM-GOMS) ya cuesta 0,4 segundos.

En una aplicación de uso continuo, el diseño de interacción mueve la aguja. La estética de la UI y los templates dominantes en el corpus de la IA, no.

La UI en estos casos, además de ser la capa adecuada para la interacción, puede tener la función de que los compradores la vean “linda”, profesional, moderna o lo que fuere (lo cual suele ayudar a la venta). Pero que la UI “luzca” ágil, no causa ningún efecto en la operación.

Hay muchas dimensiones del diseño además de la estética, y precisamente UX se trata de trabajar esas dimensiones. Aplicando estos principios, hemos logrado mejoras consistentes de hasta 4X en eficiencia operativa, más de 3X en adopción y 3X en facturación.

¿Necesitás que tu aplicación funcione realmente para tus usuarios y clientes, no sólo en la “imaginación” de una IA? Hablemos.

La entrada UX no es “cómo luce”, es “cómo se vive”. se publicó primero en Kambrica.

El problema es que Figma y otras, ya están dejando de ser herramientas de diseño, para ser herramientas de producción. Y diseñar y producir son procesos totalmente distintos, y fundamentalmente incompatibles.

Al fusionar ambos, la herramienta impone sus propias decisiones de diseño. El resultado no es mayor eficiencia, sino productos clones del promedio estocástico. Productos que aceleran la comoditización de tu producto y tu marca.

Y cuando todo se parece, el mercado empieza a elegir exclusivamente por precio. No es una falla de tu equipo de diseñadores; es la consecuencia directa de tomar decisiones estratégicas basadas en el apuro operativo.

El resultado es que el 80% de los proyectos que se lanzan, son indistinguibles.
Porque responden a las reglas de la IA, no las de tus clientes.

Esto no se arregla con diseñadores que programan. Toda metodología de desarrollo desde 1970 reconoce que diseño e implementación van por separado. Fusionarlas siempre sonó tentador. Pero operacionalmente, jamás funcionó.

La presión por producir siempre ahoga la capacidad de crear.

El apuro por “no perderse el tren” nos está haciendo terminar abajo de las vías en lugar de arriba del vagón.

En Kambrica trabajamos con IA desde 2009, mucho antes de que fuera una moda corporativa. Hace poco se vendió Keepcon, una de las compañías tecnológicas con las que trabajamos en sus fases iniciales. En palabras de su fundador: cuando no tenían clientes ni tecnologia, nuestro prototipo permitió a los inversores aterrizar una idea abstracta, entender el modelo de negocio y cerrar su primera ronda de inversión.

Empecé mi carrera en UX hace 30 años, diseñando y desarrollando simuladores de negocios para formación gerencial. Hoy ayudo a líderes y gerentes a tomar mejores decisiones en la intersección entre negocio, diseño y tecnología.

Si buscás una adopción de IA con resultados reales, el apuro es el peor consejero.
Nosotros te ofrecemos experiencia.

Pongámonos en contacto.

–

Santiago Bustelo
Junio, 2026

La entrada ¿Cómo estás encarando la adopción de IA en tu equipo de diseño? se publicó primero en Kambrica.

La adopción no “ocurre”. Se diseña. Antes del código.

Navegar a ciegas

Si estamos en el polo norte, la brújula no encuentra dirección: no hay un “ángulo” donde esté el norte. Y hacia todos lados, está el sur.

Lo mismo sucede en la industria del software con un principio que nos ha acompañado desde los inicios: la idea de que la tecnología agregaba valor por sí misma.

Ahí donde no había tecnología, la incorporábamos. Y de forma automática, creábamos valor. Eso llevaba naturalmente a su adopción y a mejores resultados.

Este principio nos ayudó a establecer dirección durante décadas: primero en los procesos de informatización, y luego en la transformación digital.

La brújula que dejó de funcionar

Hoy ocurre que ya nos encontramos en el Norte de estos procesos: ya hay una computadora en cada escritorio, una en cada bolsillo (móvil), una en cada living y habitación (smart TV), varias en cada auto… 

Entonces, este principio que fue nuestra brújula, hoy nos da lecturas erróneas.

El caso Copilot

Es así que Microsoft –nada casualmente, la empresa que tuvo por misión “una computadora en cada escritorio y en cada hogar”–, contando con un equipo de ingeniería de primer nivel, un presupuesto de marketing comparable al PBI de un país pequeño, y un canal de distribución privilegiado (las actualizaciones del sistema), lo que ha logrado es… un meme:

Copilot no es una excepción. Es la advertencia de que el principio de que “la tecnología asegura adopción” ya no aplica.

Es la punta del iceberg de miles de proyectos que veremos este año, cuyo postmortem será: “no lo hicimos porque era fácil, útil, ni rentable: lo hicimos porque el entusiasmo en la IA, nos hizo creer que lo sería“.

Desarrollo y adopción ya no van juntos.

Hoy la ecuación ya no es “más tecnología = más adopción = mejores resultados”.
Hoy la ecuación es: “Tecnología x Adopción = Resultados”.
Si adopción es cero, todo esfuerzo aplicado en Tecnología, es desperdicio.

La pregunta correcta

La pregunta ya no es: ¿Qué tecnología deberíamos agregar?
Sino: ¿Qué problema estamos tratando de resolver, y cuál es la manera más simple, rápida y económica de validar si eso es un buen negocio?

La adopción no “ocurre”: se diseña.
Y se diseña antes de escribir una línea de código.
Porque cada proyecto que arranca sin validar adopción es costo hundido.

Si tu próximo proyecto todavía empieza por tecnología, ya empezó mal. Hablemos antes.

La entrada La tecnología no asegura adopción (y eso te cuesta millones) se publicó primero en Kambrica.