# Los datos dicen dónde abandona la gente. Nunca dicen por qué.

Cómo leímos un año de noticias de financiación y 100 webs árabes, qué probaron los números, qué no y cómo usar el análisis de datos como método de diseño.

https://laithjunaidy.com/es/writing/data-says-where-not-why
Por Laith Aljunaidy. Publicado: 2026-11-01.

---

![Gráfico de 179 startups MENA con financiación: el 44 por ciento no tiene web en árabe y el 48 por ciento de las webs árabes tiene al menos un fallo que oculta el árabe a Google o a los rastreadores de IA](https://laithjunaidy.com/writing/taken-apart-2/chart.png)

*El gráfico de [Desmontado, número dos](https://laithjunaidy.com/es/writing/taken-apart-arabic-100). Las bases están sobre las barras: 179 startups, 88 páginas, 94 para los rastreadores. Esa línea de letra pequeña es casi todo este artículo.*

El 25 de septiembre de 2026 publiqué [Desmontado, número dos](https://laithjunaidy.com/es/writing/taken-apart-arabic-100). De 179 startups de la región con financiación y una web que pudimos revisar, 79 no tenían ninguna versión en árabe. Es el 44 por ciento.

Todos los fundadores de la región dicen lo mismo del árabe: por supuesto que lo soportamos. Quise saber qué significa eso en la página, así que dejé de preguntar y conté. Una lista pública, leída en orden, todas las empresas revisadas, sin elegir. El commit que publicó el resultado lleva a Claude como coautor. El escáner, la muestra y las notas sobre cómo se obtuvo la muestra se publicaron junto al ensayo, abiertos para que cualquiera los repita.

Ese número es ahora el ejemplo de Análisis de datos en mi guía del proceso de diseño. Léase una segunda vez y el límite está en el propio resultado. Los datos dicen que 53 de 67 startups de EAU con financiación se presentan solo en inglés. No dicen una palabra sobre el motivo. Ni si lo decidieron los fundadores, se les olvidó, no podían pagarlo o nunca pensaron que sus compradores leyeran árabe. Cada razón que pudiera darte sería una conjetura disfrazada de hallazgo.

Esa brecha es todo el método. El análisis de datos dice dónde abandona la gente. Nunca dice por qué. Así se construyó y se leyó realmente el escaneo, y esto es lo que enseña sobre el uso de datos en el diseño.

## Ideas clave

- El análisis de datos es leer lo que ya existe antes de crear algo nuevo: analítica, ventas, tickets de soporte, registros de búsqueda, reseñas de aplicaciones, datos públicos, investigaciones antiguas. Es la investigación más barata que hay, por eso va primero.
- Responde a dónde y cuántos. No puede responder por qué. El porqué sale de entrevistas y de observar a la gente, y los datos dicen a quién preguntar y sobre qué.
- Decide la fuente y el orden antes de mirar. Leímos las noticias de financiación de Wamda de la más reciente a la más antigua y revisamos por turno cada empresa que cumplía los criterios. No se eligió nada por tener problemas.
- Cada número lleva su base. Las mismas 79 empresas son el 44 por ciento de 179 y el 43 por ciento de 184. Ambas cifras son ciertas. Solo una es honesta sin su denominador.
- Medido, nunca supuesto. Una web que no se pudo leer quedó fuera de esa comprobación y se dijo, no se rellenó.
- La IA abarata el análisis. Ahora la habilidad es comprobarlo: abrir las filas originales, repetir el recuento y descartar cualquier porcentaje sin un archivo detrás.

## ¿Qué es el análisis de datos en la investigación UX?

Es leer lo que ya existe antes de crear algo nuevo. La entrada de mi [guía del proceso de diseño](https://laithjunaidy.com/writing/design-process-checklist#análisis-de-datos) está en Empatizar y da una razón para hacerlo primero: cuesta lo mínimo. Tickets de soporte, datos de ventas, registros de búsqueda, reseñas de aplicaciones, investigaciones antiguas. Sales sabiendo dónde mirar y con las primeras preguntas para tus entrevistas.

Nielsen Norman Group llama a la familia más amplia [investigación secundaria](https://www.nngroup.com/articles/secondary-research-in-ux/), también conocida como investigación documental, y dice que debería ser un primer paso habitual en cualquier práctica de investigación rigurosa. Su planteamiento es práctico: si alguien ya hizo un estudio, úsalo, y no pagues por redescubrir lo que tu propia organización aprendió hace dos años.

![La sección Análisis de datos de la guía del proceso de diseño en laithjunaidy.com: leer lo que ya existe y la frase de que los datos dicen dónde abandona la gente y nunca dicen por qué](https://laithjunaidy.com/writing/data-analysis/hub-data-analysis.jpg)

*La entrada de [Análisis de datos](https://laithjunaidy.com/writing/design-process-checklist#análisis-de-datos) en la guía del proceso de diseño. Allí son dos párrafos. Esta es la versión larga.*

Hay dos tipos de datos que se pueden leer así.

Los datos propios son lo que tu producto ya registra: sesiones, embudos, pedidos, la bandeja de soporte, el cuadro de búsqueda que nadie mira. Aquí aparece el abandono: un paso al que llegan muchos y del que pocos salen en la dirección correcta.

Los datos públicos son lo que el mundo ya publicó: noticias de financiación, webs de la competencia, reseñas de tiendas de aplicaciones, estadísticas oficiales. Es lo que usamos en Desmontado. Nadie nos dio acceso a nada. Cada página que leímos podía abrirla cualquier visitante.

Los dos tipos tienen la misma fortaleza y el mismo límite. Registran lo que pasó. No registran lo que alguien quiso decir.

## ¿Por qué contar en lugar de preguntar?

Porque mi pregunta era de «cuántos», y las personas responden mal a esas preguntas sobre sí mismas.

Si hubiera entrevistado a diez fundadores sobre sus webs en árabe, habría oído diez versiones de «soportamos el árabe». Es lo que se dice en voz alta, y no es mentira. Para un fundador, una página de inicio traducida detrás de un selector de idioma cuenta como soporte. Lo que importaba era cómo se ve ese soporte para quien llega a la página, para Google y para los rastreadores que hay detrás de ChatGPT, Claude y Perplexity. Eso no es una opinión que alguien tenga. Es un hecho que está en un servidor, y se puede ir a leer.

Esa es la primera regla del uso de datos en el diseño. Úsalos para las preguntas que pueden responder: cuántos, con qué frecuencia, dónde, desde cuándo. Usa entrevistas para las que no pueden: por qué, qué intentabas hacer, qué esperabas que pasara.

![La sección «Cuatro de cada diez omiten el árabe por completo» del ensayo: 79 de las 179 empresas con una web revisable no tienen versión en árabe, 8 de 66 en Arabia Saudí, 53 de 67 en EAU](https://laithjunaidy.com/writing/data-analysis/taken-apart-four-in-ten.jpg)

*El resultado tal como se publicó en [Desmontado, número dos](https://laithjunaidy.com/es/writing/taken-apart-arabic-100). La expresión del ensayo para el reparto por países es «la historia real». Es también exactamente donde los datos dejan de hablar.*

## ¿Cómo elegimos qué leer?

Esta es la parte que casi todo análisis de datos se salta, y decide si el resultado significa algo.

La forma fácil de escribir este ensayo habría sido abrir veinte webs de startups que ya conocía, encontrar las rotas y contarlas. Eso produce una cifra llamativa y no prueba nada. Encuentras lo que fuiste a buscar.

Por eso el orden se fijó antes de abrir ninguna web. Usamos una sola fuente pública, las [noticias de financiación](https://www.wamda.com/news) de Wamda, y la leímos en el orden de publicación, de la más reciente a la más antigua: 473 artículos, del 23 de septiembre de 2026 hasta el 30 de septiembre de 2025. No se mezcló ninguna otra lista, así que todas las empresas salieron del mismo flujo ordenado.

Un titular se consideraba válido solo si informaba de una empresa con nombre que levantaba dinero: una ronda anunciada, una inversión estratégica o una línea de crédito. Quedaban fuera fondos, aceleradoras, adquisiciones, salidas, alianzas, lanzamientos y menciones repetidas de la misma empresa. El país tenía que ser uno de nueve: Arabia Saudí, EAU, Egipto, Jordania, Kuwait, Catar, Baréin, Omán o Marruecos. El sector tenía que ser uno de estos: fintech, comercio electrónico, reparto, proptech, salud, edtech, movilidad, SaaS o RR. HH. Quedaban fuera los bancos con licencia, las entidades públicas y las empresas que se sabía que habían cerrado.

Pasaron 184 empresas. Las revisamos por orden, con webs buenas y malas, hasta reunir 100 con versión en árabe. La centésima fue DOO, en el artículo de Wamda del 30 de septiembre de 2025. La regla completa está escrita en [cómo se obtuvo la muestra](https://laithjunaidy.com/writing/taken-apart-2/SAMPLE.md), publicada con el ensayo.

Tres cosas de ese párrafo hacen el trabajo de verdad.

**La fuente es externa a ti.** No elegimos las empresas. Las eligió Wamda al informar de su financiación. Eso saca la selección de mis manos, que es donde debe estar cuando ya tengo una opinión sobre la respuesta.

**La regla de parada está fijada de antemano.** «Hasta tener 100 con versión en árabe» es una regla que se puede comprobar. «Hasta tener suficientes» no.

**La definición está por escrito.** Versión en árabe significa que un visitante puede llegar a texto de página en árabe desde la propia web de la empresa: un selector de idioma, un enlace hreflang en árabe, una página de inicio en árabe por defecto o una redirección según el idioma del navegador. El árabe que solo existe dentro de la aplicación móvil no contaba. Tampoco una URL en árabe a la que no enlaza nada, ni un selector que deja la página en inglés. Son decisiones de criterio, y están en las notas, donde se pueden discutir.

La muestra en sí es un archivo sencillo, [sample.csv](https://laithjunaidy.com/writing/taken-apart-2/sample.csv): empresa, país, sector, página de inicio, la URL en árabe y el artículo de Wamda que puso a la empresa en la lista. 100 filas. Cada fila puede rastrearse hasta el artículo que la justificó.

## ¿Qué comprobó realmente el escáner?

El escáner es un solo archivo, [scan.mjs](https://laithjunaidy.com/writing/taken-apart-2/scan.mjs). El comentario del principio enumera cada comprobación que hace y declara la regla sobre la que se sostiene todo el estudio: cada comprobación es medida, nunca supuesta.

![El comentario de cabecera de scan.mjs: cada comprobación es medida, nunca supuesta, y una web que no se puede descargar queda fuera del denominador de esa comprobación, seguido de las ocho comprobaciones que ejecuta](https://laithjunaidy.com/writing/data-analysis/scan-checks.jpg)

*El inicio del [escáner](https://laithjunaidy.com/writing/taken-apart-2/scan.mjs) publicado. Ocho comprobaciones, cada una una pregunta que un visitante o un rastreador real haría a la página.*

Cada comprobación representa a una persona o a una máquina que lee la página.

| Comprobación | Qué lee | A quién representa |
| :- | :- | :- |
| raw_ar_chars | Letras árabes en el HTML del servidor, sin scripts | Rastreadores de IA que no ejecutan JavaScript |
| title_ar | Si el título de la página contiene árabe | Una persona que busca en árabe y lee la línea azul de Google |
| lang, dir | El idioma y la dirección definidos en la página | Navegadores, lectores de pantalla, buscadores |
| canonical | Si la página se nombra a sí misma o a otra como original | Google al decidir qué página mostrar |
| hreflang | Cuántas alternativas de idioma declara la página | Google al emparejar las páginas en árabe y en inglés |
| bots | El estado HTTP para GPTBot, OAI-SearchBot, ClaudeBot y PerplexityBot frente a un navegador normal | ChatGPT, Claude y Perplexity |
| robots | Si robots.txt prohíbe a cada uno de esos bots | Las reglas que la propia web declara |
| overflow | Cuánto se desplaza la página hacia un lado en un iPhone 13 tras cargar | Una persona con el móvil |

Cada descarga pide el árabe primero, sigue las redirecciones y se rinde a los 25 segundos. La comprobación móvil abre la página en un viewport de iPhone 13, espera a que cargue, espera tres segundos más y mide cuánto más ancha es la página que la pantalla.

La decisión de diseño que más me importa es la que suena más pequeña. Una web que no se pudo descargar se registra como inalcanzable y queda fuera del denominador de esa comprobación. No se cuenta como rota ni como correcta. Se cuenta como desconocida, y los desconocidos se publican.

Esa regla es la razón de que el ensayo pueda decir «de las 88 páginas en árabe que pudimos leer enteras» en lugar de «de 100». Cinco webs no dieron al escáner ninguna página ese día, cuatro porque lo rechazaron y una porque no cargó, así que quedan fuera de las comprobaciones de página. Todas habían cargado en árabe cuando se revisó la muestra, y por eso siguieron dentro. Otras siete quedan fuera de las comprobaciones de texto: las seis que nombra el ensayo, cuya dirección no cambia con el idioma, y una que dibuja su árabe en un canvas, de modo que no hay texto que leer. Las bases se reducen, y cada cifra dice qué base usa: 179 empresas, 88 páginas, 94 páginas para las comprobaciones de rastreadores y otras 94 distintas para la del móvil.

## ¿Por qué cada número lleva su base?

Porque la base es el número. Un porcentaje sin ella es un estado de ánimo.

![La sección Método y datos del ensayo: el escáner y la muestra son abiertos, las páginas se descargaron el 25 de septiembre de 2026 como navegador y como cuatro rastreadores de IA, y cada cifra indica su propia base](https://laithjunaidy.com/writing/data-analysis/taken-apart-method.jpg)

*La última sección del [ensayo](https://laithjunaidy.com/es/writing/taken-apart-arabic-100#método-y-datos). Cada cifra indica su propia base.*

Un caso real del estudio. El ensayo dice que 79 de 179 empresas no tienen versión en árabe, el 44 por ciento. Las notas de la muestra, publicadas el mismo día, dicen que 79 de las 184 tenían una web operativa sin versión en árabe, el 43 por ciento. Las mismas 79 empresas. Dos porcentajes distintos.

Los dos son correctos. 184 es el total de empresas que pasaron los filtros. Cuatro de ellas no tenían ninguna web localizable y una quedó fuera porque su web nos bloqueaba desde nuestra ubicación, así que tampoco se pudo revisar. Si quitas esas cinco, quedan las 179 que pudimos juzgar. Dividir entre 184 mantiene en la base a cinco empresas que nunca juzgamos. Dividir entre 179 dice solo lo que vimos.

Lo mismo ocurre con EAU. El ensayo dice 53 de 67. Las notas de la muestra dicen 53 de 69. La diferencia son dos empresas de EAU sin web localizable. Otra vez, los mismos 53, base distinta, ambas ciertas, y solo una es una afirmación sobre webs.

Nadie notaría ninguna de las dos diferencias si hubiéramos impreso «44%» a secas. Ese es justo el problema. Un porcentaje desnudo oculta todas las decisiones que hay detrás. La base devuelve la decisión a la página, donde el lector puede discutirla.

Así que la regla que conviene llevarse, para informes de investigación, paneles y presentaciones a inversores: escribe el recuento, luego la base, luego el porcentaje. «79 de 179, el 44 por ciento». Si no puedes rellenar los dos primeros, no tienes el tercero.

## ¿Coincide la muestra con el resultado?

Un buen hábito antes de publicar: comprobar el archivo publicado contra la afirmación publicada, como lo haría un desconocido.

El ensayo dice que 8 de 66 startups saudíes con financiación no tienen web en árabe, así que 58 sí. Cuenta las filas saudíes de sample.csv y salen 58. Dice que 53 de 67 startups de EAU no tienen web en árabe, así que 14 sí. Las filas de EAU en la muestra: 14. El archivo y el ensayo coinciden, y cualquiera puede comprobarlo en un minuto.

La muestra también deja ver la forma de lo contado. 28 de las 100 empresas son fintech, 22 son SaaS y 14 son comercio electrónico. 58 son saudíes. Cualquier afirmación sobre «las startups de MENA» a partir de estos datos pesa, en realidad, hacia la fintech y el software saudíes. La mezcla de sectores es la de quienes levantaron dinero y salieron en la prensa ese año. El peso saudí es la propia regla de la muestra en acción: la lista contenía casi tantas empresas de EAU como saudíes, 67 y 66, pero solo llega a la muestra una empresa con web en árabe. No es un fallo del método. Es un hecho sobre quién está en el archivo, y se dice en voz alta en lugar de dejar que el lector suponga que la muestra se parece a toda la región.

Otro detalle pequeño del archivo: en 32 de las 100 filas, la página en árabe y la página de inicio tienen la misma dirección. A veces es una página de inicio en árabe por defecto. A veces es un cambio de idioma que cambia las palabras y mantiene la URL, el caso que el recuento tuvo que dejar fuera de las comprobaciones de texto. El archivo no puede decirte cuál es cuál. Hay que abrir la web.

## ¿Qué encontraron realmente los datos?

De las 88 páginas en árabe que pudimos leer enteras, 42 tienen al menos un fallo que mantiene el árabe lejos de la búsqueda o de las respuestas de IA. Es el 48 por ciento.

- 28 no tienen hreflang, el 32 por ciento. Google no puede saber que las páginas en árabe y en inglés son el mismo contenido en dos idiomas. Google explica cómo hreflang empareja versiones de idioma en su documentación sobre [versiones localizadas](https://developers.google.com/search/docs/specialty/international/localized-versions).
- 23 mantienen un título en inglés en la página en árabe, el 26 por ciento.
- 9 no tienen árabe en la página hasta que se ejecuta JavaScript, el 10 por ciento. Para un rastreador que lee la página en bruto, esa web en árabe está vacía.
- 8 de las 94 páginas de las comprobaciones de rastreadores rechazan de plano a un rastreador de IA con un error, el 9 por ciento. Solo una de las ocho lo declara en robots.txt.
- 3 indican a Google que la página en inglés es la original, el 3 por ciento.

El diseño móvil, lo que la gente suele culpar, estaba bastante bien. 4 de 94 páginas se desplazan hacia un lado en un iPhone.

Esa última línea es la razón para contar. El recuento colocó los fallos en otro sitio, en las partes que nadie ve: una etiqueta de título, un elemento de enlace, una regla de cortafuegos. El análisis de datos rinde al máximo cuando demuestra que te equivocabas sobre dónde mirar.

## ¿Dónde se detienen los datos?

Mira las ocho webs que rechazan a un rastreador de IA. El dato es exacto: el rastreador pide la página, el servidor responde con un error y un navegador normal recibe la página. Y solo una de las ocho lo declara en robots.txt.

Lo que no puede decir es si alguien lo eligió. El ensayo afirma que en las otras siete es una regla de cortafuegos, no una decisión de nadie. Es la lectura más razonable de la evidencia: una decisión que se quiere tomar va en robots.txt, y un valor por defecto que nunca se miró está en el cortafuegos. Pero sigue siendo una lectura. El código de estado es el dato. La intención que hay detrás es una inferencia, y la única forma de convertirla en un hecho es preguntar a la empresa.

Con la cifra de EAU pasa lo mismo. 53 de 67 startups de EAU con financiación no tienen web en árabe. Se pueden imaginar las razones. Sus compradores son extranjeros residentes. Sus inversores leen inglés. El árabe está en la hoja de ruta. Nunca preguntamos. Cada una lleva a una decisión de diseño distinta, y los datos las tratan a todas como la misma fila.

La [comparación de NN/g entre investigación cualitativa y cuantitativa](https://www.nngroup.com/articles/quant-vs-qual/) lo resume en una línea: los datos cuantitativos pueden decir que un diseño quizá no funcione, pero no señalan qué problemas encontraron los usuarios ni qué cambiar. Es exactamente el límite del ensayo. Termina con una oferta: «si tu web en árabe está en los números y quieres saber cuáles, pregúntame», porque el paso siguiente a un recuento es siempre una conversación.

## ¿Cómo se lee el abandono en tu propio producto?

El escaneo de Desmontado usa datos públicos. La mayor parte del análisis de datos en diseño trata de los números del propio producto, y la forma es la misma.

![Dos pantallas de vendedor de Bysooq: un panel con ventas totales, sesiones, conversión y pedidos, y una cuadrícula de productos con existencias y precios](https://laithjunaidy.com/writing/design-process/bysooq-hifi.jpg)

*Un panel de vendedor diseñado para [Bysooq](https://laithjunaidy.com/es/work/bysooq), comercio electrónico para Irak y Jordania. Bajo la tasa de conversión está el embudo: añadido al carrito, llegada al pago, sesiones convertidas. Las cifras son contenido de diseño, no números reales de una tienda. Lo que importa es la estructura.*

Un embudo como ese es la forma más habitual de los datos de abandono. Cada paso indica cuántas personas lo alcanzaron. El paso donde el recuento cae con más fuerza es donde se mira primero.

Así lo hago yo.

1. Escribe la pregunta antes de abrir el panel. «¿Dónde se van los clientes de los vendedores entre el carrito y el pago?» es una pregunta. «Echemos un vistazo a la analítica» es una forma de perder una tarde.
2. Fija la ventana y la fuente. Un único intervalo de fechas, una única fuente de datos, elegidos antes de mirar. Cambiar el intervalo hasta que el gráfico parezca interesante es la versión en panel de elegir veinte webs que ya conocías.
3. Escribe el recuento y la base de cada paso. No «el pago va mal». «De las personas que llegaron al pago este mes, tantas pagaron».
4. Busca la mayor caída, no todas. Todo embudo pierde gente en cada paso. El que hay que estudiar es el paso donde se va más gente.
5. Lee las filas originales que hay detrás. Abre sesiones, pedidos y tickets reales de ese paso. Las medias esconden a quien lo intentó tres veces.
6. Detente y escribe las preguntas para las entrevistas. El resultado del análisis de datos no es una solución. Es una lista corta de personas con las que hablar y de qué preguntarles.

El sexto paso es el que la gente se salta. El embudo dice que mucha gente se va en el pago. No dice si les sorprendió el coste de envío, faltaba un método de pago, la página estaba en el idioma equivocado o solo comparaban precios. Cada una de esas razones es una pantalla distinta. Si eliges una sin preguntar, diseñas para tu propia conjetura, con un gráfico que hace que parezca investigación.

## ¿Qué hacer con el porqué?

Ir a buscarlo a las personas.

En [Wfrah](https://laithjunaidy.com/es/writing/designing-wfrah), la aplicación que diseñamos para criadores de ovejas y cabras del Golfo, los ganaderos daban la misma respuesta en voz alta: el pienso es caro y los compradores pagan poco. Si solo contaras lo que la gente dice, ese sería tu hallazgo. Las entrevistas mostraron lo que había debajo. Muchos ganaderos no sabían calcular con las fórmulas la nutrición diaria del rebaño, y culpar al mercado facilitaba pasar por alto la nutrición y la gestión. Por eso la aplicación incluye una calculadora nutricional que hace las cuentas por ellos.

![Pantallas de la aplicación Wfrah en árabe: evaluación del rebaño, selección de un animal y panel de control](https://laithjunaidy.com/writing/wfrah/cover.jpg)

*[Wfrah](https://laithjunaidy.com/es/work/wfrah). La calculadora nutricional salió de las entrevistas, no de ningún número.*

El orden de trabajo es sencillo. El análisis de datos encuentra el dónde y lo dimensiona. Las entrevistas encuentran el porqué. Un guion de [entrevista con usuarios](https://laithjunaidy.com/store/user-interview) construido con los datos pregunta por la última vez que la persona se topó con ese paso exacto. Un [mapa de afinidad](https://laithjunaidy.com/store/affinity-map) ordena lo que dijeron, con una etiqueta de participante en cada nota para rastrear cada tema hasta una persona. Después, un [enunciado del problema](https://laithjunaidy.com/store/problem-statement) dice qué se arregla y para quién, con el recuento de tus datos como evidencia del tamaño.

## ¿Cómo usar la IA en el análisis de datos sin engañarte?

La IA abarató mucho este método. Un modelo lee mil reseñas de aplicaciones en un minuto, ordena tickets de soporte por temas, escribe el scraper y redacta el informe. Las herramientas avanzan rápido. Un [Show HN de octubre de 2026 sobre Graphene](https://news.ycombinator.com/item?id=49927295), un conjunto de herramientas de análisis de datos para agentes de programación, planteó la cuestión abierta con claridad. Los autores preguntaron si un agente de programación puede hacer ya la mayor parte del trabajo de un equipo de BI, y respondieron: casi. Necesitan una capa de contexto «para garantizar la corrección de las consultas».

La corrección es todo el juego. Un modelo que se equivoca un poco en la consulta devuelve igualmente un gráfico seguro de sí mismo. Un modelo al que se pide resumir una investigación escribirá sin pestañear «la mayoría de los usuarios» o un porcentaje redondo que salió de la nada. El resultado parece terminado, y terminado no es lo mismo que cierto.

Lo que mantuvo honesto a Desmontado no fue un modelo más listo. Fue un conjunto de reglas que hacen el trabajo comprobable, y valen para cualquier análisis en el que intervenga una IA.

Que escriba código, no conclusiones. El escáner es un archivo que descarga páginas y registra lo que vio. No decide nada. Pide al modelo el script que cuenta y ejecútalo tú. Un script se puede releer y repetir. Un párrafo no.

Que registre los desconocidos. «Medido, nunca supuesto» está en las primeras líneas del escáner por una razón. Si un modelo rellena un valor ausente con uno probable, tu resultado es en parte dato y en parte ficción, y no puedes distinguir cuál es cuál.

Exige la base de cada número. A cualquier porcentaje de un resumen escrito por IA se le hacen dos preguntas: de cuántos y en qué archivo. Si no puede responder a las dos, bórralo. Sin excepción para los números que suenan bien.

Abre tú las filas originales. Antes de fiarte de un tema, lee cinco reseñas reales que lo componen. Antes de fiarte de un recuento, abre tres de las webs que contó. La muestra de Desmontado supera esa prueba: los recuentos saudí y de EAU del CSV coinciden con el ensayo.

Mantén el orden y la regla de parada fuera del modelo. El modelo no debe decidir qué registros leer ni cuándo parar. Es el lugar más fácil por el que se cuela un resultado conveniente, y es una decisión que te corresponde.

Publica el método si publicas el número. El escáner, la muestra y las notas de muestreo están junto al ensayo. Es la mejor comprobación que existe. Si me equivoqué en algo, cualquiera puede encontrarlo.

Escribí sobre la otra mitad de esto en [¿puede la IA sustituir la investigación con usuarios?](https://laithjunaidy.com/es/writing/can-ai-replace-user-research): un modelo es bueno redactando, ordenando y listando, y malo siendo tu usuario. El análisis de datos es donde resulta a la vez más útil y más peligroso, porque el resultado son números, y la gente se fía de los números sin leerlos.

## ¿Cuándo no conviene empezar por los datos?

Cuando aún no hay nada que leer, o cuando los datos que tienes cuentan lo que no es.

Una idea nueva sin producto no tiene sesiones que analizar. Los datos públicos pueden ayudar igualmente: webs de la competencia, reseñas del producto más parecido, el lenguaje que usa la gente en los foros. Pero la investigación principal son las entrevistas, y no hay que esperar a números que no existen.

Seis respuestas de encuesta son una pista, no un hallazgo. No calcules medias con decimales para presentarlas como resultado. Di lo que sugieren y ve a preguntar.

Una métrica puede seguir el resultado equivocado. Los clics, el tiempo en página y las sesiones pueden subir cuando una página confunde. Si tus datos premian la conducta equivocada, más análisis hace que el problema parezca más preciso. Decide primero qué intenta hacer el usuario y elige después el número que lo mide.

La población puede escribir en un idioma que tus herramientas leen mal. Las reseñas en árabe con dialecto, escrituras mezcladas e inglés transliterado son difíciles de ordenar para las herramientas, y no verás los errores a menos que leas tú las reseñas. Esa es una razón por la que Desmontado contó cosas que una máquina lee con exactitud, letras árabes y códigos de estado, y evitó todo lo que requiere que un modelo adivine el significado.

## ¿Cómo queda la próxima vez?

El mismo método sirve a cualquier escala. [Desmontado, número uno](https://laithjunaidy.com/es/writing/taken-apart-shadcn-defaults) se hizo en GitHub en vez de en webs: los 150 repositorios de shadcn/ui con más estrellas, con la tipografía y el color primario leídos del código. Un repo donde la señal no se podía leer se contó como ilegible, nunca supuesto, lo que dejó 67 con una tipografía legible. 59 de esos 67 usan Geist o Inter. Mismas reglas, otra fuente.

![Gráficos de barras de los 150 repos de shadcn/ui con más estrellas: el 88 por ciento usa Geist o Inter, el 75 por ciento incluye un color primario neutro](https://laithjunaidy.com/writing/taken-apart-1/chart.png)

*[Desmontado, número uno](https://laithjunaidy.com/es/writing/taken-apart-shadcn-defaults). Las bases están impresas en el gráfico: solo repos legibles, nunca suposiciones.*

Si quieres hacer tu propia versión, el orden es este:

1. Una pregunta que puedas responder con un recuento.
2. Una fuente, leída en un orden fijo, con reglas escritas sobre lo que cuenta.
3. Una regla de parada fijada de antemano.
4. Definiciones escritas antes del primer registro.
5. Un escáner o una consulta que mida y registre los desconocidos.
6. Cada resultado como recuento, base y porcentaje.
7. Una comprobación del archivo publicado contra la afirmación publicada.
8. El método y la muestra publicados junto al número.
9. Una lista de las personas a las que ahora tienes que preguntar por qué.

El último paso es el que convierte el análisis en diseño. El recuento dice que 53 de 67 startups de EAU con financiación solo están en inglés. No requirió acceso ni permiso de nadie. Averiguar el porqué requerirá conversaciones, y la razón decidirá qué debería construir cualquiera.

## Preguntas frecuentes

### ¿Qué es el análisis de datos en UX?

Leer lo que ya existe antes de investigar o diseñar algo nuevo: analítica, embudos, ventas, tickets de soporte, registros de búsqueda, reseñas de aplicaciones y datos públicos. Muestra dónde abandona la gente y a cuántas personas afecta. Es el método de investigación más barato, por eso va primero, y termina con preguntas para entrevistas, no con una solución.

### ¿Qué diferencia hay entre análisis de datos e investigación secundaria?

Se solapan. La investigación secundaria, o investigación documental, es reunir lo que otros ya encontraron: informes, estudios, investigaciones antiguas. El análisis de datos es leer tú mismo registros en bruto, los números de tu propio producto o datos públicos, y contar algo. Desmontado fue análisis de datos sobre datos públicos: un flujo de financiación, leído en orden, y las páginas en árabe de 100 empresas revisadas con un escáner.

### ¿Pueden los datos decir por qué abandonan los usuarios?

No. Los datos muestran dónde se van las personas y cuántas. No pueden mostrar qué intentaban hacer, qué les confundió ni qué esperaban. NN/g plantea lo mismo: los datos cuantitativos pueden decir que algo no funciona, pero no qué problemas encontraron los usuarios ni qué cambiar. Usa los datos para elegir a quién entrevistar y qué preguntar.

### ¿Cómo se analizan las opiniones de los clientes con IA?

Dale al modelo las opiniones en bruto, pide temas con cada elemento etiquetado con su fuente y pide recuentos con su base. Después lee tú cinco elementos reales de cada tema, borra cualquier porcentaje sin recuento ni archivo detrás y trata el resultado como preguntas para entrevistas. La IA es rápida ordenando. No es una fuente de verdad.

### ¿Qué tamaño debe tener una muestra?

El suficiente para la pregunta, decidido antes de mirar. Desmontado fijó su regla de antemano: revisar por orden cada empresa que cumpliera los criterios hasta reunir 100 con versión en árabe, lo que supuso 184 empresas. Una muestra diminuta, como seis respuestas de encuesta, puede servir igualmente como motivo para ir a hablar con la gente, nunca como un hallazgo por sí sola.

### ¿Por qué publicar el escáner y la muestra?

Porque un número que nadie puede comprobar es una afirmación, no un hallazgo. Publicar [scan.mjs](https://laithjunaidy.com/writing/taken-apart-2/scan.mjs), [sample.csv](https://laithjunaidy.com/writing/taken-apart-2/sample.csv) y [cómo se obtuvo la muestra](https://laithjunaidy.com/writing/taken-apart-2/SAMPLE.md) permite que cualquiera repita el estudio, encuentre un error o lo amplíe. Los resultados por empresa se mantuvieron privados. Lo que importaba era el patrón, no una lista de nombres.