Alguien detecta un problema serio en la experiencia de usuarios. Los equipos internos no tienen formación o capacidad. Y entonces, aparece la solución estándar: una licitación.

El problema es que la licitación no es una herramienta neutral. Es una máquina de golpear, empujar, aplastar y recortar problemas complejos hasta que entran en el molde de las comparaciones simples que permite una RFP. Y ahí empieza el problema real.

¿Estás evaluando proveedores… o estás simplificando un problema que todavía no entendés bien?

Una licitación no resuelve incertidumbre: simplemente la reordena en una tabla.

Horas, roles, entregables, experiencia mínima, precio.
Todo lo que no entra en una planilla, desaparece.

Y en UX, lo que no entra en la planilla es justamente lo que define el resultado.

• La calidad de la investigación.
• La calidad de las decisiones.
• La capacidad de leer fricción real en sistemas complejos.
• La habilidad de intervenir sin romper lo que ya funciona.

Eso no se mide en una grilla.
Pero como “se pondera”, queda la ilusión de que fue evaluado.
De forma matemática. Científica. Precisa.

El error estructural: tratar una decisión como un proceso administrativo

Las licitaciones funcionan bien cuando el problema ya está definido.

• Comprar infraestructura.
• Contratar capacidad de ejecución.
• Externalizar tareas conocidas.

Pero cuando el problema es precisamente no saber qué hay que hacer, el proceso falla por diseño. Porque asume que:

• el problema ya está claro
• los criterios de éxito están definidos
• el evaluador sabe lo suficiente para comparar alternativas complejas

En UX estratégico, eso rara vez es cierto.

El efecto colateral: optimización de proceso, no de resultado

Antes de contratar a una agencia, la organización ya tomó la decisión más importante: cómo va a decidir.

Y ahí se juega todo. Porque si el modelo de decisión es incorrecto, todo lo que venga después es consistencia en el error.

• Más workshops.
• Más entregables.
• Más horas.
• Más diagramas.

Pero el problema de fondo sigue intacto.

El problema real no es UX, o IT, o cualquier servicio profesional estratégico.
Es cómo decidís contratarlo.
Si desde una consulta clínica donde se pueda elaborar un diagnóstico profesional,
o desde la lista de soluciones que pudiste imaginar sin esa instancia.

Por qué las organizaciones siguen haciéndolo mal

No es ignorancia, sino por la necesidad de mantener la ilusión de control.
Las licitaciones dan sensación de orden:

• comparabilidad
• proceso conocido
• legitimidad interna
• protección frente al riesgo político

El problema es que esa sensación reemplaza a la calidad de la decisión.
Y cuando eso pasa, el sistema elige lo que es defendible, no lo que es correcto.

UX falla porque fallan las decisiones

UX falla en la mayoría de las organizaciones. Porque UX es tomar decisiones. Y en las organizaciones, suele fallar la forma en que se decide UX.

En 2026 cumplimos 30 años trabajando con grandes empresas y organizaciones, públicas y privadas, en más de 40 industrias.

Y hay un patrón que se mantiene constante: los proyectos no fallan por falta de ejecución, sino por decisiones iniciales sin el encuadre adecuado.

La decisión de cómo contratar la dirección de un equipo de UX (desde una consulta clínica, o desde un checklist de deseos), es una de las más críticas. Porque define todo lo que viene después.

Cuando tu única herramienta es una licitación, todo clavo se resuelve martillándolo hasta que entra en una RFP

El problema aparece cuando una organización intenta resolver con procesos administrativos lo que en realidad es un problema de decisiones.

Y UX, en su núcleo, no es ejecución. Es un sistema de decisiones aplicado a producto.

Por eso, el primer problema para resolver un problema de UX, no es “hacer UX”.
Es cómo la organización decide qué es una buena solución.
Y eso empieza mucho antes de contratar a nadie.

¿Este patrón se repite en tu organización?
Hablemos.

La entrada La ilusión del proceso: por qué las licitaciones no te están ayudando a resolver tu problema se publicó primero en Kambrica.

Cualquiera podía notar que el esquema era absurdo: cualquier gusto se siente en toda la lengua, no sólo en una región particular. Pero el sistema educativo no estaba diseñado para que nadie lo dijera. El esquema sobrevivió porque no era un problema de biología, sino de sistema.

Lo que ocurrió es que estudios tempranos sobre umbrales de detección gustativa, mal interpretados y luego simplificados, se convirtieron por repetición y autoridad en dogma escolar. Cuando la ciencia ya lo había refutado, el esquema seguía en manuales y pizarrones. No por mala intención, sino por diseño: el sistema no premiaba cuestionar, sino repetir.

El modelo educativo del siglo XX no fue diseñado para formar pensamiento crítico. Fue diseñado por una sociedad industrial para alimentar a esa misma sociedad con egresados entrenados para obedecer procesos estandarizados, destinados a trabajos cuya cultura de gestión replicaba la ya conocida y probada para manejar personas a gran escala: el modelo militar.

Ese es el modelo industrial de educación: una fábrica de empleados, no una usina de pensamiento crítico.

De la lengua al NPS

Ese mismo patrón se vive hoy en las organizaciones y se replica en la industria de las experiencias.

Porque quienes de niños fueron adoctrinados a repetir mitos escolares (como el mapa de la lengua), no sorprende que de grandes generen, repitan y apliquen mecánicamente y sin cuestionar mitos corporativos. Como el NPS, que en la práctica opera como numerología corporativa.

Después de más de dos décadas, no existe evidencia científica sólida que demuestre que el NPS sirva para medir ni para gestionar la calidad de la experiencia. No resiste análisis conceptual, ni metodológico, ni empírico. Aun así, se utiliza porque “es lo que se usa”, y porque cuestionarlo se percibe como un ataque personal a la autoridad de quien lo impuso.

La superstición mutó de aula a comité ejecutivo.

NPS no tiene un solo componente que resista un análisis serio. Jared Spool documenta cómo ni la pregunta, ni la fórmula, ni las inferencias derivadas del NPS resisten análisis. Sin embargo se aplica porque ejecutivos, formados en el mismo modelo educativo industrial, “quieren números”. Y como cualquier ficción en Excel les sirve, pues les damos una que permita argumentar que nos merecemos el bono.

¿A quién le regalamos la comodidad de no tener que pensar?

Larry Tesler formuló el principio de conservación de la complejidad:
la complejidad no se elimina, se traslada.
O la asume el sistema profesional que diseña y desarrolla, o la paga el usuario final.

XDM articula este principio con el modelo de Daniel Kahneman, desarrollando cuatro niveles decisorios:

• Nivel 0 – Ejecutivo: respuesta reactiva al estímulo, sin proceso de decisión.
• Nivel 1 – Intuitivo: juicios automáticos de bajo costo cognitivo.
• Nivel 2 – Analítico: procesamiento racional, secuencial, de alto costo cognitivo.
• Nivel 3 – Creativo: generación de nuevas opciones.

De esta articulación surge una regla profesional simple:

Los productos, servicios y sistemas no deberían exigir a los usuarios más que la activación de los niveles 0 y 1. Para que eso sea posible, quienes los diseñan y gestionan deberían operar deliberadamente en los niveles 2 y 3.

Ocurre exactamente lo contrario.

Por falta de formación y de cultura de gestión basada en evidencia y modelos racionales, quienes idean, diseñan y gestionan productos operan ellos mismos en los niveles 0 y 1: hacen “lo que les parece”, sustituyen preguntas difíciles por respuestas fáciles y repiten prácticas, métricas y frameworks sin preguntarse de dónde salieron ni qué miden realmente.

Como consecuencia, la complejidad que se niegan a procesar ellos, se traslada al usuario: los usuarios finales quedan obligados a activar los niveles 2 y 3 (los más lentos y costosos) para entender y operar productos todos los días.

Eso no es una falla de usabilidad.
Es una violación al principio profesional de responsabilidad cognitiva.

Qué propone XDM

Experience Decision Making plantea un principio de responsabilidad profesional:

El esfuerzo cognitivo pesado corresponde al equipo profesional, nunca al usuario final.

XDM integra psicología cognitiva, teoría de la decisión y principios de gestión para desterrar supersticiones organizacionales, reemplazarlas por modelos con fundamento, y darle base a la gestión del siglo XXI de la industria de las experiencias.

No se trata de “medir mejor”.
Se trata de pensar mejor antes de decidir qué medir.

Si en la industria de las experiencias todavía estás usando mapas de lengua organizacionales, el problema no es la herramienta. Es el modelo mental industrial con el que estás decidiendo.

La entrada El mapa de la lengua y la fábrica de supersticiones se publicó primero en Kambrica.

Formularios que no permiten copiar y pegar, contraseñas imposibles de recordar, flujos innecesariamente largos, confirmaciones redundantes. Medidas que incomodan al usuario, complican procesos críticos y degradan la experiencia general. Y todo sin ninguna evidencia sólida de que hagan al sistema más seguro.

El problema no es técnico.
Es epistemológico.

Seguridad vs. practicidad: una falsa dicotomía

Buena parte de las decisiones de “seguridad” que degradan la usabilidad se apoyan en una falacia formal bastante básica: la afirmación del consecuente. Como seguridad y practicidad suelen percibirse como incompatibles, se asume que cualquier cosa que vuelva un proceso más engorroso debe hacerlo más seguro.

En otras palabras, se toma una consecuencia frecuente como si fuera una causa, y un efecto colateral como si fuera un mecanismo de protección. El razonamiento es inválido, pero está tan naturalizado que rara vez se lo cuestiona.

No hay threat modeling detrás, ni análisis de vectores reales, ni mediciones de impacto. Hay incomodidad inducida, presentada como control. Esfuerzo confundido con robustez, molestia con mitigación. Y un axioma aceptado sin demostración.

Cómo se construyen las supersticiones

Las supersticiones tienen una ventaja cognitiva poderosa: no requieren prueba. Como no existe forma de afirmar causalmente por qué algo no ocurrió, cualquier acción previa puede ser postulada como la razón de su ausencia. El razonamiento es simple (y profundamente defectuoso): hice X, no pasó Y, entonces X evitó Y.

Supongamos que hoy fuimos a trabajar con los calzoncillos azules. No nos asaltaron por el camino. A partir de ahí, decidimos establecer una relación causal inexistente: los calzoncillos azules evitan asaltos. Desde ese momento, los usamos todos los días, convencidos de que nuestra seguridad depende de eso. El hecho de que jamás podamos demostrar lo contrario hace que la superstición se refuerce sola.

Este mismo mecanismo opera en muchas decisiones de seguridad informática. Se implementa una medida sin evidencia, no ocurre ningún incidente (como suele pasar la mayor parte del tiempo), y esa ausencia se usa como validación retroactiva. La superstición queda institucionalizada.

Superstición no es prevención

Cuando no hay estudios públicos, datos empíricos, estándares reconocidos ni análisis que demuestren que una práctica concreta mejora la seguridad, no estamos ante una medida preventiva: estamos ante una superstición.

Y ante una superstición, el peso de la prueba no recae en quien la cuestiona, sino en quien la introduce.

La única razón por la que estas prácticas prosperan suele ser una combinación de ignorancia del negocio respecto de procesos racionales de toma de decisiones, miedo difuso a que “algo pase” y una cultura organizacional donde nadie quiere hacerse cargo de explicar por qué no se implementó una medida, aun cuando su justificación viole reglas básicas de lógica proposicional, que forma parte del programa de estudios del secundario.

Si Seguridad Informática trae supersticiones al negocio, es función del negocio tener la madurez suficiente para rechazarlas. No gobernar por miedo. No decidir “por las dudas”. No aceptar fricción inútil solo porque alguien la rotuló como seguridad.

Casos típicos de superstición en Seguridad Informática

Las supersticiones de seguridad no aparecen de manera abstracta. Se manifiestan en patrones concretos, repetidos hasta el cansancio, defendidos con convicción pero sin evidencia. Veamos algunos de los más comunes.

1. Bloquear copiar y pegar en formularios sensibles

El caso más burdo y más frecuente es impedir copiar y pegar texto en campos “sensibles”: montos de transferencias, números de tarjeta, CBU, direcciones, tokens.

La lógica implícita es siempre la misma: si lo vuelvo más difícil, debe ser más seguro.

No hay estudios públicos, papers, estándares ni recomendaciones serias que indiquen que bloquear el portapapeles reduzca fraude o aumente la seguridad. No está en OWASP, no está en PCI-DSS, no está en ningún modelo de amenazas bien hecho. Es una decisión puramente ritual.

El resultado real es conocido: más errores de tipeo, más reintentos, más operaciones fallidas, más frustración, más tickets de soporte. Es decir: más riesgo operativo, no menos.

Si el endpoint está comprometido, bloquear “pegar” no sirve.
Si el endpoint no está comprometido, bloquear “pegar” no aporta nada.

Lo único que hace es tranquilizar a quien lo propuso.

2. Contraseñas deliberadamente inhumanas

Otra superstición clásica: políticas de contraseñas diseñadas para ser impronunciables, imposibles de recordar y renovadas con frecuencia arbitraria.

La creencia es que la complejidad forzada equivale a mayor seguridad. La realidad es que produce exactamente los comportamientos que se supone que intenta evitar: contraseñas anotadas, patrones previsibles, variaciones mínimas, reutilización.

Esto no es nuevo. Está documentado en estándares como NIST SP 800–63B, que señala que los requisitos arbitrarios de complejidad no aportan beneficios significativos y tienden a aumentar la frustración y las contramedidas de los usuarios. Aun así, sigue implementándose porque suena seguro.

