Pero saber que alguien tiene 39 grados de fiebre, no nos dice cómo bajarla. Porque medida no es diagnóstico.

Y de la misma manera en que la fiebre no es “más rayitas en el termómetro”, una conversión no es “un click en un CTA”.

Una conversión es cuando una persona se convierte en otra. Por ejemplo:

• cuando un visitante, se convierte en usuario (empieza a usar el producto)
• cuando un usuario, se convierte en cliente (empieza a pagar por el uso)

Eventos que suceden en la pantalla (como hacer click en “crear cuenta”), sirven para “medir las conversiones”. Pero la conversión ocurrió mucho antes que ese evento.

El click ocurrió porque un dedo se acercó al botón. El dedo, porque un cerebro lo dirigió. Y ese cerebro, por una larga cadena de evaluaciones, información y decisiones, consideró que hacer eso, era mejor que no hacerlo.

Descifrar esa cadena causal y detectar dónde podemos intervenir es función de la investigación cualitativa y la consultoría estratégica.

¿Querés pasar de medir los síntomas de tu producto a operar sobre las causas?

Hablemos.

La entrada Medida no es diagnóstico se publicó primero en Kambrica.

Por ejemplo, le das a “analizar” tu sitio de “forma experta”. Y básicamente, te dice que hagas todo lo que no estás haciendo.

Te lo dice de forma confiada y convincente. Hasta genera cierto sentido de urgencia.

Pero se revela como un truco de feria cuando sabés que eso que no estás haciendo ahora, es por haberlo intentado antes. Y haber comprobado que no funciona.

Cuando al mago se le ven los hilos

La IA, puesta a “hacer recomendaciones”, lo que hace en realidad es completar una plantilla con “lo más probable”.

Y de la misma forma en que te rellena los textos con la insufrible plantilla “No es X. Es Y”, tiene una plantilla de “recomendación experta”:

• Título que suena a hallazgo.
• Supuesta evidencia del problema.
• Presunto impacto verosímil.
• Conclusión preocupante y tajante.

Cada vez conozco más responsables de producto y emprendedores que están ejecutando esas recomendaciones, sin ver resultados.

Porque las IA están entrenadas con lo que se puede encontrar dentro de una pantalla.
Y los resultados no vienen de ahí.
Vienen de lo que pasa delante de las pantallas.

¿Cuánto tiempo llevás implementando las recomendaciones de tu IA, sin ver resultados?

Hablemos. Podemos ayudarte a cambiar el foco a donde realmente importa.

La entrada La IA haciendo recomendaciones de “mejoras”, parece mágica. 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.

A todos les conviene que el proyecto crezca.
A nadie le conviene evaluar si el proyecto tiene sentido.

Así proliferan proveedores que cumplen pedidos, no contradicen, “avanzan con eficiencia”.

Cuando finalmente el sistema no se usa, nadie lo adopta o el negocio no mejora, el costo hundido queda dentro de la organización. El resto cobró igual. Con incentivos mal alineados, no corregir a tu cliente cuando se equivoca es un buen negocio.

La mayoría de los proyectos de software fracasa.
Pero no por cuestiones técnicas.

Sino por decisiones mal planteadas, supuestos no validados y ausencia de criterio profesional en momentos críticos.

Cada fracaso se percibe como un caso aislado.
Pero no es mala suerte: es un patrón.
Y es completamente prevenible.

En industrias maduras, la autoridad técnica implica responsabilidad sobre el resultado. Ése es el sentido original de la consultoría profesional: asesoramiento experto para tomar mejores decisiones, no proveer manos para ejecutar las que ya se tomaron.

Las software factories venden fórmulas porque las fórmulas escalan. Las agencias venden horas porque las horas escalan. Las plataformas venden uso porque el uso escala. Nada de eso garantiza resultados.

La dirección estratégica, sí.

Empieza por una breve sesión de diagnóstico.

Cuando una organización necesita revisar el rumbo de un proyecto, validar supuestos o reducir riesgo antes de invertir más, esta sesión permite analizar la situación y determinar si tiene sentido avanzar.

Si tenés autoridad sobre los proyectos, contanos sobre tu situación y si creemos que te podemos ayudar de verdad, coordinaremos la reunión.

Compartir

Si este patrón resulta familiar, probablemente alguien más en la organización también debería verlo:

La entrada En software, la mayor amenaza no es técnica. Es la estructura de incentivos. se publicó primero en Kambrica.

• mencionar la Navidad podía ofender a otras religiones,
• indicar el año implicaba que nuestro calendario es superior a otros, y
• desear felicidad suponía que quien recibe la tarjeta no la tiene, asumiendo una carencia emocional previa.

Así que, tras un riguroso proceso de pensamiento crítico y revisión legal, presentamos la tarjeta políticamente correcta definitiva:

La entrada ¡Les deseamos un año! se publicó primero en Kambrica.

Relevar, escuchar, investigar… son para esa forma de pensar, señales de debilidad.

¿Contratar expertos? Antes muertos. No ellos… sino los proyectos, o la empresa. Prefieren que el negocio pierda oportunidades, desperdicie dinero o incluso fracase, antes que aceptar que lo que dijeron ayer, vale la pena revisarlo a la luz de la nueva información disponible hoy.

Previsiblemente, los únicos casos en los que avanzamos con un proyecto, es cuando hablamos con el 20% de gerentes actualizados, competentes y responsables que entienden que su función no es ser semidioses omniscientes e infalibles. Su función es ser seres humanos, cargando con enormes responsabilidades – entre ellas, la de aprender y mejorar todos los días. Porque todo es perfectible, y en el momento en el que dejamos de avanzar, nos regalamos a que la competencia nos pase por arriba.

Si sos parte de la minoría de los gerentes que entiende realmente su función en este siglo, te invito a conectarnos y conocernos.

Con casi 30 años ayudando a gente como vos a tomar mejores decisiones, superar desafíos y lograr resultados en más de 40 industrias, seguro tenemos de qué hablar.

La entrada Sos un Gerente del Siglo XXI? se publicó primero en Kambrica.

Para el estereotipo anacrónico de ingeniero informático, si el usuario no puede usar el software, entonces el usuario es tonto.

Para ese mismo estereotipo, si el usuario está enojado por los problemas que le producen las fallas del software, “está un poquito perseguido”.

Para ese estereotipo, “diseño” es decoración. Espejitos de colores que se le pueden agregar al “software” que el estereotipo produce. La función de esos espejitos de colores sería que el software sea “lindo”, “a prueba de bobos”: porque los usuarios son esencialmente estúpidos, y como no entienden las cosas, hay que hacerles dibujitos y ponerles colorcitos.

Esa forma de ver las cosas es propia de la década del ‘70, cuando el software era algo misterioso y arcano que manejaba un puñado de gente en una sala especial en algún edificio muy importante al que muy poca gente podía entrar.

Hoy, que el software está en el bolsillo de todo el mundo, que el software es un producto o servicio que un usuario final tiene la potestad de elegir, de usar y de pagar o dejar de hacerlo, el criterio es muy distinto.

Si tu usuario no puede usar tu software, el error es tuyo: o elegiste mal a tu usuario, o construiste mal el software.

Si tu usuario está enojado por los problemas que tu software le causa, el error es tuyo: tu software no está generando soluciones, sino problemas.

Ésa es la visión de UX estratégico, entendido como la disciplina crítica, nacida en las empresas y equipos que le dieron dirección y sentido a la industria desde la década del ‘80. Y que hoy debe darle dirección a los procesos de toma de decisiones de negocio y de tecnología para lograr productos, servicios y sistemas funcionando, que sean adoptados y aceptados por los usuarios finales reales, y que cumplan con los objetivos del negocio.

Si pensás que ésta es la visión que está faltando desarrollar en tu empresa o equipo, hablemos :)

La entrada El estereotipo de ingeniero informático versus el usuario, esa cosa molesta entre el teclado y la silla se publicó primero en Kambrica.

Un argentino en Helsinki

Allá por marzo de 2016, tuve la suerte de poder participar de la conferencia Interaction 16 en Helsinki, Finlandia. Ya al bajar del avión, tuve mi primer choque cultural: la organización del evento había logrado poner un stand en el aeropuerto. Algo que habíamos soñado cuando organizamos Interaction South America 2014 en Buenos Aires, pero que requería de un apoyo oficial concreto, en lugar del simbólico que recibimos. En Helsinki, en cambio, la ciudad apoyó al evento a tal punto que en el stand entregaban tarjetas precargadas para transporte público, de manera que pudiéramos recorrer y conocer la ciudad durante una semana entera.

Mi segundo choque cultural fue cuando llegué a la parada del colectivo. No había nadie. Después de esperar un par de minutos, empecé a dudar de si esa era la parada correcta. El cartel coincidía con la línea que tenía que tomar, pero la situación me resultaba sospechosa. Entonces recorrí el resto de la dársena, acostumbrado –como en Buenos Aires– a que a veces los carteles queden como resto arqueológico luego de que la línea haya mudado su parada.

