Hay una conversación que se repite en juntas directivas de toda LATAM, y que un equipo británico de Websmith Studio resumió hace pocos días en una frase incómoda: tu sitio web no es para vos. La idea atraviesa el corazón del diseño UX moderno y choca de frente con la intuición del fundador, del gerente de marketing y del miembro del board que paga la factura. La premisa es simple, pero su aplicación en el mundo real revela una paradoja que en 2026 cuesta millones en conversión perdida: el experto en diseño está en la sala, presenta seis semanas de investigación, y luego alguien dice «No me gusta el azul» y todo se descarta.
Este artículo es una adaptación libre, con datos y contexto para la audiencia hispana, del ensayo original publicado por Websmith Studio. Lo extendemos con investigación de Nielsen Norman Group, casos prácticos de equipos en Centroamérica y un marco de decisión que cualquier desarrollador o product owner puede aplicar la próxima vez que reciba un cambio que viene «desde arriba».
Qué pasó: el ensayo que volvió a poner el dedo en la llaga
El 28 de abril de 2026, Websmith Studio publicó un texto corto firmado por uno de sus desarrolladores. La tesis es directa: el sitio web no es del fundador, ni del marketing manager, ni del board. Es del cliente que evalúa una compra, del lead que busca un teléfono, del visitante que mide tu credibilidad o del miembro que se registra para acceder a contenido cerrado. Y, sin embargo, los decisores tratan al sitio como si fuera un cuadro colgado en la pared o un jardín a contemplar, porque mentalmente lo identifican con su marca, su esfuerzo y su nombre.
El ensayo se viralizó en Hacker News y LinkedIn por una razón concreta: pone palabras a una frustración que casi todos los que trabajan con clientes han sentido. Y aunque no aporta datos cuantitativos, conecta con décadas de research del mundo del CRO (Conversion Rate Optimization) que sí los tiene.
El momento crítico: cuando la opinión del decisor sobrescribe la investigación.
El argumento central: un sitio no es arte, es una herramienta
Websmith lo sintetiza así: un sitio web tiene un único trabajo, lograr que el usuario haga lo que vino a hacer. Todo lo demás es decoración alrededor de ese propósito, y cada decisión ayuda al usuario o se le interpone. La frase suena obvia, pero al aterrizarla aparecen las consecuencias incómodas:
- El hero section que ama el CEO puede ser exactamente el que más rebote genera.- La paleta corporativa que el board defiende puede ser la que peor contraste accesible tiene.- El video autoplay con música que «refleja la energía de la marca» suele ser el primer culpable de bounce.
El principio es viejo —Steve Krug lo formuló en Don't Make Me Think en 2000—, pero veintiséis años después seguimos pidiendo a la gente que piense más de lo necesario, porque a alguien le gustó cómo se veía.
La paradoja del experto: el cirujano y el sitio
El texto original plantea una analogía punzante: un paciente no se inclina sobre la mesa de operaciones para decirle al cirujano dónde cortar. La deferencia es automática porque la apuesta es alta y la experticia, evidente. Sin embargo, en diseño la dinámica es la inversa: cuanto más bajos parecen los stakes, más confiada se vuelve la gente al sobreescribir al experto.
Nadie le dice a su contador qué deducciones reclamar, ni a su electricista qué calibre de cable usar. Pero como todos hemos visto un sitio web, todos nos sentimos calificados para rediseñarlo. La consecuencia, dice Websmith, es que la mayoría de diseñadores aprenden a elegir sus batallas: empujan una o dos veces, luego ceden silenciosamente porque la relación importa más que la colina. El sitio que termina shippeando es, en sus palabras, «esencialmente un mood board para el equipo de liderazgo: hermoso para los que lo aprobaron, silenciosamente inútil para los que se supone que debe servir».
💭 Clave: La autoridad técnica no se transfiere por entusiasmo. Que un stakeholder esté apasionado por una decisión no la vuelve correcta. La investigación de usuario sí.
Datos y cifras: lo que dice la evidencia
El ensayo es cualitativo, pero la industria del CRO lleva décadas midiendo este fenómeno. Algunos puntos clave que cualquier equipo debería conocer antes de su próxima review:
- Solo el 22 % de las empresas está satisfecho con sus tasas de conversión, según data agregada por Invesp y otras consultoras de optimización web. La mayoría sabe que pierde clientes y aún así cambia el sitio basándose en gusto personal.- Cada segundo extra de carga reduce las conversiones aproximadamente un 7 %. Esto es lo que cuesta el video full-width que «se ve impresionante».- El 88 % de los visitantes online no regresa a un sitio después de una mala experiencia, de acuerdo con Nielsen Norman Group. La fricción se paga al instante.- Pruebas A/B bien diseñadas muestran rutinariamente diferencias de 10 % a 40 % en conversión entre versiones que para el ojo no entrenado se ven igual. La intuición del decisor no es predictiva.
El punto es brutalmente simple: las decisiones de diseño UX tienen consecuencias económicas medibles, y son contraintuitivas para quien no se pasa el día observando heatmaps, session replays y embudos. Por eso se contrata a alguien que sí.
Cuando el gusto sobrescribe los datos
Lo que Websmith describe con precisión clínica es un patrón observable en agencias de Buenos Aires, San José, Ciudad de México y Madrid: el diseñador presenta un wireframe basado en testing con cinco usuarios reales (la regla de Jakob Nielsen), el cliente dice que «se siente vacío», y el equipo agrega tres bloques más, dos sliders y un popup de newsletter. La página resultante satisface al cliente y arruina al usuario.
Los costos de esta dinámica son acumulativos. Cada concesión pequeña parece razonable —al fin y al cabo, el cliente paga—, pero el resultado final es un sitio que perdió su norte. La métrica que mejor lo captura es la diferencia entre tasa de conversión por dispositivo antes y después del rediseño: cuando un sitio cae 30 % en mobile tras un refresh «aprobado por el board», la causa raíz casi siempre se rastrea a tres o cuatro decisiones de gusto que ningún test validó.
El antídoto operativo
El antídoto, sostiene el ensayo, es una pregunta sencilla. Antes de pedir un cambio en una review, preguntate: «¿esto ayuda al usuario, o me ayuda a mí?». Si no podés responder honestamente, pedí al diseñador qué dice la investigación. Si tiene una respuesta real —un número, un principio, una pieza de testing—, escuchá. Para eso le estás pagando.
Marco mínimo de decisión: dato, hipótesis, test, resultado.
Cómo se ve el flujo correcto
Para equipos que quieran institucionalizar este principio, conviene formalizar el flujo de feedback. Algo así:
flowchart LR
A["Stakeholder propone cambio"] --> B{"¿Hay data que lo respalde?"}
B -- "Sí" --> C["Aplicar el cambio"]
B -- "No" --> D["Convertir en hipótesis"]
D --> E["Diseñar test A/B"]
E --> F{"¿El test gana?"}
F -- "Sí" --> C
F -- "No" --> G["Descartar y documentar"]
El detalle importante es que nadie pierde la cara. Las opiniones del CEO no se ridiculizan, se convierten en hipótesis. Las del diseñador tampoco se imponen sin evidencia. La política interna se reemplaza por un protocolo, y el sitio empieza a optimizarse para quien debería: el visitante.
Un ejemplo de protocolo simple
Un PR template para revisiones de diseño puede capturar este principio en treinta segundos. En cualquier repo donde haya issues de UX:
# Propuesta de cambio de UX
## Cambio sugerido
[Descripción]
## ¿A quién beneficia?
- [ ] Al usuario que viene a [acción concreta]
- [ ] Al stakeholder interno (gusto / branding)
## Evidencia
- Heatmap / session replay:
- Test A/B previo:
- Investigación citable:
## Si no hay evidencia: hipótesis testeable
[Métrica + dirección esperada del cambio]
⚠️ Ojo: Si el campo «evidencia» queda vacío y el campo «beneficia al stakeholder» tiene tilde, no se trata de un cambio de UX. Es una preferencia personal disfrazada. Tratala como tal.
Impacto y análisis: por qué importa para LATAM
En el ecosistema hispano —especialmente en pymes y startups bootstrap— este patrón se agrava por tres factores. Primero, los presupuestos suelen ser ajustados, lo que aumenta la presión sobre la agencia para complacer al cliente y reduce la disposición a discutir. Segundo, muchos founders tienen background técnico o comercial pero no de producto, y sus referencias visuales son los sitios que ellos mismos usan, no los que sus clientes visitarían. Tercero, el ciclo de feedback con el usuario final es largo: el sitio se publica y los datos llegan meses después, cuando el equipo ya está enfocado en otra cosa.
El resultado es que durante 2025 y 2026 hemos visto en consultorías regionales un patrón claro: los sitios que más convierten en LATAM no son los más bonitos, son los que respetan tres reglas básicas: jerarquía visual clara, una sola acción primaria por pantalla y menos copy del que el founder quiere.
Qué sigue: el rol de la IA en esta conversación
Hay una capa nueva que el ensayo de Websmith no toca pero que en 2026 ya no se puede ignorar: las herramientas de generación de UI con IA (v0, Lovable, Cursor con plugins de diseño) hacen trivial producir variantes de cualquier pantalla. Esto debería favorecer al usuario, porque permite probar cinco hipótesis donde antes solo se podía pagar una. Pero también empeora el problema cuando el stakeholder usa la IA para generar la versión que a él le gusta y la impone sin testear.
El terreno en disputa de los próximos doce meses no es quién diseña —diseñadores y modelos van a coexistir— sino quién decide qué shippea. Y la respuesta correcta sigue siendo la de Websmith: el usuario decide, mediante datos. El diseñador interpreta. El stakeholder acepta o financia más testing. La paradoja del experto se resuelve cuando el experto ya no es una persona sino el conjunto diseñador + research + métricas.
📖 Resumen en Telegram: Ver resumen
Preguntas frecuentes
¿Significa esto que el cliente nunca tiene razón en diseño UX?
No. Significa que su opinión es una hipótesis, no una conclusión. Cuando coincide con la investigación o con un test, perfecto. Cuando contradice la evidencia, hay que discutirlo con datos antes de implementarlo.
¿Cómo respondo cuando un CEO insiste en un cambio sin evidencia?
Convertí el cambio en una hipótesis testeable. Proponé un test A/B con la versión actual y la versión propuesta, definí la métrica objetivo y un período de medición. Si el cambio gana, se queda. Si no, se documenta y se descarta. Esto reemplaza la política por un protocolo.
¿Cuántos usuarios necesito testear para validar una decisión de UX?
Para tests cualitativos de usabilidad, Nielsen Norman Group sugiere que cinco usuarios encuentran el 85 % de los problemas de usabilidad. Para tests A/B cuantitativos, el tamaño depende del tráfico y del efecto esperado, pero típicamente se necesitan miles de sesiones por variante para detectar diferencias del 5 % al 10 %.
¿Qué herramientas concretas puedo usar para defender decisiones de UX con datos?
Heatmaps y session replays con Hotjar, Microsoft Clarity (gratis) o FullStory; tests A/B con Optimizely, VWO o Google Optimize successor; analítica con Plausible, Fathom o GA4; testing remoto de usabilidad con UserTesting o Maze.
¿Cómo aplico esto en una pyme sin presupuesto para investigación?
Microsoft Clarity es gratuito y cubre heatmaps + session replays. Sumá una encuesta corta on-exit con Tally o Typeform. Con eso ya tenés base de evidencia. La excusa de «no hay presupuesto» rara vez es real cuando hay alternativas open source o freemium.
¿Esta lógica aplica también a apps móviles y dashboards internos?
Sí, con matices. En apps móviles las apuestas suelen ser más altas (un mal flujo de onboarding mata retención). En dashboards internos hay que balancear la opinión del usuario power (que sí tiene autoridad técnica sobre cómo trabaja) con la del usuario nuevo (que sufre la curva de aprendizaje). Pero el principio se mantiene: investigá antes de decidir.
Referencias
- Websmith Studio — Your website is not for you — Ensayo original que motivó este análisis.- Nielsen Norman Group — Why You Only Need to Test with 5 Users — Investigación clásica de Jakob Nielsen sobre tamaño de muestra en testing de usabilidad.- Wikipedia — User experience — Marco general y referencias bibliográficas sobre la disciplina del UX.- Nielsen Norman Group — 10 Usability Heuristics — Las diez heurísticas de Nielsen, base teórica de gran parte del diseño UX moderno.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Top comments (0)