De nuevo: fricción elevada, seguridad marginal o inexistente.

3. Expiración periódica sin motivo

Cambiar contraseñas cada 30, 60 o 90 días “porque sí” es otro ejemplo perfecto de superstición institucionalizada, persistente incluso después de haber sido cuestionada hace más de una década por organismos como el NCSC, que advierten explícitamente: “the more often users are forced to change passwords, the greater the overall vulnerability to attack”.

No hay compromiso detectado, no hay indicios de filtración, no hay evento que lo justifique. Se cambia porque siempre se hizo así. Y como nunca pasó nada grave después, la práctica se valida sola.

El razonamiento es circular: como nunca pasó nada, debe estar funcionando. Exactamente el mismo razonamiento que los calzoncillos azules.

4. CAPTCHAs que castigan a humanos

CAPTCHAs cada vez más intrusivos, opacos y fallidos, que afectan más a usuarios reales que a atacantes automatizados. Otro ritual de seguridad.

Los bots evolucionan. Los humanos se cansan. La fricción se desplaza hacia quien no es el problema.

Pero el CAPTCHA queda, porque “algo hay que poner”.

5. Confirmaciones redundantes sin información nueva

“¿Está seguro?” “¿Realmente está seguro?” “Confirme nuevamente.”

Sin aportar contexto adicional, sin resumen claro, sin cambio en el estado de riesgo. Pura repetición.

No es un control.
Es una liturgia.

6. Restricciones sin fundamento

Otro patrón clásico de superstición es imponer restricciones arbitrarias sobre los datos de entrada, sin ningún respaldo normativo, técnico ni de negocio, y luego justificarlas con la palabra mágica: seguridad.

• DNIs que “deben” tener exactamente ocho caracteres.
• Campos de CUIL/CUIT que no permiten más de 11 dígitos, impidiendo ingresar separadores habituales como puntos, guiones o espacios.
• Formularios que rechazan entradas perfectamente válidas porque no coinciden con el modelo mental del programador que las definió.

Estas decisiones no solo son incorrectas desde el punto de vista del dominio (como ya escribí en el caso del DNI argentino) sino que además suelen defenderse con argumentos técnicamente erróneos. He llegado a discutir con “expertos” de un banco que sostenían que estas restricciones eran “por seguridad”, y que por ese motivo había que limitar lo que el usuario podía tipear… usando JavaScript, lo cual es inherentemente inseguro.

Eliminar caracteres no numéricos de un input es trivial. Rechazar usuarios legítimos porque escriben como seres humanos no es una medida de seguridad: es una muestra de ignorancia técnica y de desprecio por la experiencia real.

7. “Por seguridad” como carta blanca para cualquier cosa

La seguridad es una carta tan poderosa que no solo la juega Seguridad Informática. La juegan soporte, producto, legal, compliance y cualquiera que necesite cerrar una conversación sin fundamentos.

Un ejemplo reciente y particularmente ilustrativo: la imposibilidad de eliminar manualmente chats en Gemini dentro de Google Workspace. Ante mi reclamo, la respuesta oficial fue que no se trata de un error ni de una limitación del producto, sino de una medida de seguridad.

No poder borrar información propia, en una cuenta paga, no tiene absolutamente nada que ver con medidas de seguridad. Es una decisión de diseño, y muy mala. O es que todavía no llegaron a ese punto del backlog.

El argumento de seguridad funciona porque es difícil de refutar en caliente. Nadie quiere quedar del lado de “quien bajó la guardia”. Entonces la frase “es por seguridad” se convierte en un comodín que justifica cualquier limitación, incluso aquellas que van en contra de principios básicos de control de datos, privacidad y experiencia de usuario.

El denominador común

Todos estos casos comparten algo fundamental: no están basados en evidencia, sino en miedo. No en modelos de amenazas reales, sino en la necesidad psicológica de sentir que “hicimos algo”.

Y lo más importante: la ausencia de incidentes se usa como prueba de eficacia, cuando en realidad no prueba absolutamente nada.

Eso es una superstición, no una estrategia de seguridad.

Un problema de UX que “no es un problema de UX”

Y acá es importante ser claros: esto no es, técnicamente, un problema de UX. Es una falla de razonamiento.

Demoler supersticiones no debería ser responsabilidad del área de UX. Pero no hacerlo impacta directamente en la experiencia de los usuarios, porque lo que los usuarios experimentan es siempre consecuencia de las decisiones de todos los involucrados. Especialmente cuando esas decisiones se toman a contramano de procesos racionales.

Desde UX no nos corresponde demostrar que estas prácticas no mejoran la seguridad. Nos corresponde mostrar el impacto negativo que tienen en la experiencia: en los procesos, en los errores, en los abandonos, en la confianza del usuario.

A Seguridad Informática le corresponde demostrar que estas prácticas no son supersticiones. Que están respaldadas por datos, estudios, estándares o evidencia empírica. La carga de la prueba es de quien introduce la fricción, no de quien la cuestiona.

Cuando estas decisiones prosperan, lo que vemos no es solo un fracaso del área de Seguridad Informática por introducir falsos positivos, sino también un fracaso del negocio por no contar con procesos racionales de toma de decisiones.

Muchas organizaciones donde esto ocurre no tienen UX. O dicen tener UX, pero no pesa en la mesa donde se decide. Y eso también es un síntoma.

Conozco mucha gente de negocio a la que le gusta decir que es “customer centric”. Pocas están dispuestas a cuestionar supersticiones cuando vienen envueltas en miedo, jerga técnica y la frase mágica: “por seguridad”.

Y así es como terminamos teniendo conversaciones en las que hay que repasar cosas que nuestras contrapartes deberían haber visto como parte de la educación básica.

Santiago Bustelo
Diciembre 2025

La entrada Seguridad Informática: cuando la fricción reemplaza a la evidencia se publicó primero en Kambrica.

El experimento de la cárcel de Stanford nos enseñó algo inquietante: si le das a una persona promedio un uniforme y una pequeña cuota de poder arbitrario, no tarda mucho en comportarse como un déspota. Cuando a eso le sumamos la tendencia natural del ser humano a la superstición, tenemos un cóctel explosivo: la mayoría de las culturas corporativas.

No hace falta ir a un laboratorio para verlo. Basta con mirar cómo suelen empezar las carreras corporativas: atravesando la puerta custodiada por reclutadores que actúan como porteros de la superstición.

Ahí es donde nacen los descartes absurdos:

• “Tiene el marco ‘Open to Work’, seguro está desesperado y va a mentir para conseguir el puesto”
• “Cambió de trabajo muchas veces, seguro que no aguanta la más mínima presión.”
• “Tardó mucho en recibirse… ah no, pará, yo también. Bueno, éste pasa.”

¿Por qué ocurre esto? Como descubrió Daniel Kahneman, nuestro pensamiento rápido (el Sistema 1) es un experto en trampas: sustituye una pregunta difícil por una más fácil sin avisarnos. Ante la complejidad de “¿Es esta persona competente?”, el cerebro perezoso responde a “¿Me gusta lo que leo?”. Y valida esa respuesta como si fuera una certeza técnica.

Desde luego, hay mucha gente de Recursos Humanos que son excelentes profesionales. Socios estratégicos que entienden el negocio, que respetan a las personas y que luchan contra estos sesgos cada día. A ellos, mis respetos.

Pero para los que operan en piloto automático, el daño es real. Y el problema es que, si logras superar a los guardias de la entrada, la cosa no mejora adentro. Ese tejido de sesgos y atajos mentales se calcifica. En muchas organizaciones, a esa acumulación de supersticiones que nadie se anima a cuestionar, le llaman “Cultura”.

Es lo tácito. Lo que se calla por vergüenza o por miedo. Y sobre esa base de barro se toman decisiones millonarias.

No es casualidad que el 91.6% de los proyectos de UX terminen en fracasos. No fallan por la tecnología ni por el diseño de las pantallas; fallan porque los cimientos de las decisiones que los sustentan están socavados por estas supersticiones invisibles.

Y así terminamos viviendo en una realidad disfuncional. Porque seamos honestos, ninguna persona dijo nunca de pequeña:

• “Cuando sea grande quiero pasarme el día escribiendo ficción en planillas de Excel para justificar un presupuesto.”
• “Quiero tener reuniones de tres horas para decidir el color de un botón que nadie va a apretar.”
• “Quiero fingir que estoy de acuerdo con el jefe para que no me echen.”

Vivimos en un mundo artificial, producto de las decisiones de otras personas. A diferencia de la ingeniería, donde si ignoras la gravedad el puente se cae, en la empresa no nos limitan las leyes de la física. Nos limita nuestra capacidad de enfrentar las arbitrariedades y las cosas que alguna vez tuvieron sentido, pero ya dejaron de tener propósito.

Todo lo que nos frustra, todo lo que hace miserables a las experiencias de los clientes y a los días de los empleados, es resultado de decisiones humanas. Algunas tomadas por gente que ya ni siquiera trabaja ahí.

Desde Experience Decision Making (XDM) proponemos un camino para el cambio: hacer consciente lo que hasta ahora era inconsciente. Analizar cómo se toman decisiones. Y desarrollar la competencia y el coraje para tener las conversaciones necesarias para desarmar la maraña de supersticiones en la que vivimos enredados.

Si queremos algo mejor, tenemos que empezar a cuestionar “la cultura”.
De a una conversación a la vez.

La entrada No nos limitan las leyes de la física: nos limitan las supersticiones corporativas se publicó primero en Kambrica.

La Neurona: La Investigación Individual

Una sola neurona no “piensa”. Su función es recibir, procesar y transmitir una señal electroquímica. Es un evento binario, un “sí” o un “no”, un pulso. De la misma manera, una sola investigación de UX (una serie de entrevistas, un test de usabilidad, un análisis de métricas) no es “el éxito del producto”.

La Investigación Individual (La Neurona): Proporciona un insight específico. Por ejemplo: “Los usuarios no entienden el ícono de ‘guardar’ en nuestra app”. Este es un dato crudo, un pulso de información. Es vital, pero por sí solo no genera ingresos ni reduce costes. Es solo una señal.

El ROI de la Neurona: ¿Cuál es el ROI de que esa neurona específica se active? Es una pregunta absurda. Su valor no es intrínseco ni aislado; depende de las miles de otras neuronas con las que se conecta.

El Pensamiento: La Experiencia de Usuario Exitosa

Un pensamiento complejo, una idea o una emoción no surgen de una neurona, sino de la interacción coordinada y masiva de millones de ellas. Es un fenómeno emergente. La red neuronal en su conjunto es lo que crea el valor.

La Experiencia de Usuario Exitosa (El Pensamiento): Es el resultado de conectar cientos de “pulsos” de investigación a lo largo del tiempo. El insight sobre el ícono de “guardar” (neurona 1) se conecta con los datos de una encuesta de satisfacción (neurona 2), que a su vez se combina con el análisis del funnel de conversión (neurona 3) y las entrevistas sobre las necesidades del cliente (neurona 4).

La Red (El Proceso de Diseño y Desarrollo): El equipo de producto, diseño e ingeniería actúa como las sinapsis. Toman estos insights dispersos y los conectan para tomar decisiones informadas:

“Cambiemos el ícono por un texto que diga ‘Guardar Proyecto’”.

“Además, simplifiquemos el flujo de guardado porque las métricas muestran que la gente abandona en ese paso”.

“Y basándonos en las entrevistas, añadamos una opción de ‘guardado automático’ para reducir la ansiedad del usuario”.

El resultado final es un producto más usable, que genera mayor satisfacción, aumenta la retención y, finalmente, impacta positivamente en los ingresos. Ese es el pensamiento completo.

El Desafío de la Atribución Directa

Ahora, volvamos a la pregunta del ROI. Un stakeholder pregunta: “¿Cuál fue el ROI de esas 5 entrevistas que hicimos el mes pasado?”.

Siguiendo la analogía, es como señalar una neurona en medio de un escáner cerebral y preguntar: “¿Cuántos dólares generó esa neurona cuando se activó mientras el sujeto pensaba en ‘comprar ahora’?”.

La atribución directa es imposible porque:

1. El Valor es Acumulativo: El conocimiento de UX se construye con el tiempo. Una investigación de hoy puede prevenir un error costoso en seis meses. Su valor no es inmediato.
2. El Valor es Colaborativo: La investigación informa una decisión, pero no es la decisión. El diseñador que crea la nueva interfaz, el desarrollador que la implementa sin bugs y el marketer que la comunica correctamente también son responsables del éxito. ¿Cómo aislar la contribución exacta del insight inicial?
3. El Valor es Preventivo: Gran parte del ROI de UX Research radica en los costes que evita. Evita construir la funcionalidad equivocada, evita rediseños costosos, evita dañar la reputación de la marca, evita llamadas a soporte técnico. Medir lo que no sucedió es extremadamente difícil.

Conclusión: Cambiando la Pregunta

En lugar de pedir el ROI de la neurona, un enfoque más inteligente es medir la salud y la eficacia del pensamiento general. No preguntes por el ROI de la investigación, pregunta cómo la investigación está impactando los indicadores clave del negocio (KPIs).

Epílogo: Numerología, ROI y Cultura de Gestión

Como vengo diciendo hace tiempo:

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

Pedir el ROI de UX Research pertenece a la misma lógica.

No es gestión madura: es cargo culting con planillas de cálculo.

Una cultura que confunde control con comprensión, y números con decisiones. Una cultura desviada, que busca seguridad en cifras porque perdió la capacidad de pensar.