No habiendo encontrado otra parada de la línea, volví a la original. Y después de un ratito llegó una persona muy abrigada, a quien le pregunté si la línea pasaba por ahí. Miró el cartel, me miró como si fuera imbécil, y me dijo: “Sí, claro. Ahí dice que pasa”.

“¿Y tarda mucho?”, pregunté. Me volvió dedicar la misma mirada, abrió en su teléfono la aplicación de Google Maps – que mostraba los horarios oficiales– y me dijo: “Pasa en cinco minutos”.

Y cuatro minutos y medio después, llegó desde el aeropuerto un enorme contingente de gente calentita, que había estado esperando a resguardo el horario del colectivo. Porque en Finlandia, los transportes siguen la grilla de horarios. Cosa que me pareció surreal: en Argentina, las tablas de horarios son meras sugerencias, y es habitual estar esperando media hora un colectivo que supuestamente pasa cada tres minutos.

El último choque cultural que tuve fue cuando, ya en el bus, otro pasajero notó mi ansiedad tratando de ver las paradas por las que pasábamos y contrastarlas con las instrucciones que llevaba anotadas. Me preguntó si me podía ayudar, y después de un par de veces accedí. Le conté adónde iba y me dijo que iba para el mismo lado, y que me iba a acompañar.

“Cuando nos bajamos, el gordo me asalta”, pensé. Pero no. Resultó que era una excelente persona que quería que yo tuviera una muy buena primera experiencia en su ciudad.

Me contó que se llamaba Toti, y que era docente de atención al cliente en el secundario. Porque el sistema educativo finlandés tiene que preparar a la gente para la vida real, y entiende que hay gente que no va a seguir la universidad después del secundario. Por ejemplo, va a trabajar en una peluquería. Y un peluquero tiene que saber atender a la gente.

Yo empecé mi carrera como diseñador de interacción en 1996, diseñando simuladores de negocios para formación gerencial. Atención al cliente era un tema recurrente, y teníamos cursos para gente que ya estaba trabajando (en ocasiones hacía años) sin formación alguna. En Finlandia me vine a enterar de que era parte del programa educativo oficial. Mientras que en estas pampas, todavía seguimos discutiendo sobre programas educativos que ya cuando éramos chicos olían a naftalina.

Toti me contó la razón por la que se dedica a hacer este esfuerzo para cuidar la experiencia que tienen los turistas recién llegados a Helsinki. Según él, hay dos tipos de países: los países donde todo funciona, pero nada se puede cambiar; y los países donde nada funciona, pero todo se puede conversar. Me explicó que Finlandia pertenece a la primera categoría: si sabés cómo entrar en el sistema, el sistema te lleva solo. Pero si no conocés el sistema, quedás afuera. Entonces, cuando ve a un turista perdido subirse al bus en el que él viaja, se toma con alegría la oportunidad de ayudarlo a entrar en el sistema.

El Modelo de Lewis

La muy acertada observación de Toti, tiene su reflejo académico en el Modelo de Lewis de Comunicación Intercultural, que clasifica las culturas del mundo en tres grandes estilos de comportamiento:

• Lineal‑activo: personas que planifican paso a paso, hacen una sola tarea a la vez, siguen cronogramas, valoran la puntualidad y la lógica. Es el estilo típico de países nórdicos y aquellos que impulsaron la industria informática.
• Multi‑activo: culturas más emocionales, relacionales, improvisadoras. Realizan varias tareas simultáneamente; priorizan las personas por sobre los procesos formales. Promueven la sociabilidad, la flexibilidad, la persuasión, y una gestión del tiempo policrónica. Alrededor de este polo encontramos a los países latinoamericanos, así como a los que más peso han tenido en definir nuestra cultura: España, Portugal e Italia.
• Reactivo: personas que primero escuchan y luego responden; evitan confrontaciones, valoran la armonía y el respeto. Predomina en Asia oriental.

Esta distinción entre culturas nos puede ayudar a entender por qué las construcciones que funcionan en una cultura lineal, pueden estar destinadas a fallar en una cultura multi‑activa. Como es el caso de las recetas que se suelen aplicar para la transformación digital.

Cuando nada funciona y nada se puede cambiar

En Finlandia, los colectivos cumplen el horario. Todo funciona como un reloj, pero nada se puede acomodar. En cambio, en nuestros países iberoamericanos, los transportes no cumplen el horario, nada funciona del todo… pero todo se puede charlar.

Excepto las cosas que tuvieron la desgracia de ser automatizadas.

Porque los procesos son producto de la cultura que los parió. Y en culturas donde nada funciona pero todo se conversa, informatizar un proceso “formal” cristaliza la parte menos funcional del sistema, justo esa que nunca se seguía. El resultado: sistemas que no funcionan… y que tampoco se pueden cambiar.

Es la peor parte de nuestra cultura, traducida a procesos y codificada con rigidez, la peor parte de la cultura que inventó la informática.

El mundo según la informática

La informática nació en culturas lineales. Culturas en donde el tiempo se entiende como una secuencia ordenada de eventos. En donde entre lo que tengo y lo que quiero, hay pasos que se recorren en orden.

Para nosotros, eso no es evidente. En nuestra forma de ver las cosas:

• las prioridades cambian según la ansiedad del momento,
• entre hoy y mañana puede pasar cualquier cosa,
• el horizonte máximo de planificación es hasta las próximas elecciones,
• y el trámite depende de la persona con quien hablaste.

En nuestro mundo, los procesos no existen realmente hasta que alguien los necesita. Y cuando surge la necesidad, el verdadero proceso se activa: con una llamada, un contacto, un favor, un atajo.

Es algo muy común en nuestros países: el proceso documentado suele ser una abstracción que no describe toda la complejidad del proceso real. Lo que realmente funciona está en la cabeza de cada empleado, que fue armando su parte a fuerza de prueba, error y supervivencia laboral. Los empleados no ejecutan los procesos del sistema: ellos son el sistema.

Cuando el procedimiento es ficción

El problema es que los sistemas informáticos que se proyectan en este contexto, suelen tomar el procedimiento formal como todos los “requerimientos” que hay que considerar para el desarrollo.

Pero el procedimiento que ha documentado el Negocio, muchas veces es más bien un mandato aspiracional: un “deber ser” que no contempla atajos, decisiones informales ni las negociaciones constantes que hacen que el proceso realmente funcione.

El verdadero proceso nace en las personas que tienen que ejecutarlo. Cada una, a su manera, va aprendiendo qué se puede hacer, qué no y cómo compensar los huecos. Lo ajustan con la práctica, con llamadas, con anotaciones en papeles, con “hablá con Marta que ella sabe”.

Aunque una organización tenga una “cabeza”, en nuestras culturas, la verdadera inteligencia que mantiene todo funcionando está distribuida e invisible. Es un poco como el sistema nervioso del pulpo, donde los tentáculos poseen su propia inteligencia: la mayoría de las neuronas (aproximadamente el 60 %) está en los brazos, no en el cerebro central, lo que les permite actuar con autonomía y tomar decisiones locales.

El mayor desafío de la transformación digital, es que las máquinas no pueden improvisar

La mayoría de las organizaciones latinoamericanas no se gestionan con objetivos, sino con declaraciones nebulosas: “hay que terminar esto para mañana”, sin sujeto, sin responsables, sin consecuencias claras.

Nosotros, los humanos, podemos navegar ese mundo. Las máquinas no. Las máquinas necesitan precisión, claridad, estructura. Por eso, los intentos de transformación digital en culturas que viven de la improvisación terminan en sistemas que no sirven, y en personas que buscan cómo rodearlos.

El primer paso de una transformación digital real no es técnico, es cultural. Y requiere sinceramiento: relevar cómo funcionan realmente las cosas, no cómo nos gustaría que funcionaran. Reconocer el proceso real, no el ideal. Entender la red informal de inteligencia que permite que algo tan disfuncional… funcione.

La UX interna y la transformación cultural

Las gerencias construyen en su visión un mundo coherente, que por necesidad no es el que existe hoy: es la visión del futuro. Declaran objetivos, empujan iniciativas, y cuando llegan resultados, consideran que son producto de su visión.

Pero los resultados no vienen de lo que se declara. Vienen del esfuerzo de la organización por hacer algo con eso. Viene de las experiencias, vivencias y decisiones de las personas que trabajan en la organización. Vienen de la UX interna: de lo que los usuarios internos experimentan.

Y ahí entra nuestro rol como consultores de Experiencia de Usuario estratégica. No solo diseñamos sistemas: diseñamos comprensión, y como dice Jorge Arango, somos generadores de coherencia. Construimos puentes entre lo que la gerencia quiere que pase, lo que cree que pasa, y lo que realmente pasa. Ayudamos a ver la inteligencia que fluye por debajo del organigrama. A ver el valor humano y de negocio en la improvisación, en la flexibilidad, en la capacidad de adaptación.

El primer paso de la transformación digital no es “pasar el proceso a la app”. Es conocer y entender los procesos reales. Es mapear cómo realmente funcionan las cosas. Es reconocer que las máquinas necesitan instrucciones claras, y las personas necesitan ser escuchadas.

La transformación digital sólo es posible si se encara como parte de una transformación cultural. Y nosotros, desde la experiencia de usuario estratégica, estamos en una posición única para ayudar a iniciarla.

Santiago Bustelo
Julio 2025

La entrada Transformación digital en Iberoamérica: por qué fallan los modelos del norte se publicó primero en Kambrica.

Sara Beckman, profesora de la Haas School of Business, lo resume en su entrevista para el podcast Finding Our Way de Peter Merholz (cofundador de la mítica Adaptive Path):

“[NPS] no tiene nada que ver con la satisfacción del cliente. No hay correlación entre el Net Promoter Score y la satisfacción del cliente o el aumento de beneficios.

Está mal construido desde el punto de vista estadístico. Elimina dos de las medidas. Ni siquiera es un promedio real.

No es un proxy adecuado para entender si nuestros clientes ahora pueden lograr un resultado mejor que antes. Lo que yo quiero es saber si realmente ayudé a mi cliente a ejecutar los ‘jobs to be done’ que quería que ejecutara.”

Y sin embargo, muchas organizaciones siguen exigiendo a sus equipos de UX que “mejoren el NPS”, como si ese número mágico pudiera guiar el diseño de experiencias. No solo es ingenuo. Es contraproducente.

El problema no es solo el NPS. El problema es pensar que un simple número puede reemplazar la comprensión profunda del cliente, sus decisiones y sus limitaciones. En vez de preguntarnos si el cliente nos recomendaría, ¿por qué no preguntarnos si le hicimos la vida más fácil? ¿Si evitamos fricciones? ¿Si le ahorramos tiempo, pasos, frustraciones?

Lo dije antes en Cargo Culting Management, y lo repito:

Cuando a una cultura de gestión basada en supersticiones le agregamos “métricas”, no obtenemos racionalidad. Obtenemos numerología.

Si lo que medimos no se relaciona directamente con decisiones accionables y cambios concretos en la experiencia, entonces no estamos midiendo: estamos jugando con números.

El diseño estratégico no puede depender de una encuesta de una sola pregunta. Tiene que partir de la comprensión sistémica del valor que generamos –o no– en la vida real de las personas.

NPS suena a gestión. Pero no lo es. Es numerología.

Stop Trying to Make NPS Happen.

La entrada NPS es numerología se publicó primero en Kambrica.

Mi punto es simple: la Dirección UX es al software lo que la Dirección es al cine. Y en la era de la IA, la Dirección UX es un encuadre que nos empodera desde una posición de toma de decisiones, frente a la de “Diseño”, que inevitablemente siempre queda relegada a la ejecución – lo que la tercera ola del diseño digital probablemente se termine llevando de nuestras manos.

Como en el cine, el director UX no necesita ser quien escribe el guion, actúa, opera la cámara o edita. Pero sí tiene que ser quién de forma, sentido y dirección a todo ese proceso para que se convierta en una obra coherente y efectiva, que cumpla con una visión y con objetivos de negocio.

Para lograr nuestra función como Directores UX, tenemos que conocer sobre todas las disciplinas que intervienen – empezando por research, diseño de interacción, diseño de interfaces, lenguaje audiovisual, arquitectura de información, estrategia de contenidos, así como aspectos de marketing, negocio y desarrollo. No necesitamos dominarlas todas operativamente, pero sí entenderlas lo suficiente como para delegar de manera efectiva. Es decir: lograr acuerdos claros, tomar decisiones informadas y construir una visión compartida incluso antes de tener claro cómo será el producto final.

Ese es, para mí, el corazón de la Dirección UX: mantener la visión, despejar el camino, delegar bien y decidir mejor – para lo cual hace falta dominio de metodologías, y ayuda nuestro sistema Experience Decision Making.

No se trata de “saber más” que el equipo, como equivocadamente se plantean muchos jefes. No se trata de mostrar que tenemos más técnica, más herramientas o más experiencia que cada miembro. Se trata de ayudar a que cada uno pueda hacer su mejor trabajo.

Cada persona del equipo sabe que seguramente tiene más dominio técnico que yo. Porque incluso en disciplinas donde alguna vez fui especialista, ya no estoy al día como lo están ellos. Y esa así como debe ser. No es mi rol competir con ellos, es ayudarlos a brillar.

De la misma forma en que un director de orquesta no compite contra el resto de los miembros: su rol es hacer que todos suenen mejor.

Y entonces llegó la IA.

En nuestro equipo, tratamos a la inteligencia artificial como un “ultra júnior”: un asistente que puede hacer algunas tareas útiles, pero que necesita instrucciones muy claras, supervisión intensiva y revisión constante. Porque la IA tiende a desviarse, a inventar, a justificar errores con tono convincente. No es confiable, pero sí útil si se la encuadra bien.

Nos ofrece algo valioso: la línea de base. Lo mínimo esperable. Lo que cualquier persona va a pedirle como primera versión. Y por eso no nos resuelve el trabajo: nos marca la expectativa mínima. A partir de ahí, tenemos que lograr diferenciar y construir valor.

Esto genera un cambio profundo: los roles de menor seniority, ya no son el último eslabón de la ejecución. Ahora tienen que aprender a delegar.

Tienen que aprender a pedirle cosas a la IA. A distinguir entre “que lo haga” y “que esté bien hecho”. Tienen que asumir responsabilidad, no sólo por lo que producen, sino también por lo que hacen otros —aunque ese otro sea una máquina.

Y ese es el motivo por el cual creo que la Dirección UX, como disciplina, es nuestra respuesta al desafío de la IA.

Porque pensar la UX como ejecución ya no alcanza. Necesitamos formar profesionales capaces de dirigir: de pensar en términos estratégicos, de gestionar procesos complejos, de coordinar múltiples especialidades, y ahora también, de integrar inteligencias artificiales en su flujo de trabajo con sentido crítico.

La Dirección UX no es una jerarquía. Es una mirada. Es una responsabilidad. Y es el encuadre que necesitamos para liderar el Diseño en la era de la inteligencia artificial.

Santiago Bustelo
Mayo 2025

La entrada Dirección UX: el encuadre para la era de la IA se publicó primero en Kambrica.

Y hay otros que sólo quieren a alguien que ejecute las decisiones de diseño que ya tomaron.

Para estos últimos, hay un montón de agencias dispuestas a satisfacerlos. Que dicen que sí a todo, que prometen que todo va a salir “lindo y con impacto”, y que están encantadas de ponerse a producir pantallas sin hacer preguntas.

Quienes realmente buscan soluciones entienden, tarde o temprano, que no necesitan a alguien obediente y obsecuente, sino a un socio estratégico.

Una sola reunión suele bastar para saber si somos el equipo correcto.

En Kambrica, partimos de un supuesto simple: si nos están llamando, es porque hay un problema que resolver – aunque no necesariamente esté bien diagnosticado.

En nuestra primer reunión hacemos un análisis preliminar, planteamos con claridad los problemas que podemos resolver, cuál podría ser el impacto, y los procesos, herramientas y recursos necesarios.

Si necesitan competencia y experiencia para resolver un problema real, seguimos hablando.

Si en cambio, buscan a alguien que ejecute ciegamente lo que ya decidieron —y que después se lleve la culpa para cuando no funciona—, para cuando llegan a nosotros ya hablaron con dos o tres agencias dispuestas a sacarse los ojos por agarrar el proyecto. Nosotros no competimos por ese lugar.

Si estás buscando un socio estratégico —si necesitás resultados en lugar de promesas y excusas—, con 30 minutos alcanza para saber si podemos trabajar juntos.

¡Escribinos y coordinemos agenda!

La entrada Diseñamos para cambiar comportamientos. se publicó primero en Kambrica.

Últimamente, muchas personas vienen están descubriendo —con cierto pánico– que la Ley Europea de Accesibilidad ya está por entrar en vigencia. Y de repente, se ven corriendo detrás de deadlines, tratando de “incorporar” accesibilidad a sus productos antes del 28 de junio.

Tal vez también lo hayan visto. Gente preocupada porque “ahora los sitios van a quedar todos iguales”, o porque “va a ser más difícil mantener la identidad de marca”. Como si la accesibilidad recién llegara – y nada menos que para arruinarles el diseño, que tan lindo les había quedado.

Es una reacción más común de lo que debería. Y es ahí donde se hace evidente: muchas de esas personas nunca estuvieron haciendo diseño UX.

Diseñaban pantallas. Interfaces. Look & feel. Cosas que su cliente aprobaba y pagaba. Pero no UX.

Porque no hay experiencia de usuario sin usuarios. Y eso siempre incluyó a todas las personas.

La deuda no es nueva. Es antigua. Y técnica.

El primer borrador de las WCAG (las pautas de accesibilidad para contenido web) es de 1999. Para la norma ISO 9241–210, que define formalmente la experiencia de usuario, un diseño que ignora la accesibilidad no puede considerarse que brinde una experiencia de usuario de calidad.

Esto no es una novedad. No es una moda. No es un nuevo desafío del diseño digital. Es una deuda profesional que muchas personas están descubriendo… ahora.

¿Cómo llegamos a esto?