El valor de la investigación no se mide como el rendimiento de una acción en bolsa. Se demuestra en la calidad de las decisiones que hace posibles.

Y eso — precisamente eso — es gestión.

Si quieren sumar herramientas para lograr verdaderas decisiones estratégicas y de valor en la industria de las experiencias: ¡síganme los buenos!

Ah! Y también pueden reservar una sesión de consultoría personalizada para trabajar sobre su caso si ya les está cayendo el peso de métricas mal entendidas y peor aplicadas. Métricas que la gerencia de turno usa ciegamente para enfilar a toda máquina contra el iceberg de la realidad, que terminará hundiendo los proyectos y la relación con los clientes en todas aquellas dimensiones que no pueden medir.

La entrada Pretender que te muestren el ROI de UX Research… se publicó primero en Kambrica.

De a poco, van surgiendo propuestas. Ninguna sobrevive: no es lo que buscamos, no es innovador, no nos parece. Hasta que alguien dice: “pongamos un chat inteligente”.

La idea entusiasma. Marketing ya imagina la campaña. Compras ya identifica posibles proveedores. Sistemas considera que podrá integrar la solución. Entre todos, deciden qué nombre le pondrán al agente virtual y una fecha de lanzamiento.

Varios meses y miles de dólares más tarde, se lanza a medio hacer. Dirige a los clientes a las mismas páginas que antes ya eran viejas, feas y mostraban información desactualizada. Y para eso, primero los obliga a mantener una conversación en la que el chat inteligente no entiende el 83% de lo que le preguntan.

Después de un año de exigir ajustes al proveedor, Marketing finalmente pierde interés en el agente virtual. Sin mucha ceremonia, es retirado del sitio.

En este instante, en una sala de reuniones en algún lugar del mundo, se está iniciando una historia similar. Los actores, problemas y soluciones propuestas difieren. Pero el desenlace será el mismo: una iniciativa prometedora terminando en la agonía y el olvido.

Así empieza mi libro “XDM: Experience Decision Making en 30 minutos” que podés bajar GRATIS de xdm.com.ar, con las bases para evitar que tu equipo se siga embarcando en proyectos destinados al naufragio.

Y sobre esas bases, voy publicando regularmente artículos con más modelos y casos de aplicación.

Te invito a conocer XDM y dejar de sufrir :)

Santiago Bustelo
Octubre de 2025

La entrada ¿Te suena este escenario? se publicó primero en Kambrica.

Hace mucho tiempo, analizando cómo mejorar el e-commerce de un gran cliente, nos sorprendió encontrar muchísimas quejas en redes sociales. Los productos no llegaban, y nadie respondía.

Lo elevamos como un problema crítico, junto con propuestas como ofrecer un sistema de tracking para calmar los ánimos de los clientes.

Y la persona responsable del proyecto nos dijo: “Nah, no hace falta. En ese punto ya pusieron la tarjeta de crédito.”

Ante semejante respuesta, se me ocurrió buscar entre las declaraciones de principios de la organización –misión, visión y todo eso– a ver si había algo que pudiera apoyar nuestro criterio. Y lo peor es que no encontré nada.

O sea que esta persona no estaba castigando a los clientes por capricho. Estaba actuando con total coherencia con una cultura a la que no le importaba cómo tratar a sus clientes, y que la había ascendido a tomar las decisiones que estaba tomando.

Y ahí entendí que por bienintencionada que sea, por más resultados que proponga, no hay decisión de diseño que pueda sobrevivir a la falta de principios de las decisiones de negocio.

Santiago Bustelo
Julio 2025

La entrada UX no puede maquillar la falta de principios del negocio se publicó primero en Kambrica.

Te muestran pantallas, diagramas, post-its, roadmaps… y en el momento parece que todo va bien – o tal vez sea el carisma del PM lo que te calma. Pero la verdad es que, por dentro, te queda una sensación de inseguridad. No terminás de ver claro, no podés tomar el control, y lo peor: no sabés cómo intervenir con eficacia.

Hay gente capaz, hay esfuerzo, pero falta “algo” en la dirección: algo que te de claridad. Las reuniones parecen interminables, igual que el proyecto. Y cuando el proyecto por fin termina, el resultado… “tiene todo”, pero al mismo tiempo, “le falta algo”. Todo se hizo según el plan. No hay nada puntual que objetar… pero sabés que algo no está bien. Y no podés decir qué.

¿Por qué sigo con la sensación de estar perdido, si estamos haciendo todo “de manual”?

Porque sobran metodologías, pero todas comparten la misma limitación: organizan el trabajo, pero no cómo ni por qué se decide lo que se hace.

Y cuando falta ese criterio, todo se define por intuición, simpatía o costumbre. Porque no se atiende la cuestión de fondo: que las decisiones se tomen de forma estratégica, fundamentada y con visión.

Si experimentaste o estás experimentando estas situaciones, no estás solo. Esto es lo habitual cuando se encara un proyecto de software sin un marco claro para tomar decisiones.

Porque el problema no es la tecnología, ni el diseño, ni el equipo. El problema es no tener un marco para enfrentar de manera estratégica el tejido de decisiones interdependientes que forman un proyecto de software. Entonces, esas decisiones se siguen tomando “como se puede”, según la urgencia o la intuición del momento.

Presentando Experience Decision Making

Experience Decision Making (XDM) es un sistema para tomar decisiones de calidad en proyectos de software y diseño estratégico.

Basado en teoría de la decisión, psicología cognitiva, principios modernos de gestión y experiencia práctica, XDM te da método donde otros improvisan.

Es un sistema probado en proyectos reales, con resultados medibles, diseñado para gente como vos: decisores de negocio que quieren recuperar el mando, y dejar de delegar a ciegas.

Solicitá tu consultoría gratuita y tomá el control de tus proyectos

Si estás al frente de la contratación o el rumbo estratégico de un proyecto, te invitamos a solicitar una consultoría gratuita. En tan sólo 30 minutos, podemos analizar tu situación y ayudarte a evitar los mismos errores.

Esta consultoría está dirigida a:

• Ejecutivos y mandos medios con experiencia en proyectos de software o UX.
• Responsables de negocio que ya han vivido en carne propia cómo no funciona.
• Decisores que están por encarar un próximo proyecto, y quieren hacerlo con más claridad y menos improvisación.

Completá el siguiente formulario para solicitar tu consultoría. Analizaremos tu caso y, si consideramos que podemos ayudarte de verdad, te compartiremos nuestra agenda para coordinar.

La entrada ¿Otra vez en un proyecto a la deriva? Es momento de tomar el control. se publicó primero en Kambrica.

Podrán decir que la idea no es original. Que sus abuelas ya decían “lo barato cuesta caro”. Y es cierto. Pero también es cierto que nuestras abuelas decían un montón de cosas, y una buena parte de ellas hoy resultan anacrónicas o directamente erradas.

Por eso, creo que todos necesitábamos una frase más moderna, más apropiada para los procesos de toma de decisiones en negocio, diseño y desarrollo en los tiempos que corren.

Y para facilitar que puedan citar esta versión renovada —ustedes y las generaciones venideras—, desarrollo la idea a continuación.

La Paradoja de Bustelo

Es común que se busque recortar la etapa de desarrollo de los productos –etapa donde aún no están generando ventas ni ingresos– y que se pretenda lanzar al mercado lo antes posible. El riesgo es hacerlo sin validar si lo que se está lanzando, resultará al menos apto para consumo humano.

El desarrollo de nuevas ofertas –productos, servicios, sistemas, experiencias– tiene una bajada de bandera. Hay un nivel mínimo por debajo del cual no vale la pena siquiera emprender el esfuerzo. Si lo que prima es el apuro, no se cubre lo mínimo en lo que hace a tiempo, costos y esfuerzos, por pequeña que resulte la inversión, resultará una pérdida segura.

Porque la gente apurada comete errores. Y al mercado no le gusta pagar por errores.

Hacer las cosas bien es “caro”, pero eso no tiene ninguna importancia si el negocio trabaja desde la distinción de Lean, y entiende cómo funcionan el negocio del diseño y el negocio del software. Esto es, si entiende cómo hacer de un buen diseño de software, un éxito comercial.

La filosofía Lean plantea el foco en la Calidad, y eso requiere distinguir valor de desperdicio: lo que el cliente valora, versus lo que no. Hacer foco en costos, lleva a preferir lo barato… y la mayoría de las veces, eso coincide con el desperdicio. Y crear desperdicio barato, es la forma más usual y paradójica de tirar el dinero a la basura: creyendo que se está obrando con criterio y haciendo negocios.

Hay un costo inherente al no tomar el tiempo y la atención necesarios para hacer las cosas bien. Este costo puede ser visible o no, pero existe. Hacer las cosas mal puede generar una serie de problemas, incluyendo:

• Errores y retrabajos: Será necesario corregir errores y rehacer el trabajo, lo que aumenta el tiempo y los recursos necesarios.
• Daño a la reputación: La calidad deficiente castiga la imagen de la marca, con la consecuente pérdida de clientes y oportunidades futuras.
• Mayor costo a largo plazo: El costo de corregir los errores, lidiar con las consecuencias y reconstruir la confianza resulta en software mucho mayor que el costo inicial de hacer las cosas bien desde el principio. Como menciono en la introducción de Experience Decision Making, la deuda técnica es implacable:

Una vez que algo se ha puesto en producción (esto es, el software está publicado y hay usuarios operándolo), corregirlo resulta entre 29 y 1500 veces más caro que al inicio del proyecto. El interés de la deuda técnica, asumida irresponsablemente, suele dejar proyectos en bancarrota.

El costo de hacer las cosas bien

Aunque el costo inicial de hacer las cosas bien puede ser percibido como “caro”, es en realidad la opción más rentable. Porque hacer las cosas bien desde el principio:

• Reduce la necesidad de corregir errores y retrabajos.
• Contribuye a una reputación positiva.
• Reduce los costos a largo plazo.

Por eso, otra mirada sobre este mismo tema, es otra frase que acuñé hace un tiempo (y que al día de la fecha, todavía nadie replicó):

Las cosas se hacen bien,
o se hacen de vuelta.

Santiago Bustelo
Abril de 2025

La entrada Quien cree que hacer las cosas bien es caro, no tiene idea de lo que cuesta hacerlas mal. se publicó primero en Kambrica.

Definiendo el éxito en los proyectos

La primer definición de “proyecto exitoso” surge de los inicios de la industria informática, cuando su objetivo era informatizar procesos establecidos. Cuestiones como trayectorias balísticas o cálculos de impuestos debían seguir procedimientos precisos: cualquier desvío podía costar dinero, multas o vidas.

En otras palabras, el foco estaba en lo que sucedía en la máquina. Lo que sucedía delante de ella, no era una preocupación. De hecho, los términos usabilidad y experiencia de usuario recién aparecerían algunas cuantas décadas más tarde.

Es así que la primer definición de Calidad, que podemos considerar fundacional, es lo que se conoce como la triple restricción:

• Costo: todos los recursos empleados, particularmente los recursos humanos (“horas”).
• Tiempo: el tiempo calendario que durará el proyecto.
• Alcance: lo que el equipo se compromete a construir.

En la forma de trabajo de ese entonces, que desde 1970 se conoce como “waterfall” o “cascada” y que muchos aún utilizan, estas variables se definían antes de empezar a construir el software, en una fase preliminar de análisis y estimación.

Cualquier diferencia entre esta estimación y la ejecución real, se entendía como desvío. La triple restricción tiene forma de triángulo, por dos razones:

1. Interdependencia: como en un triángulo, modificar cualquiera de las variables, requiere ajustar al menos una de las otras dos. Por ejemplo, si se revela que es necesario construir más que lo estimado, será necesario no sólo extender el alcance, sino también acomodar el costo y/o tiempo en consecuencia.

2. Simplicidad: Supongo que el triángulo debe ser la forma geométrica más compleja que pueden entender quienes pretendan seguir aplicando el modelo “en cascada”, ignorando que su primer descripción formal (Royce, 1970) era en realidad una crítica que exponía sus severas limitaciones.

Evolución del concepto de “éxito” en proyectos de software

Desde 1994, el Standish Group se ha dedicado a analizar el éxito y el fracaso de los proyectos de software, revelando en su informe CHAOS Report tendencias y factores determinantes en la gestión de proyectos tecnológicos.

Las conclusiones de la primera edición fueron contundentes: el 84% de los proyectos de software, resultaban deficientes o abandonados.

Si el 84% de los edificios colapsaran antes de ser terminados, preferiríamos vivir a la intemperie. Si el 84% de las cirugías fracasaran, aprenderíamos a andar por la vida cargando nuestros órganos en una bolsa. Pero en tecnología, esto no genera pánico ni titulares: simplemente se acepta como parte del paisaje.

Esta evidencia quizás haya ayudado a cuidar las variables, y con los años se haya observado una mejora de vez en cuando. Pero los mayores impactos los tuvieron dos grandes cambios de criterio:

• En 2001, el Manifiesto Ágil propuso una transformación en la gestión de proyectos, sugiriendo pasar del enfoque rígido y formalista a uno pragmático, que priorizara individuos e interacciones, software funcional, colaboración con el cliente y capacidad de respuesta ante el cambio.
• En 2015, el Standish Group ajustó su criterio de éxito, considerando como “exitosos” aquellos proyectos que, dentro del tiempo y presupuesto establecidos, lograban “resultados satisfactorios”, sin la necesidad de cumplir estrictamente con todo el alcance planificado.