Es buena parte, es el resultado de al menos 10 años de devaluación de la disciplina. Cuya última estación han sido los “cursos de UX” que omiten por completo la accesibilidad. Porque es “aburrida”. O sea que esos “cursos” no buscaban formar: buscaban entretener.

Escuelas piramidales en donde dan clase personas egresadas la semana anterior, sin haber tenido contacto con prácticas reales, proyectos complejos ni contextos diversos, sin poder transmitir lo que no conocen: experiencia, estándares, normas, historia, ni contexto.

Así, mucha gente fue llevada a creer que hacía UX… cuando en realidad hacía otra cosa. Y no es culpa de quienes quieren aprender. Es culpa de quienes se aprovecharon de su entusiasmo.

Mentoría para profesionales despiertos

Por suerte, cada vez más profesionales están despertando. Quieren hacer UX de verdad. Quieren entender qué significa diseñar para todos. Quieren mirar más allá de la pantalla.

Y eso es algo para celebrar.

Porque no se trata de cumplir con una norma, sino de diseñar con respeto, con criterio y con impacto real.

Muchos profesionales con experiencia estamos disponibles para ayudar, acompañar, enseñar, darles mentoría y ayudarles a resolver lo que sea que tengan entre manos. 

Y si están leyendo esto, es porque probablemente también estén entre quienes quieren hacer UX en serio. Entre quienes no están buscando atajos, sino profundidad.

Contar con el apoyo de más de 20 años de experiencia en accesibilidad, está a un clic de distancia.

La entrada Si alguien recién está descubriendo la accesibilidad, no estaba haciendo UX. se publicó primero en Kambrica.

Las dos personas están expresando su intención de hablar con la otra. Pero la tecnología telefónica digital replicó las formas del siglo diecinueve, impidiendo satisfacer esa intención.

En WhatsApp, en cambio, decidieron que si dos personas se llaman simultáneamente, ambas reciban una notificación de llamada entrante. La primera que responda establecerá la conexión, mientras que la otra verá que la llamada no se pudo completar. A diferencia de las líneas telefónicas tradicionales, donde ambas partes recibían una señal de ocupado, WhatsApp gestiona estas situaciones permitiendo que la comunicación que ambas partes declaran tener, se establezca correctamente.

Eso es UX: entender la intención y definir cómo satisfacerla. Dibujar pantallas es secundario y no define la profesión: es para un diseñador UX algo tan accesorio como lo son un arquitecto la Rotring y la regla paralela.

La entrada La Experiencia de no escuchar tuu tuu tuu se publicó primero en Kambrica.

Errores comunes en la incorporación de talento UX: los 10 fallos más frecuentes

Estos errores pueden afectar directamente la calidad de los resultados, retrasando el impacto positivo que UX puede generar en productos, servicios y en el negocio en general. Sin embargo, son completamente evitables si se cuenta con el apoyo adecuado y una estrategia de UX bien definida.

¿Estás seguro de que tu empresa está evitando los errores más comunes al contratar UX?

Errores comunes al contratar y gestionar perfiles UX:

1. Asignar a una sola persona todas las responsabilidades UX.
2. Contratar perfiles sin la experiencia adecuada por desconocer los roles y niveles de seniority.
3. Reducir UX a diseño visual o de interfaces.
4. Integrar UX sin una estrategia clara ni objetivos de negocio razonables.
5. Colocar UX bajo IT o Marketing.
6. No haber adoptado metodologías ágiles en IT antes de incorporar UX.
7. Tratar a UX como un silo, sin conexión con otras áreas.
8. Intentar “evangelizar” sin experiencia suficiente ni respaldo organizacional.
9. Esperar resultados inmediatos sin entender la evolución del proceso.
10. No contar con apoyo experto.

Si tu empresa está en el proceso de incorporar e integrar recursos UX, te invitamos a revisar esta lista. ¿Te reconoces en alguno de estos puntos? No estás solo: son errores comunes cuando desde áreas de negocio, como Recursos Humanos, se aborda la integración de UX sin la guía técnica experta necesaria.

¿Te gustaría optimizar tu estrategia UX?

Si querés diferenciarte de tu competencia, aprovechar mejor la iniciativa estratégica de incorporar UX, y optimizar tu inversión en recursos humanos, pongámonos en contacto para agendar una reunión. Podemos ayudarte a sacar el máximo provecho de tu estrategia UX y evitar los errores que frenan el crecimiento de tu negocio.

Los 10 errores más frecuentes, en detalle

1. Asignar a una sola persona todas las responsabilidades UX.

Muchas empresas buscan un perfil que se encargue de todo: desde research, ideación, Design Thinking, pruebas de usabilidad, wireframes, prototipado, diseño UI pixel-perfect, maquetado HTML y CSS responsive, desarrollo front-end JavaScript, redacción, documentación, hasta evangelización, metodologías ágiles, gestión y estrategia UX.

Eso no es un perfil UX, sino un equipo de varias personas. Y una de esas personas debe ser alguien con competencia técnica, experiencia, visión estratégica y habilidades de gestión para liderar ese equipo. Sin dirección propia, el equipo UX terminará desmembrado por los intereses de las distintas áreas de la organización.

2. Contratar perfiles sin la experiencia adecuada por desconocer los niveles de seniority.

Muchas organizaciones cometen el error de contratar perfiles sin comprender adecuadamente los diferentes niveles de seniority UX, y qué le cabe a cada uno. Esto suele resultar en una falta de alineación entre lo que la empresa necesita y lo que el profesional UX puede ofrecer.

Perfiles junior o semi senior, por ejemplo, a menudo son contratados para tareas que los exceden, o que requieren de la supervisión de un profesional de mayor experiencia en UX. Contratar el perfil adecuado según el nivel de seniority es crucial para evitar errores que afecten el rumbo de los proyectos.

3. Reducir “UX” a diseño visual o de interfaces.

Limitar UX exclusivamente al diseño visual es un error común que ha surgido con la popularización de la disciplina, que no siempre ha estado acompañada de la difusión de su verdadero alcance y fundamentos.

Aunque la creación de artefactos visuales es una de las funciones más evidentes de UX, es sólo la punta del iceberg. La norma ISO 9241–210, que define el término “experiencia de usuario”, subraya que abarca mucho más que el diseño visual: incluye la efectividad, eficiencia y satisfacción del usuario al realizar tareas. Esto requiere comprender y cuantificar lo que los usuarios experimentan al interactuar con un sistema.

Reducir UX a lo visual es una mala inversión, ya que no logrará soluciones efectivas ni alineadas con los objetivos de negocio.

4. Integrar UX sin una estrategia clara ni objetivos de negocio razonables.

Cuando las áreas de negocio definen “objetivos” para UX sin una estrategia UX clara, ni un marco racional de decisiones de diseño como Experience Decision Making (XDM), el resultado suelen ser metas poco realistas que confunden objetivos con requisitos o deseos.

Para generar un impacto real, UX debe estar alineada con los objetivos empresariales — no sólo como una función operativa, sino como un motor estratégico en la toma de decisiones y el rendimiento del negocio.

5. Colocar UX bajo Marketing o IT.

Marketing se enfoca en atraer clientes, y IT en la viabilidad técnica. UX tiene un rol distinto y complementario a ambas: garantizar que las soluciones sean efectivas, eficientes y satisfactorias para las personas.

Si UX depende de Marketing, se limitará a diseñar campañas y landing pages; si depende de IT, terminará resolviendo tickets.

UX necesita tener su propio espacio y autoridad para aportar desde la estrategia.

6. No haber adoptado metodologías ágiles en IT antes de incorporar UX.

Si una organización sigue operando con una mentalidad de cascada, es probable que vea el UX Research como un obstáculo, partiendo de la falsa premisa de que el plan ya está cerrado y solo falta ejecutarlo.

Para que UX sea efectivo, el proceso de desarrollo de software debe estar basado en metodologías ágiles que permitan iterar y tomar decisiones fundamentadas en evidencia. Sin este cambio de enfoque, el diseño terminará siendo solo una capa estética final sin impacto real en la experiencia del usuario.

7. Tratar a UX como un silo, sin conexión con otras áreas.

La experiencia de usuario no es un “producto del área de UX”, sino lo que el usuario final experimenta: el resultado de todas las decisiones tomadas por las diferentes áreas involucradas. Si el producto surge de una mala política comercial, ningún “diseño de pantallas” podrá solucionar la desconexión entre lo que se ofrece y lo que los clientes están dispuestos a aceptar.

“Tener un área de UX” no mejora automáticamente la experiencia del usuario final, especialmente si esta área se limita a ser un equipo de “delivery”, que se dedica únicamente a ejecutar decisiones sin cuestionarlas.

Para que UX tenga un impacto real, debe estar presente en todas las fases del proceso, influyendo en las decisiones comerciales, tecnológicas y estratégicas desde el principio. Solo así se garantiza una experiencia de usuario coherente y alineada con los objetivos de negocio.

8. Intentar “evangelizar” sin experiencia suficiente ni respaldo organizacional.

Pedirle a alguien con poca experiencia que “evangelice” sobre UX dentro de la empresa es una iniciativa bien intencionada, pero condenada al fracaso.