Es así que en 2020, los proyectos ágiles mostraron más del triple de proyectos exitosos, y menos de la mitad de proyectos fallidos que sus contrapartes en cascada:

Entonces, ¿ya tenemos la solución para lograr el éxito?

Empecemos por observar que para 2020, la definición de éxito que se venía aplicando, resultaba un poquito anacrónica.

Como recordarán, esa definición había nacido para evaluar la informatización de procesos bien definidos. Pero la realidad es que para mediados de la década del ’80, de esos procesos quedaban pocos aún sin resolver. Buena parte de la industria se estaba volcando a producir software como producto, para usuarios de computadoras personales. Lo cual dio un vuelco final cuando terminando el siglo XX explotó la Internet.

Hoy en día, la mayoría de los proyectos de desarrollo de software se centran en la creación de sistemas destinados a ser utilizados por usuarios finales, ya sean herramientas internas para empleados o productos y servicios destinados a su lanzamiento y monetización en el mercado.

Esto implica que la definición de “éxito” debe considerar la aceptación por parte de los usuarios, una variable que el Standish Group no contempla al aplicar una estricta perspectiva de ingeniería.

Construyendo nuestra definición de “éxito” para la industria de las experiencias

Para construir nuestra nueva definición sobre la anterior, partimos de considerar exitosos sólo los proyectos que antes satisfacían esa medida.

Y luego, observamos que podemos tomar la cantidad de descargas de las Apps como medida de su aceptación en el mercado:

La distribución de descargas de aplicaciones sigue una ley de potencias, similar a la ley de Zipf: unas pocas aplicaciones acumulan la mayoría de las descargas, mientras que la mayoría recibe muy pocas.

Como vemos, el 80% de las aplicaciones no supera las 10.000 descargas. En un mercado de millones de usuarios, esto es prácticamente homeopático. Pero para peor, considerando que la mayoría de las apps se monetizan a un precio cercano a 1 dólar (o euro) por usuario, los ingresos obtenidos no alcanzarán para cubrir los costos de desarrollo, marketing y otros gastos asociados (de al menos, entre 18.000 y 100.000 €).

Del otro 20%, es la mitad es la que realmente se lleva la torta: tan sólo el 10% acapara el 90% de las descargas.

Pero para ser generosos y optimistas, digamos que el 20% es “exitoso” en lo que hace a aceptación. Y para calcular qué porcentaje de proyectos representa, tomamos el mejor valor del criterio del Standish Group (el 42% de proyectos técnicamente exitosos ). El producto nos daría los proyectos que podemos considerar exitosos tanto desde lo técnico, como en el mercado: tan sólo el 8.4% de los proyectos.

O en otras palabras:

En la industria de las experiencias, la probabilidad de fracaso es de más del 90%.

Si fuéramos muy generosos y tomáramos el 20% de no sólo al 42% de proyectos técnicamente exitosos, sino también del 47% de “desafiados” (de alguna manera, puestos en producción), la probabilidad de fracaso sería de un 82.2%. Lo cual sigue siendo terrible.

Ante eso, los capitanes de los proyectos, las personas en la punta de la pirámide de decisiones gerenciales de la que depende que los proyectos existan, suelen tener su foco en otra parte.

El muy probable fracaso del proyecto no es algo que los capitanes de los proyectos tengan activamente en el radar para evitarlo.

En parte, porque se han formado en otras aguas: gerentes con alto seniority que llegan a la aún naciente industria de las experiencias desde industrias más maduras como bienes y servicios, están confiados en saber reconocer a tiempo las tormentas. Esa confianza suele jugarles malas pasadas cuando los riesgos son tan abstractos como la materia con la que se trabaja: software y comportamiento. Y en donde las aguas, en lugar de hacer olas, tienden a espesarse hasta que se termina remando en dulce de leche.

Y en parte, porque como dice mi colega Kaleem Khan: “Nadie quiere creer que lo que ofrece es de mala calidad o deficiente, porque nadie se propone lograr un mal diseño como objetivo. Siempre es un riesgo. Los malos diseños y las malas experiencias… ocurren”.

Entonces, ¿qué es “éxito” para Experience Decision Making?

Frente a este escenario, en Kambrica y en XDM definimos el éxito en los proyectos sobre tres dimensiones:

1. Software funcionando vs. defectos y sobreproducción.

Siguiendo el manifiesto ágil, nuestra definición considera software funcionando (que puede portar valor real: producto que llegue a los usuarios), por sobre documentación extensiva.

La documentación no puede portar valor en sí misma, porque nunca llega a los usuarios finales. En el mejor de los casos, podemos considerarla equivalente a los andamios que se erigen al menor precio posible para poder construir un edificio. Pero de la misma manera en que un andamio bañado en oro no hace ninguna diferencia más que el mayor costo, hay un punto a partir del cual mayor esfuerzo y nivel de detalle en la documentación no se traduce en mejor software: nos encontramos ante un tipo de desperdicio.

Tomando la distinción entre valor y desperdicio de la filosofía Lean –y en particular, de Lean Software Development– nuestra definición de calidad del producto final evita:

• defectos: errores o funcionalidades rechazadas por clientes y usuarios.
• sobreproducción: funcionalidades ignoradas por clientes y usuarios, elaboración detallada de aspectos que finalmente se decide no lanzar, o documentación y entregables que, en todo o en parte, no aportan al valor final.

2. Aceptado y adoptado por usuarios reales vs. impuesto, resistido, rechazado.

La aceptación de los usuarios finales es crítica para un producto o servicio tecnológico que se pretende monetizar. Como vimos, sólo el 20% de las aplicaciones lanzadas logran superar las 10,000 descargas: en otras palabras, el 80% de los proyectos resultan económicamente inviables.

Pero la aceptación de los usuarios finales también es determinante para el caso de herramientas internas. Un software cometido sin ninguna consideración por la facilidad de uso y curva de aprendizaje, requerirá de horas o días de “capacitación”, y de un buen tiempo hasta que al usuario se lo pueda considerar productivo. He llegado a ver el caso de un Call Center donde se considera que cada nuevo empleado requiere de tres meses hasta tener suficiente dominio del sistema poder resolver todos los casos que requiere su función. Tres meses durante los que se le pagará un sueldo, y que el día que renuncie, habrá que volver a dedicar con su reemplazo.

Pero la historia no termina ahí. Una vez superado esa barrera inicial, el mal software seguirá cobrando su tasa. Cada minuto adicional que los empleados pierdan debido a software difícil de usar, que no se adecúa a su real proceso de trabajo, o simplemente ineficiente, será más productividad y dinero perdidos. El modelo KLM-GOMS permite estimar el tiempo adicional que los empleados tardan en completar sus tareas debido a problemas de diseño y usabilidad: multiplicado por el salario promedio, se puede obtener una estimación del costo asociado a la ineficiencia del software, que para una planta de miles de empleados resulta millonaria.

El software sólo puede lograr valor si es aceptado y adoptado. En el mercado, el software no aceptado no genera ingresos. En herramientas internas, la resistencia de los empleados al software que se les pretende imponer siempre refleja ineficiencias operativas, donde la mala usabilidad causa confusión, errores y pérdida de productividad.

3. Cumpliendo objetivos de Negocio vs. deseos, caprichos y fracasos.

Para que un proyecto sea exitoso, debe centrarse en objetivos de negocio claros y medibles. Lo cual empieza por el desarrollo de una habilidad ejecutiva crítica: distinguir Deseos de Objetivos.

Cuando por no conocer las aguas de la industria de las experiencias se priorizan deseos o caprichos de los stakeholders, el proyecto pierde enfoque y genera desperdicio de recursos, ya que se invierte tiempo en tareas que por definición no aportan valor al Negocio.

Sólo al definir bien los objetivos y alinearlos con las mejores prácticas de la industria es posible generar resultados de calidad, verdaderamente orientados a las necesidades del cliente.

Definir qué es éxito y Calidad, es el primer paso de todo proyecto.

La Calidad no se puede agregar a un producto ya terminado. Es el resultado de las decisiones de todos los involucrados en su construcción.

Para lograr mejores experiencias y mejores productos, necesitamos claridad y tomar mejores decisiones.

De eso se trata el sistema Experience Decision Making que desarrollamos en Kambrica.

La entrada La primer causa de fracaso de los proyectos, es no tener claro qué entendemos por “éxito”. 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.

Y así como consideran que creen conocer a sus clientes, seguramente consideran que conocen (¡y aún más!) a sus propios familiares, a su pareja, a sus hijos, a sus mejores amigos.

Pero no por eso pueden decir con absoluta certeza, qué regalarle a cada uno para su cumpleaños.

Porque “conocer” no es igual a “ser capaz de anticiparse a cada necesidad, cada percepción, cada deseo, cada respuesta”.

Para lograr un producto, sistema o servicio realmente efectivo, necesitamos poder conocer las consecuencias de las decisiones y alternativas de diseño que estamos considerando.

Eso lo podemos hacer anticipando, u observando. Y nuestra capacidad de anticipación tiene límites.

No podemos anticiparnos de forma total y efectiva a los demás. Porque los demás, simplemente, son otros: tan ricos y complejos como nosotros mismos.

Por eso, nuestra imaginación nunca puede abarcarlos por completo. O acaso en absoluto.

En los más de 20 años que llevo incorporando usuarios en el proceso de diseño, hay dos grandes verdades que siempre confirmo:

• Toda sesión con usuarios genera descubrimientos. A menos que esté mal hecha.
• La única gente que cree que no aprenderá nada de observar usuarios, es la que nunca lo ha intentado.

Por eso, cuando oigo “no necesitamos UX Research”, lo que escucho es: “nunca antes hicimos UX Research, estamos ciegos y no sabemos de lo que nos estamos perdiendo”.

“No necesitamos UX research” no es una negativa. Es la forma que tienen los decisores de invitarnos a que les descorramos el telón de un mundo de oportunidades.

Santiago Bustelo
febrero de 2025

La entrada “No necesitamos UX Research, conocemos a nuestros usuarios” se publicó primero en Kambrica.

Es usual que para mejorar el producto, el Negocio traiga a la mesa ideas que corren detrás del tren de moda del momento, como ayer era “metele Blockchain” y hoy es “metele AI”.

Ante estas propuestas, la respuesta habitual de UX es hacer preguntas que, aunque esenciales, suelen parecer confrontativas, cuestionando directamente valor de la idea, o incluso a la persona que la propone.

Y ahí es cuando la gente de Negocio, que venía entusiasmada y enamorada de su, nos acusa de tener “un problema para cada solución” :)

Me ayuda mucho en esas conversaciones la distinción que compartió Juan Carlos Lucas en nuestro espacio UX Minds: “No es lo mismo tener ideas que tener ofertas”.

Porque cuando tenemos una ideas, nos validamos a nosotros mismos. Pero a las ofertas las valida un tercero: el cliente final.

Y por eso, nuestra respuesta profesional al Negocio es que desde luego, lo que trae puede ser una buena idea. Nuestro trabajo será convertirla en una buena oferta. Y pulirla hasta lograr una especificación validada que Desarrollo pueda implementar.

Y ahora sí, con la creación de valor para el cliente final como marco común, remando todos en la misma dirección, podemos empezar a hacer las preguntas correctas y tener una conversación productiva:

– ¿Qué problema/s queremos resolver?…
– ¿A quién/es?…
– ¿Cómo sabremos si lo logramos?

La entrada No es lo mismo tener una buena idea, que tener una buena oferta. se publicó primero en Kambrica.

Esa definición, que siempre comparto con equipos de IT, resume el verdadero valor del diseño UX para proyectos de software.

Las especificaciones validadas que entrega UX a IT (de las cuales, las más características son los planos de la aplicación: esquemas y diseños para su implementación), no pueden limitarse a la aprobación del Negocio, sino que también deben haber sido validadas con usuarios finales para que se consideren entregables de UX (y no simplemente UI).

¿Por qué es crucial esta validación? Porque mitiga tres problemas comunes en el desarrollo:

• Incertidumbre: saber desde el principio qué necesita el usuario evita conjeturas y suposiciones incorrectas.
• Retrabajo: identificar errores antes de la producción reduce costos y tiempos.
• Deuda técnica: decisiones informadas evitan soluciones rápidas que generan problemas a largo plazo.

De estos desafíos, es IT quien termina pagando el precio en horas extra, correcciones urgentes y sobrecarga técnica.

UX no es decoración de pantallas. Es una práctica que permite al Negocio tomar mejores decisiones y a IT desarrollar software más sólido y sostenible.

UX Research: La clave para la agilidad real

Mantener UX Research no es un lujo: es la base para ser realmente ágiles. La agilidad no significa trabajar rápido, sino tener capacidad de respuesta. Como suelo ejemplificar:

Ágil, es el esquiador olímpico que supera los obstáculos y llega a la meta. Apurado, es el que termina en el hospital.

Para desarrollar software ágil, primero debemos mirar hacia dónde vamos.

Sin research no hay Visión validada

Salir a producción sin UX Research es equivalente a lanzar una bola de nieve sin control. Puede que no sea evidente ni inmediato el desastre, pero eventualmente nos alcanzará.

• No hacer research significa operar a ciegas, ignorando la realidad del usuario final.
• Culpar al usuario por “no entender” solo refuerza el fracaso.

Porque ser ágiles no es lanzar software rápido. Es lanzar software que realmente funcione. Y un software sólo funciona si hay usuarios que lo operen. Sin usuarios, no hay software: sólo hay código que nadie ejecuta.

El verdadero éxito del software no está en su capacidad de ser ejecutado, sino en su capacidad de ser adoptado y utilizado.