Para que UX gane espacio y se establezca de manera efectiva, la “evangelización” debe provenir de una persona con autoridad, trayectoria y la capacidad de dialogar de igual a igual con las áreas clave.

Sin una base conceptual sólida, experiencia ni respaldo organizacional, las ideas de UX no tendrán el impacto necesario para ser tomadas en cuenta de manera significativa.

9. Esperar resultados inmediatos sin entender la evolución del proceso.

UX no es magia. No es contratar a alguien hoy y ver resultados al día siguiente. Como toda disciplina estratégica, requiere tiempo para diagnosticar, comprender el negocio y generar cambios reales.

Además, gran parte de esos cambios son culturales: impactan el enfoque y los procesos de las áreas existentes. Al igual que ocurre con la incorporación de áreas como Seguridad o Ética, el éxito de UX no depende solo de su implementación, sino de su integración y adopción dentro de la organización.

10. No contar con apoyo experto.

Muchas empresas intentan buscar, seleccionar e incorporar profesionales UX sin contar con el asesoramiento estratégico suficiente, ni programas de capacitación y mentoría proporcionados por profesionales con experiencia en los desafíos específicos que enfrenta la organización.

Sin las distinciones adecuadas, los esfuerzos no sólo fracasan en generar resultados, sino que los problemas suelen detectarse recién cuando ya son demasiado grandes para ignorarlos, haciendo que su solución sea aún más compleja y costosa.

¿Querés evitar estos errores al contratar talento UX?

Si tu empresa enfrenta alguno de estos problemas en sus iniciativas de contratar talento UX, podemos ayudarte a solucionarlos. En Kambrica ofrecemos consultoría estratégica, capacitación y mentoría para incorporar profesionales e integrar UX de manera efectiva en tu organización, acompañándote en su crecimiento, evitando errores comunes y maximizando el impacto en los resultados de negocio.

¿Te identificaste con alguno de estos puntos? ¿Tu empresa también ha atravesado estas dificultades? Te ofrecemos un enfoque estratégico y personalizado, para entender tus necesidades específicas, sin propuestas genéricas enlatadas.

¿Nos ponemos en contacto para hablar de cómo incorporar y proyectar UX en tu organización?

La entrada Los 10 errores más comunes al contratar UX en una organización se publicó primero en Kambrica.

Por eso, yo prefiero decir: “lo que no se entiende, no se puede gestionar”.

Porque buena parte de las cosas que tenemos que orquestar son de naturaleza cualitativa. Los números no necesariamente las describen. Muchas veces sólo miden lo que es posible o fácil medir, no lo que realmente importa.

Creer que medir tiene valor en sí mismo, es una forma de superstición. Sin comprensión, sin contexto, los números carecen de significado. Un buen gerente no persigue mejores cifras sin más, sino que entiende qué las genera y cómo intervenir estratégicamente.

Entender las partes y sus relaciones, es lo que distingue a un verdadero Gerente, de alguien que se maneja con la superficialidad.

Porque gestionar no es pretender que los números sean mayores que ayer. Gestionar es decidir mejor.

Santiago Bustelo
Febrero 2025

La entrada Medir está sobrevalorado. Un 173.19%. se publicó primero en Kambrica.

Si un equipo de desarrollo o una organización aún opera con mentalidad de cascada, es lógico que vea el Research como un obstáculo en lugar de una inversión. Para ellos, ya hay un plan definido, y cualquier tarea adicional solo “retrasa” la ejecución.

El problema es que esta mentalidad asume que ya saben qué construir, sin cuestionarse si eso realmente resolverá el problema, o incluso sin detenerse a considerar cuál es el verdadero problema a resolver.

Desde la mentalidad de cascada, es inevitable ver al diseño como algo estético y que se pretenda incorporarlo al final, cuando ya todo esté decidido. No se puede concebir que el diseño pueda desafiar el modelo mismo del sistema, como en el caso de que la investigación y el diseño de interacción planteen la necesidad de una función de “deshacer”, que no es una pantalla bonita sino un cambio en la arquitectura y la lógica de negocio.

Si se intenta incorporar UX al final, lo que se terminará incorporando no será UX.

Porque la realidad es que la consultora fundada por Don Norman –quien acuñó el término “User Experience”– advierte desde 2014 que sin UX Research, no hay UX.

En el mejor de los casos, habrá tan sólo UI: la interfaz. Y en el más usual, habrá una capa estética superficial tratando de maquillar el chancho de decisiones de diseño cometidas por personas de negocio, marketing o IT sin formación en la toma de decisiones de Diseño — sin siquiera saber que lo que estaban cometiendo, eran decisiones de Diseño.

“No tenemos tiempo” para hacer Research, significa “todavía no estamos preparados”

Cuando los decisores dicen que “no tienen tiempo” para hacer UX Research, lo que realmente están diciendo es que todavía no lo han hecho ni entendido su valor: el Research sería “una pérdida de tiempo”.

Si lo entendieran como lo que es –como algo crítico para construir software que resulte aceptado y realmente productivo– , encontrarían el tiempo.

Y para eso, es necesario primero entender que el usuario no es esa cosa molesta entre la silla y el teclado. El usuario es lo que le da sentido al software: porque sin usuarios no hay software, sólo instrucciones que nunca se ejecutarán y datos que nadie verá, ocupando lugar en algún medio de almacenamiento.

Y es la filosofía Lean, base de la agilidad, la que postula que valor es lo que el cliente final, el verdadero usuario, valora. Todo lo demás es desperdicio.

El manifiesto ágil fue redactado en febrero de 2001: en estos días, cumple 24 años.

Los ingenieros que han ignorado todo este tiempo la buena nueva que sus colegas les han presentado, difícilmente estén preparados para recibirla de manos de diseñadores, que ven como esa especie inferior que en lugar de estudiar una carrera en serio, se dedicó a aprender qué color combina con cuál.

Como profesionales, en Kambrica valoramos nuestro tiempo y el de nuestros clientes. Por eso, en nuestro primer encuentro, es clave entender si podremos construir una relación de valor o si, simplemente, no somos el proveedor que necesitan en este momento.

Hoy, el mejor indicador de si un proyecto será exitoso no es el presupuesto ni la cantidad de features que quieren diseñar, sino el nivel de madurez del equipo y la organización en metodologías ágiles.

Si el equipo aún no ha integrado la agilidad en su cultura de trabajo, es poco probable que pueda aprovechar UX estratégico. Porque sin ciclos iterativos y toma de decisiones basada en evidencia, el diseño se reduce a pintar pantallas y acomodar lo que ya fue decidido de antemano. Y ese no es el tipo de valor que ofrecemos.

UX estratégico para equipos maduros

Si este enfoque resuena con la cultura de tu organización, con tu equipo y con la manera en que quieren encarar su proyecto, entonces vale la pena que nos conozcamos. En Kambrica, trabajamos con equipos que buscan más que pantallas bonitas: transformamos la manera en que se toman decisiones para generar impacto real.

En los más de 25 años que llevamos en la industria, hemos confirmado una y otra vez que los proyectos exitosos (versus los que salen mal o que incluso se abandonan) no nacen de “briefs geniales”, ni de ejecutar sin más lo que el cliente pide. Lo que trae quien nos contrata no es una solución, sino un síntoma y una hipótesis. Si tomáramos su pedido como un plan cerrado, le estaríamos delegando las decisiones de diseño y la responsabilidad de sus consecuencias. Pero eso no es un servicio, es una renuncia. La verdadera diferencia no está en hacer pantallas, sino en diseñar sistemas que resulten adoptados por los usuarios, y que impulsen los comportamientos que crean valor.

Si en tu organización también quieren ir más allá de lo superficial, y trabajar en soluciones que realmente muevan la aguja, conozcámonos.

La entrada Para incorporar UX, la agilidad IT es condición necesaria. ¿Estás preparado? se publicó primero en Kambrica.

La tecnología no ocurre por sí sola.
La tecnología no tiene propósito sin usuarios.

La única manera de que la experiencia de usuario no exista, es que no haya usuarios.

Y sin usuarios, sin valor, sin propósito, no habrá tecnología: solo curiosidades técnicas.

Entonces, en el proceso de desarrollo de tecnología IA — la que involucra a los usuarios — , ¿quién creen que está y estará a cargo de modelar la personalidad y los modales de la IA?

Independientemente del título que le asignen a eso… seguirá siendo UX.

La entrada La IA, y específicamente las interfaces conversacionales, no “están matando” ni “van a matar” UX. se publicó primero en Kambrica.

Hace unos 10 años, nos contactó una empresa de TV.

–Queremos tener LA MEJOR usabilidad.
–Perfecto, lo primero sería replantear el control remoto…
–No no no, eso no se puede. Ya está decidido.
–¿Lo decidieron ustedes?
–No, la gerencia de Compras. Ya licitaron al mejor postor en China.

Ellos creían que usabilidad y Experiencia de Usuario eran algo que se podía comprar y agregar al producto ya cometido, sin cuestionar decisiones previas. Para ellos, “la mejor usabilidad” era simplemente una expectativa hacia nosotros: un requerimiento más. Como decir: “Más vale que hagan un excelente trabajo.”

Pero esa declaración debería haber sido algo mucho más profundo: un compromiso de su parte, habilitándonos a cuestionar los procesos que terminaban castigando al usuario final.

Este tipo de situaciones no son raras en UX. Uno de nuestros mayores desafíos es que muchos comitentes no cuentan con referencias previas sobre UX como disciplina fundamentalmente estratégica. Y por eso, nos confunden con otras áreas “parecidas” con las que ya han trabajado, que pueden ejecutar pedidos sin cuestionar el impacto que tendrán en lo que los usuarios finales experimentarán:

• Por un lado, Sistemas, que puede tomar “requerimientos no funcionales” sin preocuparse por la experiencia final, mientras el sistema siga funcionando.
• Por otro, Marketing y Comunicación, que pueden publicar lo que sea porque lo ven sólo como un problema discursivo.

Pero por definición, UX no puede funcionar así. Lo que los usuarios finales experimentan es el resultado de una cadena de decisiones. Mejorar la UX requiere analizar y mejorar en primer lugar las decisiones de negocio que condicionan negativamente las decisiones de diseño.

Por ello, es imposible “hacer una buena UX” cuando el comitente no está dispuesto a asumir un compromiso con el proceso para lograr resultados. Tal vez por eso tantas agencias hayan decidido abandonar o ignorar la profundidad de UX (desde las definiciones de Don Norman y la ISO 9241) para ofrecer algo más cómodo: “decimos que hacemos UX, pero en realidad entregamos UI”.

Así es como comitentes como el de esta historia, terminan cayendo en el engaño de agencias que les prometen: “No te preocupes, acá hacemos lo que vos querés sin cuestionarte”.

El resultado es el que todos conocemos: menos UX y más controles remotos genéricos, llenos de botones inútiles. Bah, inútiles para nosotros: están ahí para satisfacer a alguno de los otros 50 a 100 contratos que firmó el fabricante. Están ahí para pagarle el bono por buen desempeño a un gerente de ventas en China.

Esto no es solo un problema técnico. Es fallar en el núcleo de UX y CX: el desarrollo de una filosofía sobre cómo queremos tratar a la gente para poder impulsar relaciones de valor.

Es fallar en entender la paradoja que la teoría económica de W. Edwards Deming prevé desde la década de 1950: al poner foco en costos, los costos finales aumentan. Porque en lugar de invertir en calidad (lo que el cliente final valora) y construir activos, se destina presupuesto al “desperdicio” barato (lo que el cliente final rechaza). Ello requiere de constantes medidas paliativas, erosiona a la marca y la relación con los clientes, y deja los flancos descubiertos para el desembarco de la competencia.

Entender UX como disciplina estratégica, se trata de evitar esos costos y esos riesgos.

La entrada A veces, la experiencia de usuario la decide un gerente de compras… mirando ofertas chinas. se publicó primero en Kambrica.

El mito de la juventud digital arrancó con fuerza a principios de los ’80, cuando la informática se propuso conquistar los hogares. Para el desembarco, no alcanzaba con publicidad: había que estar en primera plana.

Es así como prensa e industria encontraron un mito fundacional que podían explotar para mutuo beneficio: retratar a los entonces veinteañeros Steve Jobs y Bill Gates como los “enfants terribles” que habían dejado la universidad para revolucionar una industria estancada por “viejos” y “académicos”.

El mito fundacional de los jóvenes maravilla vendía más diarios y computadoras que contar la historia real: quienes habían desarrollado las tecnologías que Apple y Microsoft comercializaban era gente como Jef Raskin y Gary Kildall, “veteranos” cuarentones con una sólida formación en matemáticas y maestrías en Ciencias de la Computación.

Un buen periodista nunca deja que la realidad le arruine una buena noticia

El periodismo es, mayormente, un género de ficción libremente basado en hechos reales. Resultaría una forma inofensiva de entretenimiento, si no fuera porque moldea decisiones que gente incauta toma en la vida real.

Es el caso de clientes y gerentes que aplican como certeza el mito de la tecnología como cosa exclusiva de la juventud, incluso por sobre la experiencia en el campo. Pareciera ser que el día en que cumplís 40 años, se te funde alguna parte mágica del cerebro que “conecta” con “lo digital”. Más de un selector de Recursos Humanos dejaría de leer un CV luego de ver que la fecha de nacimiento es 1969. Sin duda, a ese candidato ya se le acabó la nafta y no tiene nada que ofrecer:

La realidad es que los chicos que están entrando a la universidad, los “nativos” digitales, los que “respiran” la tecnología desde la cuna… bueno, resulta que estos chicos no saben cómo usar Word. Hiperventilan con sólo ver la grilla de un Excel.

Que la actual tecnología de consumo se pueda usar sin siquiera saber leer, no es mérito de los “nativos digitales”. Sino de quienes les llevamos 20, 30, 40 o más años de ventaja diseñando cosas que les resulten cada vez más fáciles de usar.

Mis padres nunca se interesaron en usar la ZX-81 que me regalaron. Para ellos, la Olivetti era más práctica: apretaban una tecla y la palabra se imprimía. El ritual que yo tenía que hacer para cargar un rudimentario procesador de textos les resultaba inconcebible.

Quienes nacieron con un dispositivo táctil a la mano, tienen una experiencia de uso tan práctica como la de mis padres: si quieren escribir, tocan el icono de la App en la pantalla, y a continuación, escriben.

Al igual que mis padres, los “nativos digitales” no necesitan entender la diferencia entre memoria y almacenamiento, RAM, ROM, diskette, disco duro, local o en la red. Nunca tuvieron que devanarse los sesos para ahorrar un precioso puñado de bytes. Ni tuvieron que sufrir por las incompatibilidades entre diferentes sistemas de codificación de texto (lo cual Excel recién terminó de resolver ¡hace menos de 10 años!).

Este alivio que viven, es producto del trabajo de quienes ya teníamos por lo menos 20 o 30 años a fines del siglo pasado, cuando Jef Raskin publicó “The Humane Interface”. Allí, proponía diseñar sistemas que no obligaran a los usuarios a manejar tecnicismos básicos como directorios y archivos, al punto que ni siquiera existiera la necesidad de “guardar” un “archivo”, porque el sistema estaría diseñado bajo la premisa de preservar de manera transparente el trabajo del usuario.

Las tecnologías difíciles crean personas fuertes, las personas fuertes crean tecnologías simples, y las tecnologías simples crean centennials.

La familiaridad con la tecnología no es producto de la juventud. Es el fruto del trabajo de quienes fuimos marcados por tecnologías difíciles, que pudimos adquirir desde nuestra infancia la capacidad de entenderlas en su progresiva complejidad, de domarlas y mejorarlas, y de crear tecnologías simples para mejorar la condición humana.

Quienes empezamos nuestro camino programando microcomputadoras de 8 bits no sólo somos testigos y protagonistas de los éxitos y fracasos de nuestra industria en las últimas décadas: conocemos sus causas humanas, independientes de la tecnología y del momento.

Somos los pioneros de las disciplinas de Experiencia de Usuario, de las prácticas, metodologías y tecnologías que hoy se consideran estándares. Somos quienes forman y dirigen a las personas y equipos que logran resultados. Somos la nueva generación de profesionales que pasaron los 40 años y trabaja tras las cortinas, a espaldas del periodismo sensacionalista.

Somos los expertos capaces de ayudar a nuestros clientes a tomar mejores decisiones.

Quienes en cambio, basan sus decisiones en artículos periodísticos de medios masivos apuntados al mínimo común denominador, terminan redescubriendo uno de los principios fundamentales de la informática: garbage in, garbage out.

La entrada Edadismo digital: el fraude que no envejece cumple 40 años se publicó primero en Kambrica.

1. “Un DNI válido tiene exactamente ocho caracteres”

Quienes cometieron el sistema bancario que muestro decidieron que un DNI debe tener, sí o sí, ocho caracteres. Si se ingresan sólo siete dígitos, el sistema no permite avanzar.

Para tomar esa decisión, ¿consultaron alguna normativa, revisaron la base de clientes, o realizaron cualquier otra actividad que permitiera una decisión basada en evidencia? ¿Salieron en algún momento de la caverna platónica desde la que programan?

No. Si lo hubieran hecho, se hubieran encontrado con miles de casos como el de mi madre, quien cobra su jubilación en ese mismo banco… y tiene un DNI de tres millones. O sea, 7 dígitos.

“Entonces tu mamá tendrá que poner un cero adelante”, podría decir el analista funcional cavernario responsable (¿?), ignorando que:

• las personas usuarias no tienen por qué adivinar requerimientos que no existen en el mundo real, sino que salieron de la galera del programador de turno.
• es muy poco probable que a una persona de más de 70 años se le ocurra probar semejante ridiculez.

En mi experiencia facilitando y observando sesiones de usabilidad con adultos mayores, cuando ingresan sus datos correctamente y el sistema no los deja avanzar, rara vez modifican la información. En lugar de eso, el 99% de las veces elaboran hipótesis, sospechas y quejas resignadas sobre el sistema, el banco o el gobierno de turno.