Para IT y Negocio, UX Research no es una opción: es el camino hacia construir Valor en lugar de Desperdicio. Es la clave para lograr soluciones más robustas y efectivas.

La entrada UX Research para IT y Negocio: Cómo mejorar la toma de decisiones y el desarrollo de software se publicó primero en Kambrica.

En UX pasa algo parecido: hay gente de negocio y producto capaz de agotar todas las métricas y herramientas inventadas y por inventar, antes que tomarse un par de horas en observar a sus usuarios – el único “truco” que funciona para lograr resultados.

Emplear esas herramientas sin antes haber observado usuarios reales, es como pretender diagnosticar a un paciente sin mirarlo, sólo leyendo los análisis del laboratorio.

Nuestro paciente tiene exactamente 39.1° de fiebre

Buenísimo, ¿entonces, sabemos cómo bajarla? No. Porque una medida no es un diagnóstico.

Un diagnóstico es producto de un entendimiento del problema. Y eso empieza por lo cualitativo: entender cuál es la situación y cuáles son sus causas.

Analytics, mapas de calor, registro de sesiones, análisis con inteligencia artificial y tantas otras, pueden ser de gran utilidad para hacerse una idea o medida lo que sucede en la pantalla. Pero la experiencia de usuario no es eso: es lo que sucede delante de la pantalla. Sólo partiendo de ahí podemos dar contexto y sentido a lo demás.

Facilitar e interpretar sesiones cualitativas con usuarios y clientes reales requiere de oficio, experiencia, entendimiento de usabilidad, diseño, tecnología y de dominio. Observarlas requiere aceptar que los hallazgos puedan poner en duda decisiones de negocio, y de una cultura empresarial ansiosa por conocer sus problemas cuando todavía son pequeños, en lugar de barrerlos debajo de la alfombra para que crezcan y le exploten a otro.

Mirar lo que escupe una máquina nos evita todas esas complejidades y permite lecturas superficiales, relajadas y sobre todo impunes, propias de la astrología, el tarot y la interpretación de la borra del café. Porque bajo el manto de la aparente objetividad de los números, se esconde la triste pantomima que detallo en “Cargo Culting Management”:

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

Aquí van algunos ejemplos de interpretaciones apenas un poco más ridículas que muchas que escuché en estos años. Las cometí con la ayuda de una AI, una herramienta invaluable para vomitar incoherencias que suenen bien:

• “La gráfica de bounce rate tiene forma de una montaña rusa, lo que sugiere que nuestros usuarios están viviendo una experiencia emocional intensa al navegar por nuestro sitio”
• “La baja tasa de conversión en esta página se debe a que la UI tiene una mala feng shui, ya que los elementos del formulario alineados a la izquierda crean una energía negativa que bloquea al usuario”
• “El aumento en las búsquedas de keywords relacionadas con la competencia podría indicar que estamos siendo víctimas de amarres y gualichos por parte de nuestros rivales”
• “Al analizar los datos de cohortes, podemos ver que los usuarios que se registraron en enero tienen una mayor tasa de retención, lo que sugiere que nuestra marca se hace fuerte en Capricornio: es ambiciosa, persigue metas a largo plazo y es muy disciplinada en su ejecución”
• “Al analizar el mapa de calor, podemos ver que los usuarios se sienten atraídos por los elementos más brillantes, eso indica que nuestro mercado objetivo son las polillas”

Si esto te resulta exagerado, pero familiar… es momento de dejar de poner el carro adelante del caballo. Sin procesos maduros de toma de decisiones, ninguna herramienta es mejor que un placebo.

Santiago Bustelo
Septiembre 2024

La entrada Así como en EEUU miden en cualquier cosa menos metros, hay gente de Negocio capaz de cualquier cosa para no verle la cara a su cliente. se publicó primero en Kambrica.

La función de la consultoría estratégica es cultivar esta habilidad y facilitar la construcción de objetivos sólidos. Para marcar la diferencia entre deseos y objetivos, planteo el siguiente ejemplo:

Deseo: “Que dure para siempre”

Supongamos que en la primer reunión del proyecto, un stakeholder plantea que el producto deberá “durar para siempre”.

Si la reunión no se planteó formalmente como una sesión de brainstorming, como consultores estratégicos es nuestra señal para declarar que:

• está muy bien esa idea como puntapié inicial para iniciar esa práctica creativa,
• preguntar si hay otras ideas más, y
• anunciar que en una segunda etapa, refinaremos todas esas ideas para lograr las definiciones clave, de cuya aprobación dependerá el inicio del proyecto.

Porque no se puede tomar “que dure para siempre” como una definición válida sobre la cual empezar ningún proyecto.

¿Hasta cuándo sería “para siempre”? ¿Por toda la eternidad? ¿Acaso el producto debe sobrevivir a la muerte térmica del universo? Claramente eso es imposible. ¿El producto debería durar millones de años? Pongámosle que miles, nomás. ¿Cómo podemos calcular cuánto costará construir algo semejante? Y sobre todo, ¿qué sentido tiene?

“Que dure para siempre” es un deseo. Expresa una aspiración sin tener en cuenta factores prácticos, límites técnicos ni realistas. No resulta accionable, verificable, viable, ni de utilidad para encarar un proyecto.

Si un stakeholder no puede entender esta condición, si no puede aceptar la facilitación necesaria para transformar este enunciado vulgar en un objetivo válido, entonces no hay proyecto posible bajo términos racionales. O no habrá nada que lo pueda satisfacer, o aceptará las promesas del mejor charlatán.

Nuestro trabajo en consultoría estratégica, es ayudar a los decisores a convertir estas declaraciones en objetivos válidos. Por ejemplo:

Objetivo: “El Tiempo Medio Entre Fallas debe exceder la vida útil esperada del producto”

Esta declaración es un objetivo porque es clara, específica y medible. Puede ser alcanzada y evaluada.

Se compone de dos definiciones técnicas aceptadas y maduras: la primera, el Tiempo Medio Entre Fallas, es un concepto de ingeniería perfectamente aplicable al desarrollo de software.

La segunda, la vida útil esperada del producto, depende de expectativas de los clientes generadas por el mercado y por nuestra propia oferta.

Lo genial de este objetivo es que puede cumplirse mediante dos estrategias complementarias: aumentar el Tiempo Medio Entre Fallas (un problema de ingeniería), y/o acotar la expectativa de los clientes sobre la vida útil del producto (un problema de marketing).

Si estamos construyendo una sonda espacial o un marcapasos, una larga vida útil resulta una expectativa básica y crítica. Pero un juguete eterno no será bueno para quien lo compra, ni para quien lo fabrica. Los padres verán horrorizados cómo su criatura descubre que su juguete irrompible, es muy útil para romper otros juguetes. Y los fabricantes terminarán bajando la cortina y viendo cómo los pocos juguetes que lograron vender pasan de hermano a hermano, de generación a generación, y así por los siglos de los siglos.

La pata del mono vs. el pie derecho

Pretender basar un proyecto sobre deseos en lugar de objetivos, es como pedirle deseos a la pata de mono. Como en el cuento de W.W. Jacobs, lo que al principio parecen ser buenas ideas, se revelan finalmente como una maldición.

En Kambrica ayudamos a empresas de todo tamaño –desde startups hasta Fortune 500– a transformar deseos en objetivos claros y alcanzables, fundamentales para el éxito de los proyectos.

Alinear las expectativas y los procesos de toma de decisiones de los stakeholders hacia un horizonte viable es la única forma de empezar un proyecto con el pie derecho.

La entrada Una habilidad ejecutiva crítica: distinguir Deseos de Objetivos se publicó primero en Kambrica.

¿Cómo fabrican estas “proyecciones” sensacionalistas?

Con matemática básica, aplicada a lo bestia.

La cosa es más o menos así: cuando no tenemos todos los valores que necesitamos de una serie, podemos acudir a diferentes métodos para inventar los faltantes.

Si los valores que nos faltan son los del medio, podríamos calcular los que estén a medio camino entre los que tenemos. A eso se le llama “interpolación”. Si bien no es “correcto”, puede resultar más aceptable que no tener el dato.

Cuando los datos que nos faltan están fuera de la serie (por ejemplo, porque corresponden al futuro y aún no los tenemos), podemos tomar los últimos disponibles, ver la relación entre ellos, y aplicarla hacia adelante para estimar el siguiente valor. A eso se lo llama “extrapolar”. Lo cual, como en el caso anterior, tampoco es “correcto”, pero puede resultar aceptable.

El problema es que cuantos más datos extrapolemos, mayor será nuestro margen de error. Los primeros datos estarán más o menos cerca de los valores reales que aún no tenemos. Pero si seguimos extrapolando sin más, es prácticamente seguro que los datos que obtendremos y las conclusiones que saquemos, serán basura.

Un ejemplo práctico

Para proyectar cómo crecerá un bebé, podemos partir de cuánto mide al nacer (49.9 cm) y al cumplir el primer mes (54.7 cm).

Entre estos valores, hay una diferencia de un 9.6%. Si empleamos esta relación para calcular los valores de los dos meses siguientes, estaremos aplicando una extrapolación exponencial:

A primera vista, parecen más o menos aceptables los valores que obtuvimos para nuestro bebé imaginario, al cual llamaremos Bebᵉˣᵖ. Comparemos con datos reales de la OMS:

Nuestro Bebᵉˣᵖ resultó más alto que un bebé real de tamaño medio. Pero no más grande que un bebé real muy grande (el 0.27% de la población). Para haber fabricado esta información con tan poco, podríamos decir que está mal, pero no tan mal.

Hasta acá, podríamos festejar nuestro moderado éxito y retirarnos con gloria.

Pero el éxito es adictivo, y queremos más.

Así que seguimos extrapolando.

Es así que para los seis meses, nuestro Bebᵉˣᵖ no sólo habrá sobrepasado al bebé más grande, sino que estará compitiendo en tamaño con un lavarropas:

Desde luego, puede ser peor – al igual que las “predicciones” de que la AI tendrá inteligencia infinita.

Al cumplir 18 meses, ocurrirán dos cosas:

• Bebᵉˣᵖ ya será más bien un Pibᵉˣᵖ
• Ya no nos entrará en el departamento.

Pero se pone mejor.

Al cumplir 6 años, Pibᵉˣᵖ habrá superado a la Torre Eiffel:

Lo maravilloso de la función exponencial es que una vez que las cosas son enormes, en muy pocos pasos se vuelven monstruosas.

Porque crecer un 9,6% mensual, sobre el 9,6% del mes pasado, y así durante 12 meses, resulta en un tamaño final tres veces el inicial.

Y el triple de un montón, es una bestialidad.

Es así que para cuando cumpla 9 años, Pibᵉˣᵖ tendrá que usar escafandra, porque habrá superado el límite de la Troposfera y le será imposible respirar. Eso, o vivir patas para arriba.

Poco antes de cumplir 19 años, habrá cabeceado la luna. A los 34, medirá prácticamente 1 año luz. Y antes de cumplir los 60, habrá superado el tamaño del universo observable.

Eso sería, la “singularidad”, supongo.

Conclusión

Al extrapolar torpemente más allá de unos pocos datos, aplicamos el supuesto de que la tendencia inicial se mantendrá hasta el infinito. Pero en la realidad, tarde o temprano, todo encuentra algún tipo de límite.

Todos tenemos una idea de las diferentes etapas y límites del crecimiento humano, y reconocemos el absurdo en el crecimiento de Bebᵉˣᵖ. Pero ante lo nuevo, la falta de referencias permite que proyecciones desbocadas pasen por debajo del radar y acampen en el espacio de lo verosímil.

Una de las proyecciones exponenciales más famosas de la informática, es la “ley de Moore”: la observación de que la cantidad de transistores que los fabricantes logran meter en un microprocesador, se duplica cada unos dos años.

Más allá de opiniones de si aún sigue aplicando o no, la última palabra la tienen las leyes de la física. La carrera por la miniaturización tiene una línea final: es imposible fabricar un transistor que mida menos que un electrón.

A partir de allí, o más probablemente mucho antes, la única forma de duplicar la cantidad de transistores sería duplicando el tamaño. El escenario en el que un microprocesador duplique su tamaño cada dos años, es el mismo que el de Bebᵉˣᵖ, sólo que con factores distintos: un iCorᵉˣᵖ que empiece midiendo 1 x 1 cm, tocará la luna en 70 años. Le tomará poco más de 119 años alcanzar su primer año luz.

Desde luego, eso no es lo que ocurrirá. Porque nada, absolutamente nada, puede crecer indefinidamente.

Cuando extrapolando al futuro llegamos a conclusiones increíbles, eso no significa que nos espere un futuro increíble “porque es lo que dicen los números”. Los números son un invento humano. Y lo más probable, es que hayamos hecho mal las cuentas.

La entrada Extrapolando hasta el absurdo y más allá se publicó primero en Kambrica.

Al año siguiente, la “excelente” Atari, se derrumbó de forma catastrófica: perdió 536 millones de dólares y tuvo que enterrar miles de juegos y equipos no vendidos en la basura. Terminó disuelta en 1984.

Ante las dudas que empezaron a surgir sobre su análisis, Tom Peters mostró una envidiable elegancia. Simplemente dijo que considerar a Atari una empresa excelente había sido un error, y siguió vendiendo su libro.

¿Fue realmente tan sólo un error aislado? Me propuse ver qué pasó en estos 40 años con las empresas que analizaron Peters y Waterman, y si su teoría ha sido lo suficientemente sólida para superar el paso del tiempo.