No es un problema “generacional”. Es una cuestión básica de accesibilidad, de un sistema que margina a sus usuarios y los obliga a depender de un tercero para actividades de su vida diario. Un sitio que des-habilita, reforzando estereotipos estúpidos como éste:

El supuesto de que todos los DNIs deben tener 8 caracteres es una decisión que los programadores tomaron basándose en sí mismos como referencia. No hubo una consideración real hacia las personas usuarias que deberían operar el sistema.

Los programadores son una de las profesiones más alejadas del público. Dentro de los equipos que desarrollan software, ocupan los últimos puestos del ranking de la empatía. Es común que no tengan conciencia de que están reemplazando sistemas de atención al público, ni de las disciplinas que abordan la calidad de atención en el software. Lamentablemente, aún hoy existen equipos donde, por falta de madurez, dirección y roles apropiados, los programadores son los únicos responsables de las decisiones de diseño de interacción — creando sistemas sesgados, inflexibles y hostiles que se infligen sobre las desafortunadas personas usuarias.

2. “El número de DNI es único”

Suele sorprender que el número de DNI argentino no sea único. Pero, ¿por qué la sorpresa? El hecho de que existan pares de personas con el mismo número de DNI no derriba una definición formal. Simplemente se opone a una creencia que nosotros habíamos asumido.

Como profesionales del software, no deberíamos sorprendernos cuando nuestros supuestos se revelan inválidos. Más bien, deberíamos mantener una postura de prudente sospecha sobre todo lo que creemos saber.

Que existan colisiones de números de DNI resulta bastante razonable cuando consideramos cómo surgieron. Cuando a principios del siglo XX se empezaron a asignar números de documento (en ese entonces, la Libreta de Enrolamiento), no existían ni internet ni telecomunicaciones fiables. Sin un mecanismo de sincronización, la correlatividad de los documentos quedaba librada a la suerte. La posterior creación de la Libreta Cívica para el voto femenino, con su propia numeración, complicó más las cosas.

Recién con la digitalización de los registros en las décadas de 1980 y 1990 se pudo normalizar la situación. Y es así que se encontraron millones de números de DNIs asignados a más de una persona. AFIP y ANSES decidieron que la única solución era hacer “borrón y cuenta nueva”. Es así como crearon en 1990 el número de CUIT/CUIL. En donde la “U” es de “Único”, cosa que el DNI no es.

Una de las primeras cosas que hacemos en Kambrica cuando evaluamos sistemas de atención al público, CRMs, etc., es observar si el sistema se basa en el falso supuesto de que los números de DNI son únicos, y si existe algún mecanismo para resolver colisiones. Generalmente, no lo hay, y a la pobre persona afectada no le queda más que jorobarse.

“Mala suerte”, dirá el analista funcional cavernario del capítulo anterior. No, no es mala suerte. Es ignorancia, soberbia y negligencia de quienes tienen el gran poder de definir cómo funcionan y se comportan los sistemas.

No podemos construir sistemas sobre falsedades

Quienes definimos el comportamiento de los sistemas que utilizarán otras personas no podemos caer en la soberbia de considerarnos la medida de todas las cosas, ni basarnos en lo que “nos parece”. Cada decisión de diseño de sistemas debe ser sólida y fundamentada en evidencia. De lo contrario, estaremos bloqueando a usuarios legítimos solo por ignorancia.

A más de diez años de promulgada la Ley N° 26.653 de Accesibilidad Web, trabajar sobre supuestos no sólo es chapucero e inadmisible: puede ser ilegal.

Para no caer en falsos supuestos, no hace falta que seamos infalibles, que lo sepamos todo. Tenemos al alcance de los dedos la posibilidad de resolver cualquier duda. Y de hecho, la aprovechamos continuamente… cuando somos conscientes de nuestra falibilidad.

Ningún programador se lanza a escribir miles de líneas de código sin consultar cada tanto la documentación o la web. Porque, si no lo hace, es casi seguro que el código no funcionará: ningún programador es, ni debe creerse, infalible al escribir código. Como dice Joel Spolsky, es más difícil leer código que escribirlo – y es por eso que es mejor encontrar los bugs lo antes posible.

Lo mismo ocurre con los supuestos sobre los cuales construimos el comportamiento de los sistemas. Nunca podemos caer en la soberbia de considerarnos infalibles en nuestro conocimiento sobre cómo funciona el mundo. Las personas usuarias merecen que investiguemos los requerimientos y supuestos que las afectan, tanto como las máquinas merecen que consultemos argumentos y funciones.

Santiago Bustelo
Septiembre 2024

La entrada Falsedades que los programadores creen sobre los DNIs se publicó primero en Kambrica.

¿Qué son realmente los requerimientos? ¿De dónde salieron?

Los “requerimientos” vienen de cuando en los principios de la informática, había que informatizar métodos o procesos establecidos y bien definidos.

Por ejemplo, los pasos a cumplir para liquidar correctamente un impuesto o para trazar trayectorias balísticas. Si el programa no seguía esos pasos al pie de la letra, alguien podía terminar con una multa, preso, o muerto.

Los requerimientos eran originalmente eso. Cosas que el cliente pedía a los programadores, que debían ser cumplidas tal cual se las solicitaba.

Como en esa época todo lo que los clientes podían solicitar eran estrictamente requerimientos (porque no había espacio para nada más), por metonimia se empezó a llamar “requerimiento” a cualquier cosa que los clientes pudieran pedir.

Y se los siguió llamando así, aún cuando los clientes empezaron a solicitar cosas que ya no eran, realmente, requerimientos. Ya no eran cosas que no se podían negociar. Eran sus propias ideas o deseos.

Los “requerimientos” alimentan incentivos perversos

Es así que hoy, los verdaderos requerimientos –la información sobre métodos o procesos establecidos que no se pueden cuestionar– puede representar menos del 1% de un proyecto.

El resto son ideas que nos trae el cliente. Estas ideas pueden variar desde solicitudes más o menos concretas (“necesitamos una App”, sin haber evaluado si el mercado tendría interés en ella), hasta caprichos (“que sea disruptivo”, “que tenga IA”).

Cumplir con los “requerimientos” se ha convertido en un ejercicio de evitar conflictos, no en crear software útil. Un proyecto de software sin objetivos bien definidos, en el que ni siquiera el cliente entiende lo que está pidiendo, está condenado al fracaso. Pero no es que los programadores no sepan que los pedidos son irracionales; es que a nadie le conviene ser quien le diga al emperador que está desnudo.

El modelo de negocios basado en cobrar por hora genera incentivos perversos para las agencias y software factories. A ninguna le conviene corregir a sus clientes cuando se están equivocando. En otras palabras, lo común en la industria es tratar a los clientes como adversarios, algo que fácilmente se disfraza de “profesionalismo” pretendiendo que cumplir con los supuestos “requerimientos” es hacer un buen trabajo.

Un modelo de negocios distinto: un modelo honesto.

Los modelos de negocio basados en “requerimientos” no sólo son anticuados: son perjudiciales. Hace más de veinte años que el Manifiesto Ágil declaraba: “colaboración con el cliente sobre negociación contractual”. La noción de “requerimientos”, de enunciados que no se pueden observar ni cuestionar, socava ese principio.

En Kambrica, nuestra misión es articular estrategia y experiencia para lograr software funcionando (versus desperdicios: inversiones y esfuerzos que no generan valor), aceptado y adoptado por usuarios reales (versus impuesto, resistido o rechazado), y cumpliendo objetivos de negocio (versus caprichos y fracasos).

Por eso, nuestro modelo de negocios está basado en compromisos que muy pocas agencias están dispuestas a asumir:

• Ser honestos y transparentes en todas nuestras interacciones, evitando cualquier forma de desinformación.
• Proporcionar recomendaciones efectivas basadas en el juicio profesional calificado, sin sugerir ni aceptar nada que pudiera beneficiarnos comercialmente a expensas de generar perjuicios o desperdicios para nuestro cliente.
• Ayudar a nuestros clientes a tomar decisiones informadas que reduzcan desperdicios, riesgos e incertidumbre, y maximicen el valor, incluso si esas decisiones pudieran implicar un perjuicio comercial para nosotros.

Creemos que la Tecnología, con mayúscula, es lo más humano que hay: el ser humano moderno es el producto del proceso de co-evolución que comenzó con el Homo habilis y las herramientas que desarrolló.

Las primeras herramientas que hemos encontrado tienen más de 2 millones de años, cuando no existía el Homo Sapiens: fueron obra de las especies que nos precedieron. Esas herramientas permitieron a nuestros antepasados obtener nutrientes a los que otras especies no pueden acceder. Y el círculo virtuoso que se dio entre el mayor acceso a nutrientes y el desarrollo cognitivo necesario para lograr ese acceso, fue dando lugar a la naturaleza humana actual.

Por eso, creemos que crear Tecnología, con mayúscula, solo es posible desde un compromiso genuino con nuestros clientes, con la comunidad y con nuestra especie.

La entrada “Requerimiento”… ¿es lo que el cliente “re quiere”? se publicó primero en Kambrica.

Nueve mujeres no pueden tener un bebé en un mes.

Para stakeholders obsesionados con lograr “quick wins” dejando todo lo demás aparte, creé la relación inversa:

En nueve meses podés tener un pibe, o nueve ratoncitos.

Podríamos llamarlo la Ley de Bustelo-Brooks.

Santiago Bustelo
Agosto 2024

La entrada La ley de Bustelo-Brooks se publicó primero en Kambrica.

¿Por qué todo eso? Porque las metodologías las suele empujar el área de IT, que no sólo no tiene porqué entender lo que hacemos ni cómo encaminarlo exitosamente, sino que además nos suele traer muchas veces las cosas ya contaminadas: por ejemplo, confundiendo agilidad con apuro, o los espacios de investigación y de toma de decisiones de diseño como “Big design up front”. 

No hay forma de sumarnos exitosamente a algo que ya empezó mal antes.

El manifiesto ágil declara: valoramos “software funcionando”, por sobre “documentación exhaustiva”.

Para UX, esto significa: nuestros entregables no son valor si no se traducen en funcionalidad aprobada, en atributos visibles en el producto final.

¿Podemos identificar en qué medida total o parcial, un entregable nuestro NO aporta valor? ¿Podemos señalar qué cosas NO valen la pena hacer?

Por ejemplo, ¿entendemos y podemos explicar qué decisiones debe alimentar un customer journey? En función de ello, ¿tenemos las herramientas para argumentar y demostrar que sería suficiente hacerlo en una simple tabla de Excel, en lugar de toda esa decoración que queda tan linda en dribbble pero que no moverá la aguja en el proyecto?

UX ágil parte de entender el Manifiesto Ágil

Si no entendemos y no podemos poner en práctica la filosofía ágil, no hay manera de “hacer UX ágil”. Sólo estaremos generando entregables sin valor, sin ningún aporte a la agilidad del proyecto … pero eso sí, cumpliendo a rajatabla la burocracia de las ceremonias y los sprints.

En el resumen de mi charla en el evento “La Medida del Diseño 2018: Métodos lentos en tiempos ágiles”, organizado por IxDA Viña del Mar, profundizo sobre estos temas.

Santiago Bustelo
Julio 2024

La entrada ¿Cómo integrar UX research y diseño UX sobre metodologías ágiles? se publicó primero en Kambrica.

Esta misma mentalidad se refleja en algunos gerentes que pretenden contratar barato a agencias que ejecuten decisiones de diseño y desarrollo que ya han tomado, negándose a incorporar procesos que puedan mejorar la calidad de esas decisiones para evitar el escenario más habitual en el software: el fracaso.

Es así como en este momento, hay en algún lugar del mundo un gerente de compras presionando a una agencia para que acepte diseñar y desarrollar “la App” casi al costo. Ignorando que, de los más de 3 millones de apps publicadas, el usuario promedio sólo tiene instaladas unas 80.

“La App” pasará a sumarse al 80% de las Apps que no llegan a las 10.000 descargas. Y que los usuarios eliminarán la próxima vez que se les llene el teléfono: es decir, a más tardar a fin de mes.

Eso no es ahorrar: es “invertir” tiempo, esfuerzo y dinero para, a cambio, obtener un retorno negativo.

El valor de una buena inversión en dirección de UX & IT

Las empresas que buscan soluciones baratas y rápidas para ejecutar ideas sin dirección ni validación experta, terminan perdiendo más de lo que ganan.

Contratar agencias que puedan cometer UX y desarrollo al costo más bajo, seleccionados por departamentos de compras que negocian agresivamente, resulta en proyectos mal concebidos, en productos que no cumplen con las necesidades reales de los usuarios y que, en última instancia, serán ignorados o en el mejor caso, resistidos.

Esta estrategia de “ahorro” es, en realidad, una forma de desperdicio. En lugar de construir soluciones que realmente funcionen, aporten valor y puedan aspirar a tener alguna adopción por el mercado, se pierde tiempo y dinero en hacer pantallas lindas y baratas que le gusten a los decisores, y cuyo destino inevitable será, tarde o temprano, el descarte que dé lugar a otro proyecto. Porque en un mercado competitivo, las cosas se hacen bien, o se hacen de vuelta.

Visión vs. espejismos

Muchos gerentes consideran sus ideas como una “visión”, y a los diseñadores y desarrolladores como meros albañiles a quienes hay que decirles lo que tienen que hacer. Pero si esa visión de producto que espera el éxito no está informada por la evidencia, no será más que un espejismo.

El problema es que no es lo mismo tener ideas (que validamos nosotros mismos), que tener ofertas (que validan los clientes). Para un producto exitoso, no alcanza con una “buena” idea. Hay que madurarla en una buena oferta. Ésa es la función del Diseño como disciplina estratégica: la arquitectura, en lugar de la decoración.

Una consultoría experta que aplique procesos maduros de creatividad y toma de decisiones basada en evidencia, es una excelente forma de lograr esa maduración. Pero a menudo, los decisores consideran estos servicios “caros”, sin conocer los riesgos que les evitan ni entender el valor que aportan.

Porque sus pareceres y decisiones se fundan en la idea culturalmente instalada de que “ahorrar” es comprar barato, en lugar de invertir racionalmente.

La filosofía Lean y el diseño basado en objetivos

Existen diversas “escuelas” de pensamiento de diseño.

Una, basada en entender al diseño sólo como disciplina visual y como el establecimiento de una filosofía de cómo lograr “impacto”, se enfoca en crear interfaces que le gusten al comitente — la persona que paga por el proyecto.

Otra, que entiende al Diseño como disciplina proyectual y estratégica siguiendo las definiciones de Don Norman, la norma ISO 9241 y la filosofía Lean que ayudó a reconstruir la industria japonesa, es la que realmente da resultados — porque ése es precisamente su foco.

Ésa es nuestra escuela de pensamiento de diseño que impulsa la Dirección UX como disciplina para lograr software funcionando, aceptado y adoptado por usuarios reales, cumpliendo objetivos de Negocio.

Para la Dirección UX, la pregunta “¿qué tan crítico es un buen diseño de UX para incrementar uso y conversiones?” se responde por definición: si el diseño UX no incrementa uso y conversiones, no es bueno.

La escuela de la Dirección UX no sólo considera los factores estéticos: reconoce factores críticos de éxito como la funcionalidad, la eficiencia y la satisfacción del usuario final. Es una inversión sólida que, aunque pueda parecer más costosa inicialmente, resulta en productos exitosos, robustos, y que resisten el paso del tiempo: inversiones que resultan en verdaderos ahorros – en lugar de costo hundido y deuda técnica.

Conclusión

Comprar barato cosas que no son necesarias ni se van a usar no es ahorrar: es desperdiciar. Lo mismo ocurre en las empresas que contratan equipos de UX baratos para ejecutar proyectos que no resultarán en productos aceptados por los usuarios finales.

Para realmente ahorrar y obtener resultados, es fundamental invertir en equipos de UX bien dirigidos y capacitados, y darles los recursos y la autoridad necesarios para hacer su trabajo.

Solo así se pueden crear productos que satisfagan las necesidades del mercado y generen un retorno positivo sobre la inversión.

La entrada Comprar barato cosas que no necesitás, no es ahorrar. ¿Estás haciendo lo mismo en tus contrataciones de UX & IT? se publicó primero en Kambrica.

Así que puedo declarar que esta heurística es mía. Es la Heurística de Bustelo.

Principio: Las interfaces deben liberar al usuario de tareas repetitivas, aprovechando la capacidad de las computadoras para automatizar procesos. No hacerlo es desperdiciar el potencial del medio digital y castigar la eficiencia del usuario.

Ejemplo: La interfaz que muestro a continuación, que mi banco nos inflige a todos sus clientes, nos obliga a hacer un click por cada comprobante que necesitamos descargar.

A la hora de hacer el cierre fiscal, son 72 clicks que hay que hacer con cuidado de no saltearse nada: 2 tarjetas x 12, 3 cuentas x 12, y un año de Inversiones. Y eso, suponiendo que no tenés Préstamos, y sin contar los clicks que hay que hacer para pasar de una pestaña a la otra.

Todo ello, teniendo cuidado en cada click y haciendo scroll lentamente para no perder la guía (porque no hay distinción entre íconos cliqueados vs. aún sin cliquear).

El proceso puede llevar hasta una hora. Que se podría evitar con un enlace o botón de “descargar todo”. Es decir, aplicando la heurística de la naturaleza digital: el principio de que las computadoras están diseñadas para manejar tareas repetitivas de manera eficiente. Esta heurística enfatiza la importancia de aprovechar la tecnología para automatizar y simplificar procesos, asegurando que los sistemas e interfaces estén optimizados para acciones repetitivas, mejorando así la eficiencia del usuario y reduciendo la probabilidad de errores.

Santiago Bustelo
Mayo 2024

La entrada Heurística de la naturaleza digital: “las computadoras se inventaron para realizar tareas repetitivas”. se publicó primero en Kambrica.