En el libro, los autores habían analizado 62 empresas, de las cuales habían destacado 43 como “excelentes”. Las otras 19 quedaban en la categoría “prometedoras”, con potencial para alcanzar la excelencia en el futuro.

Después de cruzar fuentes, encontré que 30 empresas del total (∼48%) se habían convertido en advertencias, vendido a la competencia, o desaparecido. De estas empresas caídas en desgracia, 18 habían formado parte de la selecta lista de empresas “excelentes” (∼42% de bajas).

Atari no fue un caso aislado ni una excepción. Tan sólo la primera en caer.

Confesiones post mortem

A fines del año 2001, cuando “In search of Excellence” había cumplido casi 20 años, Tom Peters escribió un artículo en donde confesó que los datos habían sido fraguados, lo cual explica algunas cosas. Para entonces, ya iban 19 empresas caídas en desgracia.

Pero a continuación de su confesión, Tom desestimó las objeciones que recibió desde que Atari inauguró la lista, diciendo que “pasaban por alto completamente el punto central”. A renglón seguido, se fue por las ramas y empezó la historia de cuando estaba de moda llevar una cebolla en el cinturón.

Como Tom no tuvo la cortesía de desarrollar “el punto central” de manera concisa, decidí pasarle el artículo completo a ChatGPT y pedirle que me extrajera el punto central. Me dio esto:

El punto central al que Tom Peters se refiere en sus palabras es que la búsqueda de la excelencia no se trata simplemente de obtener resultados financieros o de cumplir con métricas predefinidas. Peters argumenta que el verdadero éxito empresarial va más allá de los números y se centra en aspectos como el compromiso con la innovación, el enfoque en las personas y los clientes, la pasión y la búsqueda desinteresada de un ideal. En otras palabras, el “punto central” es que la excelencia empresarial implica más que simplemente alcanzar cifras rentables; se trata de crear una cultura organizacional que valore la calidad, la creatividad y el compromiso humano en todos los aspectos del negocio.

Así que ya saben. Si separamos la paja del trigo, desestimamos los datos falsos, la falta de capacidad predictiva, las exageraciones, la verborragia y la logorrea, nos queda que la vida y obra del gurú del management Tom Peters, podría haber sido un mail recitando perogrulladas.

Lecciones de 1982 a 2022: lista de empresas ejemplares (de lo que no hay que hacer)

Para referencia, les dejo la lista de empresas que en los 40 años desde la publicación de “In Search of Excellence”, podemos considerar advertencias más que “ejemplos de excelencia”.

En negritas, destaco las empresas consideradas excelentes según Tom y Bob. Para más detalle, identifico con asteriscos y cruces:

• (**) Empresas que “superaban todos los requisitos para ser consideradas excelentes”, ubicadas en la parte superior del cuadro original (“entrevistas estructuradas y revisión bibliográfica de 25 años”).
• (*) Empresas que “superaban todos los requisitos”, de la parte inferior del cuadro (donde las entrevistas habían sido “limitadas”).
• (††) Empresas de la parte superior del cuadro para las cuales no había “información extensiva públicamente disponible”, pero que aún así los autores “estimaban” que pasaban los requisitos.
• (†) Empresas “estimadas” como “excelentes”, de la parte inferior del cuadro.

En orden cronológico de disolución, pedido de quiebra, adquisición o fracaso notable:

1. Atari † (perdió 536 millones de dólares en 1983, debiendo literalmente enterrar sus videojuegos, consolas y computadoras en la basura; finalmente fue disuelta en 1984 y sus activos vendidos a diferentes compañías)
2. Western Electric (desmantelada en 1984, difunta en 1996)
3. Xerox (invirtió millones de dólares para crear innovación que capitalizaron otros. La computadora Xerox 820, que no aplicó ninguna de esas innovaciones, fue discontinuada en 1985. El mismo Tom Peters dijo en 2001: “Si se podía hacer mal, Xerox lo estaba haciendo mal”)
4. Allen-Bradley †† (adquirida por Rockwell Automation en 1985)
5. General Foods (adquirida por Philip Morris Companies en 1985; la marca terminó de desaparecer en 1995)
6. Chesebrough-Pond’s * (adquirida por Unilever en 1987)
7. Gould Electronics Inc. (absorbida parcialmente por Nippon Mining en 1988, cerrada en 2014)
8. Wang Labs * (bancarrota en 1992; la forma en que llevó adelante sus Procesadores de Texto es para Jared Spool un caso ejemplar sobre modelos de negocios destinados al fracaso en la industria informática)
9. Westinghouse (adquirida por CBS en 1995)
10. IBM ** (lanzó la PC en 1981; dos años después Compaq comenzó a desplazar a IBM del mercado del hardware. Apostó entonces al mercado del software, desarrollando OS/2 junto con Microsoft, que la acuchilló por la espalda para quedarse con ese mercado. En 1996, IBM lanzó la última versión de OS/2, despidió a 1300 personas y se despegó del producto)
11. Amdahl ** (adquirida por Fujitsu en 1997)
12. Hughes Aircraft † (adquirida por Raytheon en 1997)
13. DEC — Digital Equipment Corporation ** (incapaz de adaptar su modelo de negocios tras la aparición de las PCs, fue adquirida por Compaq en 1998, que no supo muy bien qué hacer con ella, se encontró a su vez en dificultades financieras, y se fusionó con Hewlett-Packard en 2002)
14. Standard Oil (Indiana)/Amoco * (adquirida por BP en 1998)
15. Data General * (adquirida por EMC Corporation en 1999, que cerró todas las líneas excepto CLARiiON, hasta que en 2012 le desconectó el respirador)
16. Raychem * (adquirida por Tyco International en 1999)
17. Arco (adquirida por BP en 2000)
18. Polaroid (bancarrota en 2001)
19. Rockwell (disuelta en 2001)
20. K mart * (bancarrota en 2002, cerrando más de 300 tiendas y despidiendo a unas 34.000 personas)
21. TRW (adquirida por Northrop Grumman en 2002)
22. Boeing ** (escándalo por espionaje industrial y corrupción en 2003; en crisis desde 2019 por accidentes del B737 MAX)
23. Delta Airlines ** (bancarrota en 2005)
24. Dana Corporation ** (bancarrota en 2006)
25. Maytag * (adquirida por Whirlpool Corporation en 2006)
26. National Semiconductor * (adquirida por Texas Instruments en 2011)
27. American Airlines (bancarrota en 2011)
28. Eastman Kodak ** (al igual que Xerox, ignoró la innovación que se producía en sus propios laboratorios; finalmente otros avanzaron con la fotografía digital y terminó declarando la quiebra en 2012, de la cual emergió cual zombie que se resiste a morir)
29. McDermott (bancarrota en 2020, de la cual se repuso tras equilibrar 4.600 millones en deuda)
30. United Technologies (adquirida por Raytheon en 2020)

La entrada “In search of excellent failures”: en busca de los fracasos ejemplares en la obra de Tom Peters se publicó primero en Kambrica.

Acabo de mirar. Pasados más de 5 años, la App tuvo… poco más de 100 descargas.

Lecciones aprendidas

Hay proyectos que salen bien, y proyectos de los que se aprende. De éste, aprendimos un montón:

1. Muchos gerentes no tienen necesariamente como prioridad los resultados del Negocio. Su verdadera preocupación es mantener la red de promesas que los sostiene. Si esa red está construida con resultados o con bullshit, es otro tema.
2. Muchos gerentes son como los pacientes de Dr. House: mienten.
   Por ignorancia, por vergüenza, por lo que sea, mienten.
   En este caso, no necesitaban UX e innovación. Necesitaban un cómplice. Es un servicio que en Kambrica no ofrecemos, así que hicieron bien en cambiar de proveedor.
3. Es frecuente que antes de llamarnos, nuestros clientes ya hayan tomado decisiones de diseño, sin siquiera saber que son decisiones de diseño. Ello me llevó a estudiar sobre el tema y construir el encuentro entre UX y Teoría de la Decisión. Aplicando este modelo, podemos entender mucho mejor la situación inicial de nuestros clientes y reducir fricciones desde el principio.
4. “Me dijeron q para hacer UX en serio, hay q medir NPS y mostrar el impacto en los resultados del Negocio”
   NPS es numerología, Papá Noel no existe, los Reyes son los padres, y tal vez el gerente que nos contrata tenga otras prioridades antes que los resultados del Negocio.

Por todo eso, resulta crítico esclarecer desde el principio cuáles son los verdaderos objetivos del proyecto, si están alineados con los de la organización, nuestra ética profesional y nuestras competencias técnicas.

En Kambrica, declaramos nuestro compromiso en ayudar a tomar decisiones informadas que reduzcan desperdicios, riesgos e incertidumbre. Esto implica ser honestos y transparentes, especialmente cuando “duele”: decirle al cliente que no necesita una App, que está en el camino equivocado, o que su problema no es de UX.

Este compromiso nos permite trabajar con quienes realmente valoran nuestro aporte estratégico. Y nos evita malentendidos y mutuas pérdidas de tiempo con quienes están buscando otra cosa.

La entrada A muchos gerentes no les importan los usuarios. Pero tampoco, los resultados del Negocio. se publicó primero en Kambrica.

Una decisión de calidad requiere de modelos racionales, alimentados con información válida.

Cuando no tenemos modelos adecuados, caemos en diferentes formas de superstición. Una muy extendida en nuestra industria, es el cargo culting: la imitación superficial de un proceso o práctica sin comprender su verdadero propósito o significado.

El Cargo Culting (literalmente, “culto a la carga”) surgió y fue descubierto a mediados del siglo XX. Es un fenómeno realmente fascinante, y su historia no tiene desperdicio.

Resulta que durante la Segunda Guerra Mundial, los norteamericanos establecieron bases en las islas del Pacífico. Algunas de esas islas todavía no habían tenido contacto con la civilización moderna.

Una vez que la guerra terminó, fueron los antropólogos a ver qué había pasado. Y se encontraron con proto-religiones, que sostenían que imitando lo que habían visto hacer a los soldados, lograrían que “lleguen de los cielos” los aviones con “las ofrendas de los antepasados”. Esto es, víveres, autos, materiales de construcción… la carga.

Es así como los nativos construyeron “aeropuertos” con ramas, esperando que los antepasados los vieran desde el cielo y les hicieran llegar sus ofrendas.

Estas creencias aún hoy persisten, disfrazadas de tradición. Aquí vemos a los nativos marchando hoy como hacían sus padres, imitando las marchas militares:

“Ojalá llueva guita”: la danza de la lluvia gerencial

Y así como estos nativos creían que sus pantomimas atraerían a las “ofrendas”, nuestra industria está llena de gerentes que esperan lograr resultados imitando a gerentes, empresas y equipos exitosos.

O sea, Cargo Culting Management.

Me he cruzado con más de uno que, habiendo leído alguna hagiografía de Steve Jobs, decidió que la clave del éxito era ser cómo él: o sea, un cretino que maltrata a su equipo. La parte del libro donde cuentan que estudió caligrafía y cultivó su apreciación por el arte y el diseño antes de opinar sobre diseño, se la saltearon.

Este tipo de personajes es tan patético que resulta inofensivo.

Lo peligroso son los otros. Los que parece que saben lo que hacen, porque imitan la apariencia de saber lo que hacen.

Los que por ejemplo, creen que “son ágiles” por “practicar los rituales”, hundiendo a sus equipos en el dogmatismo y la alienación profesional. Y todo, por no haber entendido un manifiesto de tan sólo cuatro líneas. ¿Qué parte de “Individuos sobre procesos y herramientas” no les entra?

Otro fenómeno es el uso de métricas por imitación y desde el pensamiento mágico, sin realmente entender qué están midiendo ni qué hacer con esas medidas. A lo sumo, sacar promedios, ver si un valor es mayor o menor que el otro, y otros ejercicios propios de escuela primaria.

Una cultura de gestión inmadura no mejora “midiendo cosas”. Mejora adoptando procesos racionales de toma de decisiones. Mejora dejando atrás el pensamiento mágico y las supersticiones.

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

El NPS es el mejor ejemplo de esta tendencia. Es una aberración metodológica que no permite identificar las causas de los problemas ni sirve para medir el progreso. Pero, se aplica porque se supo que otro lo aplicó, y no podemos ser menos. Cargo Culting Management.

Cargo Culting Design “Thinking”

Otro ejemplo de pensamiento mágico, es tener fe en que lograremos el éxito aplicando “de manual” alguna “metodología de diseño” como “Design Thinking”, “Doble Diamante” o “Design Sprint”. Que lejos de recetas para el éxito, no son más que un simplificaciones didácticas, destinadas a lograr un entendimiento inicial del proceso de Diseño, en personas que nunca antes habían diseñado nada.

En la misma línea, pero más caro, es creer que se puede “tener” UX, como si fuera una cosa tangible. Ello se manifiesta usualmente en “tener” un “laboratorio de innovación”; si es colorido y vidriado, mejor.

Vendría a ser como una pecera con animalitos exóticos para mostrarle a las visitas. Si a alguno se le ocurre salir de la pecera y traernos alguna de sus locas ideas, lo agarraremos de las patitas y con mucho cariño, lo pondremos de vuelta en su lugar.

Es un antipatrón reinventado una y otra vez. Alcanza con repasar la historia del ya mítico Xerox PARC, donde cristalizó la informática que conocemos hoy… y que explotaron Apple y Microsoft. A Xerox, lo único que le importaba era seguir vendiendo fotocopiadoras.

Steve Jobs aprendió muy bien esa lección y es famoso por estar en contra de mantener la innovación en un “laboratorio” separado, desarrollando “conceptos”. Bajo su dirección, Apple siempre desarrolló productos viables: Real Artists Ship.

La mayoría de los gerentes que dice querer innovar, no anhela el resultado, ni mucho menos el proceso. Sólo el status de “ser innovador”. Por eso, la mayoría de las empresas no integra innovación en el Negocio: la mantiene aparte y a raya.

En otras palabras: la mejor manera de asegurarse de que la innovación nunca suceda, es teniendo un laboratorio de innovación. Lejos del negocio, que quede linda pero que no moleste.

Si tus competidores se tiraran de un puente, ¿qué harías? ¿Salto mortal, bomba o de cabeza?

El corazón del Cargo Culting Management es creer que alcanzaremos el éxito si imitamos a los demás. Sobre todo, a los exitosos.

Ese supuesto es falso.

Había una vez un consultor de McKinsey que creyó que, si analizaba las empresas líderes del mercado, podría destilar la fórmula del éxito gerencial. Muy seguro de sí mismo, renunció a su trabajo, escribió el libro y salió a venderlo.

El libro, “In Search of Excellence”, vendió millones y catapultó a Tom Peters como el nuevo gurú del management. A él le fue muy bien. Pero a las empresas que había señalado como excelentes, no tanto: la tercera parte de las empresas que el libro presentaba como excelentes y ejemplares en 1982, estaba en crisis tan sólo dos años después.

La caída de Atari fue particularmente espectacular. Cruzando datos, encontré que al día de hoy, casi la mitad de las empresas analizadas se convirtieron en advertencias o desaparecieron.

Tom había apostado por los caballos más gordos, no por los mejores. Por ejemplo, apostó por Xerox, que en ese momento tenía tanta, pero tanta plata, que podía darse el lujo de patinar millones en el PARC. Esa inversión, como ya sabemos, la capitalizaron Apple y Microsoft… que Tom Peters ni siquiera había registrado en su radar.

La absoluta incapacidad predictiva de la teoría de Tom Peters, llevó a Merrill Chapman a pensar que la cosa era exactamente al revés: en lugar de buscar ejemplos en los exitosos, hay que aprender de los errores de los fracasados. Sobre todo, si parecían muy exitosos antes de caer catastróficamente.

Y es así como en su libro “In Search of Stupidity”, Chapman se dedica a repasar las decisiones que llevaron a varias empresas exitosas a la ruina. Su conclusión, bastante mordaz y sensata, es que el secreto del éxito empresarial no está en imitar a las “empresas excelentes”: está en hacer las cosas menos mal que los demás, y especialmente, en evitar cometer estupideces de las que no puedas recuperarte.

Sin modelos adecuados, es simplemente imposible saber si estás cometiendo estupideces. Hasta que alguna de ellas resulta fatal.

Santiago Bustelo
Febrero 2024

La entrada Cargo Culting Management: imitarle los berrinches a Steve Jobs no te garantiza el éxito se publicó primero en Kambrica.

Puede ser que quien las haga de vuelta, y logre hacerlas bien, no seamos nosotros… sino nuestro competidor, aprendiendo de nuestros fallos.

Por ello, siempre es mejor hacer las cosas bien desde el principio.

A pesar de que, puesto así, resulte tan simple y hasta obvio invertir en calidad, lo usual es el foco en salir rápido y barato.

Como resultado:

• La gente apurada comete errores.
• La gente que construye tecnología apurada, comete errores que la tecnología multiplica.
• De los errores se aprende, pero sólo si hay capacidad de analizarlos – lo cual es imposible si nos mantenemos apurados y, peor aún, bajo creciente presión por los errores que vamos acumulando. Cualquier oportunidad de aprendizaje quedará para la competencia.
• Por si no fuera suficiente, nuestra incapacidad de reconocer y corregir nuestros errores se cristalizará como costo hundido y deuda técnica, entorpeciendo todo avance futuro. La competencia, en cambio, tendrá el camino despejado.

En una industria competitiva, si no somos el ejemplo, somos la advertencia.

Reemplazar propósito por urgencia, resulta en un suicidio empresarial: avivar a los competidores, regalarles el negocio en bandeja, y multiplicar toda la inversión en desarrollo y publicidad por cero.

Algunos casos ejemplares:

• MySpace (2007): MySpace priorizó el crecimiento rápido sin invertir adecuadamente en la mejora de la plataforma. Problemas de usabilidad, seguridad y una interfaz desordenada alejaron a los usuarios. Facebook y Twitter aprendieron de los errores de MySpace, ofreciendo experiencias de usuario más limpias y seguras. MySpace perdió su base de usuarios y relevancia, siendo eventualmente vendido a una fracción de su valor anterior. Mientras escribo estas líneas, MySpace permite iniciar sesión con… Facebook o Twitter.
• Windows Phone (2010): Microsoft apresuró el lanzamiento del sistema operativo móvil para competir con iOS y Android. El sistema operativo carecía de muchas aplicaciones y funcionalidades comparado con sus competidores. La falta de adopción por parte de los consumidores y desarrolladores resultó en la eventual retirada de Microsoft del mercado móvil, mientras que Apple y Google consolidaron su dominio en el mercado móvil.
• BlackBerry PlayBook (2011): BlackBerry lanzó el PlayBook para competir con el iPad, tan a las apuradas que lo lanzó sin un cliente de e-mail nativo. Las malas ventas y la pérdida de participación de mercado perjudicaron a BlackBerry, que ya no está entre nosotros.
• Google Glass (2013): Otras empresas aprendieron de los errores de Google para desarrollar sus propias tecnologías de realidad aumentada. Google terminó descontinuando el producto, perdiendo la inversión inicial y el potencial de mercado.
• Samsung Galaxy Note 7 (2016): Samsung apresuró su lanzamiento para competir con el iPhone 7. El resultado fueron baterías defectuosas que causaron incendios y explosiones. Los retiros masivos y la pérdida de confianza resultaron en enormes costos financieros y de reputación para Samsung, que fueron aprovechados por Apple y demás competidores.
• Y por último, la mayor catástrofe de la industria aeronáutica en los últimos 20 años, el Boeing 737 MAX (2018): Boeing aceleró su desarrollo a un nivel de imprudencia criminal. 346 muertos llevaron a la inmovilización global de la flota, causando pérdidas financieras, un impacto negativo en la reputación de Boeing, y una oportunidad para Airbus.
  Las pérdidas financieras de Boeing suman más de 120 mil millones de dólares a la fecha:
  • En enero de 2020, la compañía estimó una pérdida de $18.4 mil millones para 2019.
  • En marzo de 2020, Boeing buscó un rescate de $60 mil millones, lo que provocó una fuerte caída en el precio de sus acciones. Finalmente, Boeing recibió $17 mil millones en fondos del estímulo por el coronavirus.
  • A la fecha de la recertificación por la FAA en noviembre de 2020, las órdenes netas de Boeing para el 737 MAX habían disminuido en más de 1,000 aviones, con 448 órdenes canceladas y 782 órdenes eliminadas del respaldo porque ya no eran lo suficientemente seguras para confiar en ellas.
  • Los costos directos totales estimados de las puestas en tierra del MAX fueron de US$20 mil millones y los costos indirectos superaron los US$60 mil millones.
  • El 7 de enero de 2021, Boeing acordó pagar más de $2.5 mil millones después de ser acusado de fraude.
  • Después de su intención de suspender la producción en diciembre de 2019, Boeing estimó un costo adicional de $6.3 mil millones para entregar el programa 737 MAX.

Para construir buenas Experiencias, hay que tener experiencia.

Para ayudar a nuestros clientes a tomar mejores decisiones, en Kambrica desarrollamos Experience Decision Making: un sistema consistente y aplicado en proyectos reales que permite identificar y corregir a tiempo los patrones que llevan al fracaso.

La fórmula para el éxito puede ser esquiva, pero una condición es innegable: no cometer errores que podrían haberse previsto con la experiencia, ni tan caros que podrían haberse mitigado con procesos racionales de toma de decisiones.

La entrada Nuestra regla #1 de consultoría estratégica: “las cosas se hacen bien, o se hacen de vuelta”. se publicó primero en Kambrica.

En un primer nivel, podemos entender la toma de decisiones como una torre compuesta por cuatro pisos:

Una decisión propiamente dicha, alimenta una acción. Si nuestra “decisión” no se traduce en una acción, entonces sería más apropiado considerarla una expresión de deseos.

A su vez, la decisión se alimenta de información. Y esa información se sostiene, por su parte, en preferencias.

 
 
Desde luego, la toma de decisiones está compuesta por muchos más elementos.

Veamos en detalle qué hay en cada piso:

Acción

Sin compromiso con la acción, no hay decisión.

En la industria de las experiencias, es normal que haya varios decisores. Y estos decisores suelen comprometer la capacidad de ejecución de otros.

Es el caso cuando un Project Manager tiene con un miembro del equipo, un diálogo como éste:

– ¿Cuánto te llevaría desarrollar esta funcionalidad?
– Una semana.
– Tenemos que tenerlo listo para mañana.

En este ejemplo, el PM ya comprometió una capacidad ajena, sin información previa. El resultado de comprimir cinco días de trabajo en uno solo, será que sólo estará terminado el 20% más evidente en una primera inspección superficial.

El 80% restante es lo que se llama deuda técnica: como el software tiende a aumentar su complejidad a medida que se lo construye, todo lo que se deja para un futuro, puede ser mucho más costoso de resolver mañana. Una vez que algo se ha puesto en producción (esto es, el software está publicado y hay usuarios operándolo), corregirlo resulta entre 29 y 1500 veces más caro que al inicio del proyecto. El interés de la deuda técnica, asumida irresponsablemente, suele dejar proyectos en bancarrota.

Decisión

En este piso de la toma de decisiones, tenemos el marco y el proceso.

El marco define la forma de ver la decisión, o en otras palabras, qué se está decidiendo: no es lo mismo decidir sobre cómo construir algo, que evaluar la posibilidad de tercerizarlo.

Proceso refiere al método empleado para tomar la decisión. Por ejemplo, un decisor puede evaluar si cada idea que se propone en una reunión, le parece o no le parece, y desarrollar la primera que encuentre satisfactoria. Otro proceso posible sería analizar el problema a resolver, descomponerlo en variables, y comparar racionalmente varias propuestas según su posible impacto.

Información

XDM divide este piso en cuatro departamentos: causas, orientación, alternativas y consecuencias.

Causas: ¿cómo llegamos hasta aquí?

La experiencia que tienen los usuarios puede ser producto de causas sumamente complejas. La comprensión de las mismas resulta indispensable para una decisión acertada. Algo tan simple como un “inocente” campo de texto provocando que los usuarios abandonen un proceso de registración, puede deberse a decisiones técnicas o de marketing cuya revisión implique redefinir el marco, las conversaciones a mantener y el alcance de la decisión.

Orientación: ¿dónde estamos?

Entender la situación actual requiere poner a prueba nuestros preconceptos, desarmarlos y construir nuevos ante la evidencia. Resulta de vital importancia tanto para un piloto de la Fuerza Aérea, como para quienes toman decisiones en un proyecto.

Sólo desafiando nuestras certezas, podemos reconocer la experiencia que están teniendo nuestros usuarios, y cómo la podemos mejorar.

Alternativas: ¿qué podemos hacer?

Sin dos o más alternativas entre las cuales elegir, no puede hablarse de una decisión. Lo habitual, sin embargo, no es comparar todas las alternativas razonables antes de tomar una decisión. Es muy común detener el proceso con la primera que “nos parece”. Identificar cuando ello ocurre (que es mucho más frecuente que lo que creemos), nos abre la puerta a mejores decisiones.

Consecuencias: ¿qué puede ocurrir?

Para poder evaluar las alternativas, es necesario anticiparse a las consecuencias de cada una de ellas.

Experiencia e imaginación son herramientas usuales. Pero en la industria de las experiencias, no resultan suficientes. Quienes proyectan y construyen un producto, servicio o sistema, ya conocen demasiado como para poder anticipar acertadamente la experiencia que tendrán los usuarios. Por ejemplo, es normal que a todos los involucrados en el proyecto les parezca obvio todo lo que el usuario debería saber y hacer para operar una funcionalidad… porque fueron ellos quienes lo decidieron así.

La experiencia sólo puede ser evaluada observando a usuarios interactuando con el producto, servicio o sistema. Para conocer las posibles consecuencias de las alternativas consideradas, podemos realizar pruebas con muestras reducidas. Por ejemplo, observando tan sólo cinco usuarios operando una interfaz, la probabilidad de identificar problemas de usabilidad graves es del 97%.

Parece sorprendente que una muestra tan reducida pueda resultar válida, cuando lo que usualmente tenemos como referencia son las muestras demográficas. En una muestra demográfica, se trata de conocer atributos del conjunto. Por ejemplo, si queremos conocer cuántos tipos de caño existen en el mundo, sabemos que visitar una sola ferretería no será suficiente. Visitar todas las ferreterías del mundo sería lo ideal, pero resulta inviable. Quizás habría que visitar una de cada ciudad importante, o al menos una de cada país. Es una cantidad apreciable.

Una prueba de usabilidad no es una muestra demográfica: es un estudio para identificar problemas. Si sospechamos que en nuestra casa hay un caño tapado, podemos pasar cinta hasta encontrar una obstrucción. No necesitamos hacerlo cientos de veces.

Preferencias

XDM divide este piso en tres departamentos: valores, cargas y objetivos.

Valores: ¿qué debemos proteger?

Aquí identificamos, en primer lugar, aspectos éticos y de identidad. Muchas decisiones que resultan en impactos negativos en la experiencia de los usuarios, son producto de faltas de definición en este punto. Cuando a los involucrados en el proyecto se les pide mejorar métricas de negocio como conversiones o facturación, sin considerar ningún valor como limitante, no debe sorprender si ello resulta en estrategias que castigan la reputación de la marca: desde confundir a los usuarios, hasta pretender cobrarles por productos y servicios que nunca solicitaron.

Cargas: ¿qué podemos dejar atrás?

Un avance puede requerir dejar atrás algo que resultó costoso de construir, pero que ya no resulta necesario: quien construye una balsa improvisada para cruzar una gran extensión de agua no obraría sabiamente si, una vez llegado a la otra orilla, decidiera cargarla durante el resto de su camino.

En las organizaciones, los costos hundidos resultan muchas veces menos evidentes o difíciles de dejar atrás, pero no menos problemáticos.

Objetivos: ¿qué queremos ganar?

Aquello de valor que se espera obtener como objetivo del proyecto. La falta de declaraciones formales al respecto vuelve muy difícil que los resultados del proyecto coincidan con lo que se pretendía. Más aún cuando a lo largo de un proyecto, intervienen actores de diferentes disciplinas, formaciones y preferencias.

Mejores procesos de toma de decisiones en la industria de las experiencias, surgen de responder a estas tres preguntas:
— ¿Qué problema queremos resolverle… ?
— ¿…a quién?
— ¿cómo sabremos si lo logramos?

Conociendo los fundamentos de Experience Decision Making

Tomar decisiones, al igual que correr o respirar, es algo que todos somos capaces de hacer.

Pero de la misma manera en que buzos y deportistas profesionales estudian, entrenan y mejoran las funciones sobre las que se basa su actividad, quienes gestionamos, proyectamos y construimos experiencias, debemos entrenar nuestra capacidad de tomar mejores decisiones.

XDM es un sistema de modelos y métodos para lograr mejores procesos de toma de decisiones en la industria de las experiencias. Nuestra primer edición, “Experience Decision Making en 30 minutos”, presenta los modelos y conceptos fundamentales.

Los invitamos a obtener el eBook y empezar a desenredar las conversaciones de sus proyectos.

La entrada Anatomía de la toma de decisiones en la industria de las experiencias se publicó primero en Kambrica.

La más notable es reconocer que no tenemos acceso directo a la realidad. Ello tiene implicaciones sumamente profundas, entre otras cosas, a la hora de gestionar proyectos.

Cuando “vemos un árbol”, en realidad estamos viendo un recorte y una traducción que nuestra mente hace de la realidad. Estamos viendo lo que entendemos que es ese árbol. Creemos que todos verán lo mismo. Pero personas que hayan estudiado bellas artes, jardinería o biología, “verán” cosas muy distintas.

Una mirada intuitiva dirá que el árbol surge de la tierra. Pero en realidad, la mayor parte de la masa del árbol surge… del aire. Sabemos que la madera del árbol está hecha de celulosa. Y que la celulosa está formada por el carbono que, gracias a la fotosíntesis, el árbol capturó del CO₂ que nosotros, otros animales y la industria exhalamos.

Si es posible llegar a conclusiones erradas con algo en apariencia tan simple y cotidiano, ¿cómo podemos llegar a buenas conclusiones en algo tan complejo como gestionar software y comportamiento?

Gestionando percepciones

Nos formamos una imagen del mundo, que es nuestra y única. Y solemos operar hacia esa imagen como si fuera la realidad, pretendiendo que nuestras acciones nos traigan los resultados que esperamos. Pero los resultados no vienen de la imagen mental hacia la cual proyectamos. Vienen de la realidad, que es algo muy distinto. Y que es indiferente a nuestros esfuerzos por amoldarla a lo que nuestra mente puede manejar.

El estratega John Boyd comparaba a la mente con un sistema sometido a la segunda ley de la termodinámica: todo sistema cerrado tiende a la entropía, a un menor potencial para funcionar y tomar acción, a un mayor nivel de confusión y desorden. Para lograr impacto en la realidad, necesitamos mantener una mente abierta.

Establecer objetivos claros sobre qué resultado queremos (objetivos), cómo sabremos si lo hemos logrado (métricas), y observar, validar y aprender constantemente, resulta fundamental para lograr buenas decisiones y el éxito de todo lo que querramos emprender.

Nuestra percepción es nuestra, particular y única. Siempre dependerá de nuestros modelos mentales, de nuestro conocimiento previo, de nuestras distinciones. Todo es perfectible, y la percepción no es una excepción: no podemos lograr una percepción perfecta. Pero podemos tener la precaución de tratarla como lo que es: información sesgada, incompleta y parcial sobre el mundo en el que queremos intervenir… nunca un sustituto.

Conociendo los fundamentos de Experience Decision Making

Tomar decisiones, al igual que correr o respirar, es algo que todos somos capaces de hacer.

Pero de la misma manera en que buzos y deportistas profesionales estudian, entrenan y mejoran las funciones sobre las que se basa su actividad, quienes gestionamos, proyectamos y construimos experiencias, debemos entrenar nuestra capacidad de tomar mejores decisiones.

XDM es un sistema de modelos y métodos para lograr mejores procesos de toma de decisiones en la industria de las experiencias. Nuestra primer edición, “Experience Decision Making en 30 minutos”, presenta los modelos y conceptos fundamentales.

Los invitamos a obtener el eBook y empezar a desenredar las conversaciones de sus proyectos.

La entrada La ilusión fundamental se publicó primero en Kambrica.

¿Cómo tomamos decisiones?

La teoría de la decisión clásica considera un decisor racional. A lo largo de cuatro décadas, el psicólogo y premio Nobel Daniel Kahneman encontró evidencias que lo llevaron a ampliar esa visión, modelando un sistema 1 (una forma de procesar y decidir rápida e intuitiva), y un sistema 2 (más lento, lógico y deliberado).

Partiendo de esta base, XDM reconoce cuatro niveles decisorios:

Nivel 0 (“Ejecutivo”)

Este nivel representa la menor distancia con la acción, esto es, la intervención en la realidad. La acción que se produce solamente desde el nivel 0, es una respuesta reactiva a un estímulo, sin que medie ningún proceso de decisión.

Muchos de los adjetivos que el Negocio pretende lograr en la percepción del producto final por parte de los usuarios (“intuitivo”, “moderno”, “innovador”, “disruptivo”) surgen de atender a este nivel.

Para XDM, en el nivel 0 está el impulso que lleva a la acción. Toda decisión que lleva a la acción, es sólo posible superando los umbrales que inhiben ese impulso.

Nivel 1 (“Intuitivo”).

Las decisiones en este nivel resultan habituales, automáticas, y de muy poco costo cognitivo, tales como sumar 2 + 2, o recordar un dato de memoria. Se activa ante la necesidad de una respuesta y en ocasiones, reemplaza una pregunta difícil por una más simple que puede responder, disfrazando la respuesta como válida sin ofrecernos ninguna indicación de que ha ocurrido una sustitución.

Este nivel produce certezas: sus juicios resultan intuitivamente satisfactorios, pero no necesariamente válidos. La duda, o complejidad de procesamiento, nos lleva a elevar la decisión a alguno de los niveles superiores.

Nivel 2 (“Analítico”)

Se dan aquí procesamientos racionales, secuenciales, de mayor costo cognitivo, tales como multiplicar 329 x 713, o responder a “¿cuántas letras E se cuentan en este párrafo?”.

Este nivel produce validaciones siguiendo un procesamiento racional. Sin embargo, cuando las mismas no son aceptadas por el nivel 1, sentimos que “la cosa no cierra”. Para que ocurra una decisión comprometida de tipo racional, el nivel intuitivo también debe ser satisfecho.

Nivel 3 (Creativo)

XDM encuentra la necesidad de separar al proceso creativo en su propio nivel, el más relacionado con la imaginación. Si en el nivel 1 se produce una decisión intuitiva entre opciones habituales, y en el 2 una decisión analítica considerando la información disponible, el nivel 3 es lo que activamos para crear nuevas opciones.

La creatividad es un proceso que se apoya en los niveles 1 o 2 para lograr certeza o validación. Y lo más importante: puede ser elaborada por cualquier persona para generar nuevas alternativas dentro de su área de dominio, no sólo por aquellas con “inclinaciones artísticas”.

Una de las conclusiones fundamentales de XDM, es que la distinción entre estos niveles resulta crítica para la industria de las experiencias:

Los productos, servicios y sistemas presentados a los usuarios, no deberían exigir de ellos más que la activación de los sistemas 0 y 1.

Los involucrados en las decisiones del proyecto deberían ejercitar destreza en la aplicación de niveles 2 y 3 (análisis racional y creatividad). Y observar que sus propias aplicaciones del nivel 1 no les jueguen la mala pasada de disfrazar como certezas lo que podrían ser, en realidad, faltas de criterio.

Conociendo los fundamentos de Experience Decision Making

Tomar decisiones, al igual que correr o respirar, es algo que todos somos capaces de hacer.

Pero de la misma manera en que buzos y deportistas profesionales estudian, entrenan y mejoran las funciones sobre las que se basa su actividad, quienes gestionamos, proyectamos y construimos experiencias, debemos entrenar nuestra capacidad de tomar mejores decisiones.

XDM es un sistema de modelos y métodos para lograr mejores procesos de toma de decisiones en la industria de las experiencias. Nuestra primer edición, “Experience Decision Making en 30 minutos”, presenta los modelos y conceptos fundamentales.

Los invitamos a obtener el eBook y empezar a desenredar las conversaciones de sus proyectos.

La entrada XDM: los cuatro niveles decisorios se publicó primero en Kambrica.

En los últimos 25 años, diversas consultoras y organizaciones vienen analizando la industria del software. Según la muestra y metodología empleada, encuentran que más del 70% de los proyectos fracasa.

Hablamos aquí de proyectos de alto perfil, ejecutados por equipos capacitados. Hablamos aquí de una métrica que en los profesionales experimentados preocupa, pero no sorprende.

Estos tristes resultados resultan de medir, solamente, dimensiones de gestión de proyectos de software: si el producto final logra funcionalidad satisfactoria en tiempo y costos.

Necesariamente, de considerar además dimensiones de gestión de la experiencia –esto es, si lo que las personas experimentan en situación de uso, impulsa comportamientos que generen valor para el negocio– la tasa de fracasos será aún mayor. Si la ingeniería de software y diseño de producto tuvieran por separado un 30% de éxito, la probabilidad de éxito combinada sería sólo un 9%.

Este panorama nos trae malas y buenas noticias

Las malas noticias son que lo más probable es que, a pesar de nuestras mejores intenciones, nuestro proyecto fracase.

Todo proyecto se inicia sostenido en un acto de fe: que este rediseño, esta reingeniería, esta nueva tecnología, resolverán los problemas identificados, amplificarán capacidades y abrirán nuevas oportunidades.

La realidad es que todo proyecto genera problemas nuevos – y en el caso de la industria del software, estos problemas son tales que el fracaso de un proyecto resulta la norma, no la excepción.

Las buenas noticias son que, atendiendo a lo que el resto pasa por alto, podemos lograr no sólo reducir riesgos, sino también una ventaja competitiva. Y lo que a todos se nos suele pasar por alto es una función central de nuestro trabajo: nuestros procesos de toma de decisiones.

Todo producto, servicio o sistema es el resultado de decisiones. Para lograr mejores resultados, necesitamos tomar mejores decisiones.

La toma de decisiones en la industria de las experiencias

La toma de decisiones es la función más importante de la gestión. Nunca antes fue tan difícil.

Este desafío ha sido terreno fértil para nuevas metodologías de trabajo, todas ellas prometiendo el éxito que escapa a las demás. Aunque útiles, todas comparten la misma limitación: una metodología de trabajo propone una forma de organizar personas y procesos. No reemplaza a las personas, ni a sus procesos de toma de decisiones.

Experience Decision Making (XDM) nace de reconocer esa pieza faltante. Integra y extiende elementos de teoría de la decisión, psicología cognitiva y principios de influencia y liderazgo, en un sistema consistente y aplicado en proyectos reales.

XDM permite encontrar respuestas a:

¿Cómo tomamos decisiones? ¿Estamos aplicando el proceso correcto? ¿Qué tipos de información necesitamos? ¿Qué declaraciones debemos hacer?

¿Cómo podemos administrar la complejidad y la incertidumbre?

¿Qué preguntas tenemos que hacernos para lograr proyectos exitosos?

¿Cómo podemos facilitar mejores procesos de toma de decisiones de nuestros superiores y clientes?

Conociendo los fundamentos de Experience Decision Making

Tomar decisiones, al igual que correr o respirar, es algo que todos somos capaces de hacer.

Pero de la misma manera en que buzos y deportistas profesionales estudian, entrenan y mejoran las funciones sobre las que se basa su actividad, quienes gestionamos, proyectamos y construimos experiencias, debemos entrenar nuestra capacidad de tomar mejores decisiones.

XDM es un sistema de modelos y métodos para lograr mejores procesos de toma de decisiones en la industria de las experiencias. Nuestra primer edición, “Experience Decision Making en 30 minutos”, presenta los modelos y conceptos fundamentales.

Los invitamos a obtener el eBook y empezar a desenredar las conversaciones de sus proyectos.

La entrada Para lograr mejores resultados, necesitamos tomar mejores decisiones se publicó primero en Kambrica.