Un toolbox con funcionalidades diseñadas para obtener conocimiento, datos e ideas, para aplicar en tu proceso de trabajo de research, diseño, etc.
Insights®, by Ego Agency
Insights® es un producto (toolbox) que contiene funcionalidades, diseñadas por especialistas con más de 20 años de experiencia en la industria digital, para hacer más ágil, eficiente y profundo cada proceso de investigación y discovery.
Insights® es un producto (toolbox) que contiene funcionalidades, diseñadas por especialistas con más de 20 años de experiencia en la industria digital, para hacer más ágil, eficiente y profundo cada proceso de investigación y discovery.
Seleccionás qué querés analizar: SEO, UX, CRO, accesibilidad, tech stack, arquitectura o sentiment. Cada función tiene su propio framework especializado.
Cada función pide los inputs que necesita: URL del sitio, nombre de marca, tipo de negocio u otros datos específicos según el análisis.
El motor de IA procesa la evidencia con el framework especializado de la función seleccionada, aplicando criterios de expertos de la industria.
Score, hallazgos, recomendaciones priorizadas y roadmap. Listo para presentar al cliente o usar como base para el proyecto.
Cada herramienta es un diagnóstico especializado que traduce datos en decisiones. Insights concretos para avanzar a paso firme, sin conjeturas.
Corre directo en el navegador. Sin APIs de terceros, sin tokens, sin setup técnico previo.
Lo que antes tomaba días de investigación manual ahora se produce en minutos con la misma profundidad analítica.
Cada función aplica frameworks diseñados por especialistas senior de EGO con experiencia real en proyectos digitales de escala.
El output es un HTML autocontenido con score, hallazgos visuales y recomendaciones accionables. Se entrega directo al cliente.
Cada diagnóstico incluye recomendaciones priorizadas por impacto, con hipótesis de mejora y roadmap de implementación.
El toolbox crece con nuevas funciones y criterios actualizados. Cada suscripción incluye todas las actualizaciones sin costo adicional.
Cada herramienta es un diagnóstico especializado que traduce datos en decisiones. Insights concretos para avanzar a paso firme, sin conjeturas.
Construí un producto SaaS completo, solo, sin ser developer. Lo que aprendí sobre la secuencia correcta de trabajo con IA y por qué el criterio no se automatiza.
Juan Julio Spinetto · Proceso & aprendizajePara quién está dirigido el FAE, cuánto cuesta no saber qué está fallando, y por qué velocidad y profundidad no son excluyentes cuando la metodología es sólida.
EGO Design · Consultoría & FAEEl stack completo de APIs, servicios e integraciones detrás de cada reporte. Por qué los resultados son verificables, no estimados, y qué hace que la calidad sea de primer nivel.
EGO Design · Stack & MetodologíaArquitectura, seguridad, modelo de acceso, pasarela de pagos y el detalle técnico de las 8 funciones. Todo visible. Sin caja negra.
EGO Design · Transparencia & SeniorityLa arquitectura de información no se ve, pero todos la sienten. Por qué es la primera pregunta de cualquier auditoría y qué revela sobre el estado real de un sitio.
Juan Julio Spinetto · Arquitectura & AICómo un rediseño mal ejecutado me hizo entender que SEO y UX son la misma disciplina vista desde distintos ángulos. Y por qué los Core Web Vitals lo confirman.
Juan Julio Spinetto · SEO & PerformanceLa diferencia entre usabilidad y experiencia. Por qué las heurísticas de Nielsen siguen vigentes después de 30 años, y qué agrega el análisis visual al diagnóstico estructural.
Juan Julio Spinetto · UX & UsabilidadPor qué el diseño visual no garantiza la conversión, qué hace que alguien tome la decisión de comprar, y por qué el problema casi nunca está en el botón.
Juan Julio Spinetto · Conversión & FunnelSiendo jurado en Awwwards vi sitios extraordinarios que fallaban en accesibilidad básica. Por qué la accesibilidad es una decisión de diseño, no un checklist de compliance.
Juan Julio Spinetto · Accesibilidad & InclusiónNo soy developer, pero aprendí que ignorar el estado técnico de un sitio al tomar decisiones de diseño es un error que se paga caro. La deuda técnica como límite invisible del diseño.
Juan Julio Spinetto · Stack & Deuda TécnicaEl gap más común en los briefs de diseño: la percepción real de la marca. Por qué escuchar antes de diseñar cambia las decisiones que se toman después.
Juan Julio Spinetto · Percepción & SentimentEn e-commerce cada decisión tiene una consecuencia medible. Lo que aprendí de años de auditorías en retail y por qué el diagnóstico siempre precede al rediseño.
Juan Julio Spinetto · E-Commerce & ConversiónUna colección curada de métodos, modelos y principios de diseño — pensada para ayudarte a decidir qué hacer después de leer tu reporte de Insights.
Cargando contenido…
Por Juan Julio Spinetto
La arquitectura de información es la decisión de diseño más invisible y más determinante que existe. Nadie la ve, pero todos la sienten. Cuando el usuario abandona a los 30 segundos sin saber bien por qué, generalmente es un problema de arquitectura. No de diseño visual. No de velocidad. De estructura.
En 15 años de consultoría, la primera hora de cualquier auditoría siempre fue la misma: mapear a mano cómo estaba organizado el sitio. Navegando, anotando, trazando el árbol de páginas en un documento o en una pizarra. Era trabajo tedioso pero necesario — sin ese mapa, el resto del análisis era especulación sobre síntomas en vez de diagnóstico de causas.
Uno de los proyectos que más me marcó fue una auditoría para una empresa de servicios financieros. El cliente nos decía que el sitio era claro. Que sus empleados lo navegaban sin problema. Que los clientes "ya sabían cómo funciona". Lo que no veían era que sus empleados llevaban años usando ese sitio y habían desarrollado un modelo mental que los usuarios nuevos nunca iban a construir en tres clics.
Cuando mapeamos la arquitectura real — no la del sitemap declarado, sino la que emergía de seguir los links — encontramos 14 secciones en el primer nivel de navegación, dos de las cuales tenían nombres que solo tenían sentido si ya sabías lo que había adentro. Eso es lo que yo llamo una arquitectura hecha para el organigrama, no para el usuario.
La estructura de navegación que tiene sentido para el equipo interno casi nunca es la misma que tiene sentido para quien llega por primera vez. Esa brecha es el problema más frecuente que encuentro, y también el más costoso, porque atraviesa todas las capas del producto.
Porque todo lo que viene después depende de ella. El SEO depende de la estructura de URLs y el internal linking. La conversión depende de si el usuario encuentra lo que busca antes de frustrarse. La accesibilidad depende de si la navegación es predecible. El rediseño visual fracasa si la arquitectura subyacente está rota — solo le pone maquillaje a un problema estructural.
Trabajé con clientes en retail, banca, automotriz y telco. En sectores tan distintos, el denominador común de los problemas de experiencia era casi siempre el mismo: estructura de información inconsistente, profundidad de navegación excesiva, secciones que existían por razones históricas que ya nadie recordaba pero que nadie se animaba a tocar.
Rediseñar sin auditar la arquitectura primero es como repintar una casa sin revisar los cimientos. El resultado se ve mejor. Dura menos.
Hay un concepto en arquitectura de información que se llama "information scent" — el rastro de señales que le indica al usuario si está yendo en la dirección correcta. Cuando ese rastro es claro, el usuario navega con confianza. Cuando es ambiguo, empieza a dudar, a hacer backtrack, a explorar sin dirección. Ese comportamiento es invisible en el diseño pero visible en las métricas: bounce rate alto, tiempo en sitio bajo, rutas de navegación erráticas en los heatmaps.
La función de arquitectura busca exactamente eso: verificar si el mapa mental que construye el usuario cuando navega coincide con lo que el negocio quiere que haga. La jerarquía real del sitio, no la que alguien dibujó en un Figma hace tres años. Los links que el usuario ve versus los que el sitio declara en el sitemap. Las páginas huérfanas que acumulan tráfico sin estar conectadas al flujo principal.
Hay un componente que empezó a importar en los últimos años y que los análisis tradicionales de arquitectura no contemplaban: la rastreabilidad para motores de IA. Los LLMs aprenden de sitios web. Los crawlers de Perplexity, ChatGPT Search, Claude.ai — todos necesitan poder leer y estructurar el contenido de un sitio. Si la arquitectura no es limpia, si los headings no tienen jerarquía, si el contenido está fragmentado en decenas de páginas sin contexto, el sitio no va a ser citado ni recuperado por estos sistemas.
Eso es AI Readiness. Y ya no es una consideración futura — es una ventaja competitiva presente para las marcas que lo entienden ahora.
Un análisis de arquitectura basado en datos del sitio no puede reemplazar el card sorting con usuarios reales ni el tree testing con prototipos. Esas metodologías validan hipótesis con comportamiento real. Lo que esta función hace es mapear el estado actual con precisión, identificar los problemas más evidentes, y proveer el punto de partida para esas validaciones posteriores. El diagnóstico antes del test. La radiografía antes de la cirugía.
Juan Julio Spinetto — Co-fundador EGO, especialista UX/CX y Service Design. 15 años diseñando experiencias digitales en retail, banca, automotriz y telco.
Cargando...
Última actualización: Junio 2026
Insights® es un producto de EGO Design, con sede en Buenos Aires, Argentina. Esta política describe cómo recopilamos, usamos y protegemos la información de los usuarios del sitio insights.egodesign.io.
Al registrarte: nombre, apellido, email, nombre de usuario y empresa (opcional). Los datos se almacenan en Supabase (PostgreSQL) con cifrado en tránsito y en reposo.
Al usar el producto: los reportes generados (función analizada, URL del sitio, resultados) se guardan asociados a tu cuenta para que puedas acceder a ellos. El HTML scrapeado de los sitios analizados no se persiste — se usa solo para generar el reporte y se descarta.
Analytics (con tu consentimiento): si aceptás las cookies, Google Analytics 4 recopila datos de navegación anónimos (páginas visitadas, eventos, duración de sesión). Podés rechazar o revocar el consentimiento en cualquier momento.
Pagos: los datos de tarjeta de crédito son procesados directamente por Stripe y nunca pasan por nuestros servidores. Solo almacenamos el ID del cliente y la suscripción.
Contacto Enterprise: si completás el formulario de contacto, guardamos tu nombre, email, empresa y mensaje en nuestra base de datos para responder tu consulta.
No vendemos ni compartimos tus datos con terceros con fines comerciales.
El producto utiliza los siguientes servicios externos:
Tenés derecho a:
Para ejercer cualquiera de estos derechos, escribinos a julio.spinetto@egodesign.io.
Implementamos medidas técnicas para proteger tus datos: HTTPS en todas las comunicaciones, Row Level Security (RLS) en la base de datos, secrets almacenados en variables de entorno, verificación de firma en webhooks de pago, y output sanitizado para prevenir XSS.
Conservamos tus datos mientras mantengas una cuenta activa. Al eliminar tu cuenta, tus datos personales y reportes son eliminados de nuestra base de datos.
Solo usamos cookies funcionales (sesión de usuario, preferencias de tema) y analíticas (Google Analytics, con consentimiento). No usamos cookies de publicidad ni de seguimiento de terceros.
Esta política se rige por la Ley Argentina de Protección de Datos Personales N° 25.326. Para usuarios de la Unión Europea, cumplimos con los principios del RGPD/GDPR.
EGO Design · Buenos Aires, Argentina
Email: julio.spinetto@egodesign.io
Sitio: insights.egodesign.io
2 lecturas · EGO Design
Construí un producto SaaS completo, solo, sin ser developer. Lo que aprendí sobre la secuencia correcta de trabajo con IA y por qué el criterio no se automatiza.
Juan Julio Spinetto · Proceso & aprendizajePara quién está dirigido el FAE, cuánto cuesta no saber qué está fallando, y por qué velocidad y profundidad no son excluyentes cuando la metodología es sólida.
EGO Design · Consultoría & FAEEl stack completo de APIs, servicios e integraciones detrás de cada reporte. Por qué los resultados son verificables, no estimados, y qué hace que la calidad sea de primer nivel.
EGO Design · Stack & MetodologíaPor Juan Julio Spinetto
Construí un producto SaaS completo, solo, sin ser developer. Cuatro engines de análisis, backend serverless, persistencia en Notion, reportes HTML con diseño cuidado, sistema de auth y modo demo.
No soy developer. Soy diseñador UX con 15 años de experiencia. Esto es lo que aprendí en el proceso.
Desde EGO hacemos auditorías de experiencia digital para clientes en retail, banca, automotriz y telco. El proceso siempre fue riguroso pero costoso en tiempo. Un análisis completo podía llevar días, y eso limitaba cuántos clientes podíamos atender en paralelo.
La pregunta que me hice fue: ¿qué pasaría si pudiera automatizar la parte de análisis y usar ese tiempo ganado para ir más profundo donde más importa?
El aprendizaje más importante fue la secuencia correcta de construcción cuando se trabaja con IA:
Skill conversacional → Validación metodológica → Backend productizado
Primero el skill. Antes de escribir una sola línea de código, construí el análisis como un prompt muy elaborado. Lo testeé en conversación hasta que el resultado era consistente y útil.
El skill como especificación. Cuando el prompt producía outputs confiables, eso ya era la especificación del backend. No necesité escribir un PRD aparte.
El producto como automatización. El backend envolvió en infraestructura lo que el skill ya sabía hacer. Esto cambió algo importante: el diseñador puede ser el arquitecto del conocimiento del producto, no solo el usuario final.
No es la velocidad — aunque eso es visible. Es dónde va el tiempo de mayor valor. La IA no me hace un mejor analista — me da más tiempo para hacer el trabajo donde realmente agrego valor como consultor.
La IA no reemplaza la necesidad de entender el problema real antes de diseñar. No reemplaza el criterio para distinguir un hallazgo relevante de uno anecdótico. Un output de IA es tan bueno como el input que le das.
Los consultores que integren IA como amplificador de su metodología van a poder dar un nivel de profundidad y velocidad que antes requería equipos más grandes. Lo que se vuelve más valioso no es el análisis en sí — es saber qué analizar, cómo interpretarlo y qué hacer con los hallazgos.
Juan Julio Spinetto — Co-fundador EGO, especialista UX/CX y Service Design. 15 años diseñando experiencias digitales en retail, banca, automotriz y telco.
EGO Full Assessment Engine
El Full Assessment Engine es un sistema de auditoría de experiencia digital desarrollado por EGO. Combina metodología UX/CX de 15 años con inteligencia artificial para analizar en horas lo que antes requería semanas de consultoría. Examina simultáneamente 9 dimensiones del ecosistema digital de una organización — desde usabilidad y contenido hasta performance técnica, accesibilidad, SEO y customer journey — y produce un scorecard multidimensional con hallazgos priorizados por impacto y un roadmap de mejora accionable.
No es una herramienta genérica ni un checklist automatizado. Es metodología probada en proyectos reales con clientes de banca, retail, automotriz y telco, potenciada con IA para ampliar la velocidad y el alcance del análisis sin resignar criterio ni profundidad.
Para directores de producto, gerentes de marketing, CTOs y CEOs que toman decisiones sobre experiencias digitales — y que necesitan saber qué tan bien está funcionando realmente lo que tienen, sin depender de la intuición ni de reportes parciales.
Si tu organización tiene un sitio, una app o un ecosistema digital que impacta en ingresos o en la relación con el cliente, este análisis es para vos.
Cada mes sin un diagnóstico claro tiene un precio: conversión que se pierde sin causa aparente, usuarios que abandonan sin dejar señales claras, fricción que se acumula y erosiona la percepción de marca. La mayoría de los problemas de experiencia son invisibles hasta que se vuelven urgentes.
Un análisis completo cuesta menos que un mes de fricción sin resolver. Y la información que genera vale meses de decisiones mejor fundamentadas.
La promesa no es solo velocidad. Es velocidad con rigor. El FAE analiza 9 módulos de forma simultánea — UX, contenido, SEO técnico, performance, accesibilidad, customer journey, competitive benchmark, conversión y ecosistema digital — y los cruza para producir un scorecard multidimensional con hallazgos priorizados.
Lo que antes tomaba semanas de consultoría ahora es un proceso de horas. El tiempo ganado va a interpretación estratégica, no a relevamiento.
Una consultoría tradicional tarda semanas, cuesta más y depende de la disponibilidad del equipo consultor. El FAE entrega la misma profundidad metodológica en una fracción del tiempo, porque la IA hace el trabajo de síntesis y el criterio humano hace el trabajo de interpretación.
No es un template genérico. El análisis se construye sobre 15 años de metodología UX/CX especializada en industrias con alta complejidad de experiencia: banca, retail, automotriz y telco. Cada hallazgo se contextualiza dentro del ecosistema del cliente, no en abstracto.
"Ya sé que tenemos problemas, no necesito que me lo digan." Saber que hay problemas no es lo mismo que tener un mapa claro de cuáles son, cuánto impactan y en qué orden conviene resolverlos. El valor del diagnóstico no está en confirmar que hay fricción — está en darte el criterio para priorizar sin adivinar.
No hay que esperar una crisis para hacer un diagnóstico. El mejor momento es antes de una inversión grande en rediseño, antes de un lanzamiento importante, o cuando los números muestran señales de alerta sin una causa clara. El FAE te da el contexto para decidir mejor, no después de equivocarte.
EGO Design — Consultoría de experiencia digital. Probá el FAE →
EGO Design · Stack & Metodología
Cada reporte que genera Insights® es el resultado de una cadena de procesos automatizados — pero automatizados no significa genéricos. Cada proceso fue diseñado, refinado y validado a partir de años de trabajo real: diagnósticos de sitios, auditorías con clientes, errores cometidos y patrones que se repiten. Lo que se automatizó no es una fórmula aprendida de libros, sino una forma de pensar forjada en el hacer. Esta página documenta exactamente cómo funciona ese proceso.
Los modelos de lenguaje como Claude son extraordinariamente capaces de razonar y sintetizar. Pero sin acceso a datos actuales, operan desde su conocimiento de entrenamiento — lo que saben de un sitio o una marca hasta cierta fecha. Para análisis de calidad profesional, eso no es suficiente.
La arquitectura de Insights® resuelve este problema en dos niveles: scraping real de cada sitio para las 7 funciones URL-based, y búsqueda web en tiempo real para Social Listening. Claude recibe evidencia verificable antes de escribir una sola línea de reporte.
Cuando ingresás una URL, el sistema intenta obtener el HTML real del sitio en cuatro capas sucesivas, en orden de costo y complejidad:
El sistema detecta automáticamente si un sitio es un JS shell — un HTML vacío producido por frameworks como React, Next.js, Vue, Angular, Shopify o Webflow — y en ese caso escala directamente a Firecrawl, que renderiza el JavaScript con un browser headless real antes de devolver el contenido.
El parser HTML no solo guarda el código crudo. Extrae y estructura más de 30 señales específicas que Claude necesita para un análisis riguroso:
Estructura semántica: todos los H1, H2 y H3 reales, título de página, meta description, canonical, idioma declarado, estructura de headings.
Navegación real: todos los links de <nav> y <header> con sus textos y destinos. Si el menú tiene 8 ítems, Claude los ve todos.
CTAs detectados: botones y links con texto de conversión — "Comprar", "Contratar", "Contactar", "Demo". Claude analiza cuántos hay, dónde están y qué dicen.
Formularios completos: cada form con sus campos, labels, placeholder, botón de submit, y si tiene link de privacidad.
Stack tecnológico: scripts externos que revelan el framework, analytics (GA4, GTM, Hotjar, Clarity, Meta Pixel), CMS, CDN y herramientas de terceros.
Señales de seguridad: headers HTTP reales — HSTS, CSP, X-Frame-Options, Referrer-Policy — capturados en la misma solicitud.
JSON-LD y Schema.org: datos estructurados completos, mostrando qué tipos usa el sitio (Organization, Product, FAQ, BreadcrumbList).
Open Graph y redes sociales: metadatos para compartir y links a perfiles sociales detectados en el HTML.
Robots.txt y Sitemap.xml: directivas de rastreo y conteo real de páginas indexadas con sample de URLs.
Subpáginas clave: el sistema intenta scrapear automáticamente /about, /contacto y /privacidad, extrayendo su contenido para análisis de credibilidad y compliance.
Para las funciones de SEO y Diagnóstico Técnico, el sistema llama en paralelo a la API de Google PageSpeed Insights y obtiene métricas medidas por los servidores de Google — no estimadas por Claude:
Core Web Vitals reales: LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), FCP (First Contentful Paint) y TBT (Total Blocking Time) con sus valores exactos en milisegundos.
Scores certificados: Performance, Accessibility, Best Practices y SEO en escala 0–100, los mismos que muestra Google en su herramienta pública.
Oportunidades de mejora: los 8 principales problemas detectados por Lighthouse con ahorro potencial en milisegundos.
La función de Accesibilidad WCAG va un paso más allá. Ejecuta el audit de accesibilidad de Lighthouse — que internamente usa axe-core, el motor de testing de accesibilidad más utilizado en la industria — en modo mobile y desktop simultáneamente.
Claude recibe cada fallo con su ID de audit exacto, el criterio WCAG violado (por ejemplo: WCAG 1.4.3 (AA) — Contraste mínimo), el nivel de impacto (Crítico / Serio / Moderado) y los snippets HTML reales de los elementos que fallan. No hay estimaciones: si color-contrast falla en 3 elementos específicos, Claude sabe exactamente cuáles son.
La función de Social Listening & Sentiment Analysis usa una lógica diferente: en vez de scrapear un sitio, busca qué se dice de la marca en internet en este momento. El sistema lanza 7 búsquedas en paralelo usando la API de Brave Search:
Opiniones generales en el mercado local, reseñas en plataformas especializadas (Trustpilot, G2, Capterra), conversaciones en Reddit y foros, noticias y cobertura mediática reciente, quejas y reclamos, menciones en redes sociales, y benchmark comparativo si se especificaron competidores.
Cada búsqueda devuelve resultados reales con título, descripción y URL. Claude analiza esos resultados — no su memoria — y puede citar fuentes verificables en el reporte.
Para las funciones de UX, CRO y E-Commerce, cuando Firecrawl renderiza el sitio, también captura un screenshot de la página. Esa imagen se convierte en base64 y se envía a Claude junto con toda la evidencia textual.
Esto permite análisis que antes eran imposibles de automatizar: visibilidad real de los CTAs, jerarquía visual del above-the-fold, contraste percibido, calidad del diseño, presencia de trust badges, layout del carrito o de la ficha de producto — exactamente como lo haría un consultor viendo la pantalla.
Toda la evidencia recolectada se entrega a Claude Sonnet 4.6 de Anthropic, con un límite de 16.000 tokens de output — el doble de lo habitual en implementaciones estándar. Esto permite reportes con la profundidad necesaria para cubrir los 5 módulos de cada función con el nivel de detalle que requiere un análisis profesional.
La regla central en todos los prompts es la misma: analizar primero la evidencia concreta, complementar con conocimiento solo cuando la evidencia es insuficiente, nunca inventar datos.
La tecnología resuelve el acceso a los datos. Pero lo que convierte esos datos en un diagnóstico con criterio profesional es algo que no se puede comprar en ningún marketplace de APIs: 15 años de metodología de consultoría codificada en cada función.
Cada una de las 8 funciones de Insights® tiene un skill — un conjunto de instrucciones de análisis — diseñado específicamente por los especialistas de EGO para su disciplina. No son prompts genéricos de "analizá este sitio". Son marcos analíticos que reflejan cómo razona un consultor senior en cada área:
01 — Arquitectura del Sitio: Mapeo del árbol de páginas, evaluación de jerarquía de navegación, análisis de internal linking y estrategia de URLs, detección de páginas huérfanas, y construcción de una Nav Spec completa con header, footer y breadcrumbs recomendados. El mismo proceso que sigue un arquitecto de información al diseñar o auditar la estructura de un sitio.
02 — SEO & Visibilidad: Análisis de los cuatro pilares del SEO moderno — técnico, on-page, off-page y de contenido — con especial atención a señales de E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness), que son los criterios que Google usa hoy para evaluar la autoridad de un sitio. Los Core Web Vitals reales de Google se integran directamente en el diagnóstico de performance SEO.
03 — UX & Usabilidad: Evaluación sistemática contra las 10 heurísticas de usabilidad de Nielsen, análisis de arquitectura de información, diseño visual y experiencia mobile. Cuando hay screenshot disponible, Claude lo analiza como lo haría un diseñador UX senior revisando la pantalla: jerarquía visual, claridad del above-the-fold, affordance de los elementos interactivos.
04 — CRO & Conversión: Framework de análisis de conversión que examina el funnel completo: messaging y propuesta de valor, visibilidad y jerarquía de CTAs, trust signals, friction points y señales de intención de compra. Identifica dónde se pierde conversión y por qué, con recomendaciones priorizadas por impacto estimado en tasa de conversión.
05 — Accesibilidad WCAG: Evaluación contra los cuatro principios WCAG 2.1 — Perceptible, Operable, Comprensible, Robusto — con los 30+ criterios auditados por Lighthouse y axe-core mapeados a sus criterios de éxito exactos y nivel de conformidad (A, AA, AAA). Para cada fallo: qué impacto tiene en usuarios con discapacidad visual, motriz, auditiva o cognitiva, y qué corrección técnica específica corresponde.
06 — Diagnóstico Técnico: Detección del stack completo (frontend, backend, hosting, CDN, build tooling), auditoría de headers de seguridad HTTP, análisis de deuda técnica con comparación de versiones detectadas vs. actuales, y roadmap de mejoras técnicas en tres fases. Los datos de PageSpeed Insights se usan como fuente primaria para el módulo de performance.
07 — Social Listening & Sentiment: Análisis de cinco capas de conversación digital — redes sociales, Reddit y foros, plataformas de review, cobertura mediática y comparativas — usando resultados reales de búsqueda. Incluye identificación de arquetipos de usuario (Defensor, Frustrado Regular, Churner Vocal, Power User, Casual, Escéptico), mapa emocional y señales de intención, y diagnóstico de reputación digital con semáforo.
08 — E-Com Optimization: Framework específico de CRO para e-commerce que evalúa la ficha de producto (imágenes, copy, precio, variantes, reviews), el flujo de carrito y checkout (pasos, fricción, guest checkout, medios de pago), trust signals y urgencia, experiencia mobile y estrategia de recuperación de abandono. Las recomendaciones se priorizan por impacto directo en tasa de conversión.
Estos skills no son plantillas genéricas. Son la destilación de cómo los especialistas de EGO piensan, preguntan y diagnostican en cada disciplina — ahora disponibles a escala, en minutos, para cualquier sitio.
La diferencia entre un reporte genérico de IA y un reporte de Insights® no está en el modelo de lenguaje — está en los datos que recibe antes de escribir. Un modelo que trabaja de memoria produce análisis plausibles. Un modelo que analiza el HTML real, las métricas reales de Google, los fallos reales de accesibilidad y las menciones reales en internet produce diagnósticos verificables.
Cada hallazgo puede ser comprobado. Cada score tiene una fuente. Cada recomendación está anclada en evidencia concreta, no en patrones genéricos del tipo de sitio.
Eso es lo que diferencia a Insights® de cualquier herramienta que simplemente le pida a una IA que "analice" una URL sin haberla visitado primero.
EGO Design — Consultoría de experiencia digital amplificada con IA.
EGO Design · Transparencia & Seniority
La mayoría de los productos SaaS construyen una caja negra. Vos ingresás una URL, algo pasa adentro, y recibís un resultado. Si el resultado está bien, confiás. Si está mal, no tenés forma de saber por qué.
Insights® funciona diferente. Esta página documenta, sin omisiones, cómo está construido el sistema: qué pasa desde que ingresás una URL hasta que recibís el reporte, cómo se protegen los datos, cómo funciona el modelo de acceso, cómo se procesan los pagos, y el detalle técnico de cada una de las 8 funciones. No porque tengamos obligación de mostrarlo — sino porque creemos que la transparencia es una forma de respeto hacia quien usa el producto.
Si entendés cómo funciona, podés evaluar si confiar. Eso es seniority.
Insights® es una aplicación serverless deployada en Vercel, con infraestructura distribuida globalmente en la red edge de Vercel. No hay servidores propios que mantener, escalar ni monitorear — cada request se ejecuta en la región más cercana al usuario que lo inicia.
El frontend es un único archivo HTML estático (insights.html) servido directamente desde el CDN de Vercel con latencia de milisegundos. Las funciones de análisis son serverless functions en Node.js bajo /api/ — se instancian bajo demanda, ejecutan el análisis y se apagan. No hay estado entre requests.
La base de datos es Supabase (PostgreSQL managed), usado para autenticación de usuarios, almacenamiento de reportes y gestión de planes. Los secrets (API keys, tokens) viven exclusivamente en variables de entorno de Vercel — nunca en el código fuente, nunca expuestos al cliente.
Autenticación: Supabase Auth maneja el ciclo completo de sesiones — registro, login, reset de contraseña, refresh automático de tokens. Las contraseñas nunca pasan por el código de Insights® ni se almacenan en ninguna tabla propia: Supabase las hashea con bcrypt antes de persistirlas.
Autorización (Row Level Security): La tabla profiles tiene RLS habilitado en PostgreSQL. Esto significa que cada usuario solo puede leer y escribir su propia fila — a nivel de base de datos, no solo de aplicación. Aunque alguien encontrara la URL de la API de Supabase, no podría leer datos de otro usuario. Las operaciones administrativas (actualizar planes post-pago, verificar emails) usan la SERVICE_KEY exclusivamente server-side.
API keys: Todas las claves de servicios externos — Anthropic, Stripe, Brave Search, Firecrawl, Apify — viven en variables de entorno de Vercel. El frontend solo tiene acceso a la clave publicable de Supabase (sb_publishable_...), que por diseño no puede realizar operaciones privilegiadas.
Webhooks de Stripe: Cada evento entrante se verifica con firma HMAC usando el STRIPE_WEBHOOK_SECRET. Si la firma no coincide, el request se rechaza con 400. No es posible falsificar un evento de pago.
El sistema de acceso tiene cuatro niveles, controlados por la columna plan en la tabla profiles de Supabase:
Anónimo: puede navegar todo el sitio, acceder a las páginas de cada función y ver la documentación general. No puede leer artículos internos de documentación ni ejecutar análisis.
Registrado (free): todo lo anterior más acceso completo a los artículos de documentación. No puede ejecutar funciones de análisis.
On Demand ($10 · pago único): puede ejecutar exactamente 2 análisis a elección, sin vencimiento. El contador se descuenta server-side vía /api/utils (acción use-function) — no es posible saltear el límite manipulando el cliente. Cada ejecución pasa primero por una validación en servidor que verifica el plan y decrementa el contador atómicamente antes de permitir el análisis.
Plan Insights® y Plan Insights Pro (suscripción mensual): ejecuciones ilimitadas. El plan se activa automáticamente cuando Stripe confirma el pago exitoso via webhook. Si la suscripción se cancela, el plan vuelve a free automáticamente.
Enterprise: sin procesamiento automático — activa un formulario de contacto directo. La activación de plan enterprise se gestiona manualmente por el equipo de EGO.
Cuando un usuario hace click en "Comprar" o "Suscribirse", el flujo es el siguiente:
El servidor crea una Stripe Checkout Session con el Price ID correspondiente al plan elegido. Stripe maneja todo el proceso de pago — datos de tarjeta, 3DS, reintentos — en su infraestructura certificada PCI DSS. Insights® nunca ve ni almacena datos de tarjeta.
Cuando el pago confirma, Stripe envía un evento checkout.session.completed (pago único) o invoice.paid (suscripción) al endpoint /api/webhooks/stripe. Ese endpoint verifica la firma, extrae el supabase_user_id del metadata, y actualiza la tabla profiles con el nuevo plan, límite de funciones y fecha de activación.
Si una suscripción se cancela, Stripe envía customer.subscription.deleted y el plan se revierte a free automáticamente, sin intervención manual.
Cada función tiene una cadena de recolección de evidencia específica y un skill diseñado por los especialistas de EGO. El modelo de lenguaje siempre recibe evidencia primero — no trabaja de memoria.
fn01 — Arquitectura del Sitio: scraping completo del HTML + robots.txt + sitemap.xml + subpáginas clave (/about, /contacto). El skill analiza la jerarquía de URLs, internal linking, profundidad de click, breadcrumbs, y construye una Nav Spec completa. Tiempo promedio: 60 segundos.
fn02 — SEO & Visibilidad: scraping HTML + Google PageSpeed Insights API (métricas reales de Google: LCP, CLS, FCP, TBT, scores 0-100) + Brave Search para señales off-page. El skill evalúa los cuatro pilares SEO con especial foco en E-E-A-T y Core Web Vitals certificados. Tiempo promedio: 65 segundos.
fn03 — UX & Usabilidad: scraping HTML + screenshot real via Firecrawl. Claude Vision analiza la imagen junto con la evidencia textual. El skill aplica las 10 heurísticas de Nielsen, evalúa arquitectura de información, jerarquía visual y experiencia mobile. Tiempo promedio: 60 segundos.
fn04 — CRO & Conversión: scraping HTML + screenshot + Brave Search para señales de reputación y contexto competitivo. El skill examina el funnel completo: messaging, CTAs, trust signals y friction points. Tiempo promedio: 60 segundos.
fn05 — Accesibilidad WCAG: scraping HTML + Lighthouse Accessibility Audit completo (powered by axe-core) en mobile y desktop simultáneamente. Claude recibe cada fallo con su ID exacto, el criterio WCAG violado, el nivel de impacto y los snippets HTML reales. El análisis se basa 100% en datos de axe-core — no hay estimaciones. Tiempo promedio: 160 segundos (el audit de Lighthouse requiere renderizado headless completo).
fn06 — Diagnóstico Técnico: scraping HTML + Google PageSpeed Insights + Brave Search para contexto de reputación técnica. El skill detecta el stack completo, audita headers de seguridad HTTP, evalúa deuda técnica con comparación de versiones, y produce un roadmap en tres fases. Tiempo promedio: 65 segundos.
fn07 — Social Listening & Sentiment: sin scraping de sitio propio — en cambio, 7 búsquedas paralelas via Brave Search API cubriendo opiniones, reseñas, Reddit, noticias, quejas, redes sociales y benchmark competitivo. Si la marca tiene presencia en redes, Apify puede complementar con datos de Instagram, TikTok, Twitter/X, LinkedIn y YouTube. El análisis trabaja sobre resultados reales y verificables. Tiempo promedio: 70 segundos.
fn08 — E-Com Optimization: scraping del homepage + scraping dedicado de una página de producto/categoría via Firecrawl + screenshot + Brave Search para contexto de mercado. El skill evalúa la ficha de producto, carrito y checkout, trust signals, urgencia y experiencia mobile con benchmarks específicos de e-commerce. Tiempo promedio: 60 segundos.
No guardamos el HTML scrapeado. La evidencia recolectada de cada sitio se usa para construir el prompt de Claude y se descarta inmediatamente. No se persiste ningún dato de sitios de terceros en nuestra base de datos.
No entrenamos modelos con tus datos. Los reportes que generás se guardan en tu cuenta únicamente para que puedas volver a consultarlos. No se usan para ningún tipo de fine-tuning ni entrenamiento.
No procesamos datos de tarjeta. Stripe es PCI DSS Level 1 certified. Los datos de pago nunca pasan por los servidores de Insights®.
No ejecutamos código arbitrario de sitios externos. El scraping extrae HTML y metadatos — no ejecuta JavaScript de terceros en nuestro entorno de servidor.
Todo lo anterior es la cocina visible: la infraestructura, los protocolos, los flujos. Pero hay una parte que no tiene diagrama posible.
Cada skill — cada conjunto de instrucciones que define cómo Claude analiza cada función — está escrito por alguien que pasó años haciéndolo a mano. Que sabe qué mirar primero en un sitio de e-commerce. Que sabe qué falla siempre en la accesibilidad de aplicaciones hechas con frameworks modernos. Que sabe la diferencia entre un problema de UX y un problema de negocio.
Eso no se documenta. Se acumula. Y es lo que diferencia un análisis de Insights® de un prompt genérico con el mismo modelo de lenguaje.
Mostramos la cocina porque confiamos en lo que cocinamos.
EGO Design — Insights® es un producto de EGO Design. Buenos Aires, Argentina.
Por Juan Julio Spinetto
La arquitectura de información es la decisión de diseño más invisible y más determinante que existe. Nadie la ve, pero todos la sienten. Cuando el usuario abandona a los 30 segundos sin saber bien por qué, generalmente es un problema de arquitectura. No de diseño visual. No de velocidad. De estructura.
En 15 años de consultoría, la primera hora de cualquier auditoría siempre fue la misma: mapear a mano cómo estaba organizado el sitio. Navegando, anotando, trazando el árbol de páginas en un documento o en una pizarra. Era trabajo tedioso pero necesario — sin ese mapa, el resto del análisis era especulación sobre síntomas en vez de diagnóstico de causas.
Uno de los proyectos que más me marcó fue una auditoría para una empresa de servicios financieros. El cliente nos decía que el sitio era claro. Que sus empleados lo navegaban sin problema. Que los clientes "ya sabían cómo funciona". Lo que no veían era que sus empleados llevaban años usando ese sitio y habían desarrollado un modelo mental que los usuarios nuevos nunca iban a construir en tres clics.
Cuando mapeamos la arquitectura real — no la del sitemap declarado, sino la que emergía de seguir los links — encontramos 14 secciones en el primer nivel de navegación, dos de las cuales tenían nombres que solo tenían sentido si ya sabías lo que había adentro. Eso es lo que yo llamo una arquitectura hecha para el organigrama, no para el usuario.
La estructura de navegación que tiene sentido para el equipo interno casi nunca es la misma que tiene sentido para quien llega por primera vez. Esa brecha es el problema más frecuente que encuentro, y también el más costoso, porque atraviesa todas las capas del producto.
Porque todo lo que viene después depende de ella. El SEO depende de la estructura de URLs y el internal linking. La conversión depende de si el usuario encuentra lo que busca antes de frustrarse. La accesibilidad depende de si la navegación es predecible. El rediseño visual fracasa si la arquitectura subyacente está rota — solo le pone maquillaje a un problema estructural.
Trabajé con clientes en retail, banca, automotriz y telco. En sectores tan distintos, el denominador común de los problemas de experiencia era casi siempre el mismo: estructura de información inconsistente, profundidad de navegación excesiva, secciones que existían por razones históricas que ya nadie recordaba pero que nadie se animaba a tocar.
Rediseñar sin auditar la arquitectura primero es como repintar una casa sin revisar los cimientos. El resultado se ve mejor. Dura menos.
Hay un concepto en arquitectura de información que se llama "information scent" — el rastro de señales que le indica al usuario si está yendo en la dirección correcta. Cuando ese rastro es claro, el usuario navega con confianza. Cuando es ambiguo, empieza a dudar, a hacer backtrack, a explorar sin dirección. Ese comportamiento es invisible en el diseño pero visible en las métricas: bounce rate alto, tiempo en sitio bajo, rutas de navegación erráticas en los heatmaps.
La función de arquitectura busca exactamente eso: verificar si el mapa mental que construye el usuario cuando navega coincide con lo que el negocio quiere que haga. La jerarquía real del sitio, no la que alguien dibujó en un Figma hace tres años. Los links que el usuario ve versus los que el sitio declara en el sitemap. Las páginas huérfanas que acumulan tráfico sin estar conectadas al flujo principal.
Hay un componente que empezó a importar en los últimos años y que los análisis tradicionales de arquitectura no contemplaban: la rastreabilidad para motores de IA. Los LLMs aprenden de sitios web. Los crawlers de Perplexity, ChatGPT Search, Claude.ai — todos necesitan poder leer y estructurar el contenido de un sitio. Si la arquitectura no es limpia, si los headings no tienen jerarquía, si el contenido está fragmentado en decenas de páginas sin contexto, el sitio no va a ser citado ni recuperado por estos sistemas.
Eso es AI Readiness. Y ya no es una consideración futura — es una ventaja competitiva presente para las marcas que lo entienden ahora.
Un análisis de arquitectura basado en datos del sitio no puede reemplazar el card sorting con usuarios reales ni el tree testing con prototipos. Esas metodologías validan hipótesis con comportamiento real. Lo que esta función hace es mapear el estado actual con precisión, identificar los problemas más evidentes, y proveer el punto de partida para esas validaciones posteriores. El diagnóstico antes del test. La radiografía antes de la cirugía.
Juan Julio Spinetto — Co-fundador EGO, especialista UX/CX y Service Design. 15 años diseñando experiencias digitales en retail, banca, automotriz y telco.
Por Juan Julio Spinetto
Durante años, el SEO y el diseño UX vivieron en mundos separados. El SEO era cosa de keywords y metadatos. El UX era cosa de flujos y usabilidad. En la práctica, esa separación costó proyectos enteros. Y costó clientes.
Me di cuenta de esto tarde, en un rediseño de e-commerce donde mejoramos significativamente la experiencia pero perdimos posicionamiento en el proceso. Habíamos cambiado URLs, reestructurado la jerarquía de headings, migrado la plataforma sin redirect mapping completo. El sitio era más usable, más rápido, más claro. Y Google tardó meses en volver a encontrarlo.
Ese proyecto cambió cómo trabajo. Antes del rediseño, el sitio posicionaba bien para sus términos principales. Después del rediseño, el tráfico orgánico cayó un 40% en los primeros 60 días. Las URLs habían cambiado sin redirects. Los H1s habían sido reemplazados por títulos más "creativos" que no contenían las keywords que el usuario buscaba. El sitemap nuevo tardó semanas en ser indexado.
El equipo de desarrollo no sabía de SEO. El equipo de SEO no estaba involucrado en el rediseño. Yo, como director de la experiencia, no había hecho la pregunta que tendría que haber hecho desde el día uno: ¿cómo afecta cada decisión de diseño a la rastreabilidad y al posicionamiento actual?
Desde ese momento, el análisis SEO es parte del diagnóstico inicial de cualquier proyecto. No al final. Al principio.
Empecé a ver el SEO de otra manera: no como una disciplina técnica aparte, sino como un sistema de señales sobre la calidad del diseño de información. Un sitio con buena arquitectura, contenido bien jerarquizado y performance sólida casi siempre tiene buen SEO. Porque Google aprendió a valorar exactamente lo mismo que valora un usuario: claridad, velocidad, relevancia.
Los Core Web Vitals son el ejemplo más concreto. LCP, CLS, FCP, TBT — son métricas de experiencia de usuario que Google convirtió en señales directas de ranking. La performance es UX. El SEO y el diseño convergieron al mismo lugar desde caminos distintos, y ese punto de encuentro es donde se juegan muchas de las decisiones que más impacto tienen.
Un sitio que carga en 4 segundos no es solo una mala experiencia de usuario. Es un sitio que Google está penalizando en silencio.
Experience, Expertise, Authoritativeness, Trust. Google definió el E-E-A-T para evaluar la calidad del contenido, pero en realidad es una descripción bastante precisa de lo que debería transmitir cualquier sitio de negocio bien diseñado. ¿Se entiende quién está detrás? ¿Hay señales de autoridad verificables? ¿El contenido demuestra conocimiento real del tema o es copy genérico que podría ser de cualquier competidor?
Esas son preguntas de diseño de contenido, no de SEO técnico. Y el diseñador que las ignora está dejando una parte importante del trabajo a medias.
Esta función analiza el SEO en cuatro dimensiones: técnico (rastreabilidad, indexación, performance), contenido (relevancia, estructura, densidad, jerarquía de headings), autoridad (señales off-page, menciones, E-E-A-T verificable), y experiencia (Core Web Vitals reales, mobile, UX signals). No son dimensiones independientes — se potencian o se cancelan entre sí.
Un sitio con contenido excelente pero performance técnica deficiente no va a posicionar tan bien como podría. Un sitio técnicamente impecable con contenido genérico tampoco. El SEO es un sistema. El análisis tiene que ser sistémico.
Este análisis no tiene acceso a Search Console ni a Google Analytics. No puede ver el volumen de búsquedas reales, las posiciones exactas, ni el tráfico histórico. Lo que sí puede hacer es evaluar el estado técnico y de contenido del sitio con datos reales — y señalar los problemas que esos datos confirmarían si estuvieran disponibles. Es el diagnóstico del especialista antes de ver los laboratorios. No los reemplaza, pero orienta qué pedir y dónde mirar.
Juan Julio Spinetto — Co-fundador EGO, especialista UX/CX y Service Design. 15 años diseñando experiencias digitales en retail, banca, automotriz y telco.
Por Juan Julio Spinetto
Hay una distinción que aprendí a fuerza de proyectos: usabilidad y experiencia de usuario no son lo mismo. Un sitio puede ser perfectamente usable — claro, predecible, sin fricción — y aun así dejar al usuario con una sensación de indiferencia total. La usabilidad es el mínimo necesario. La experiencia es lo que queda después de que el mínimo está resuelto.
Pero la usabilidad tiene que estar primero. Sin ella, nada de lo que viene después funciona como debería.
Jakob Nielsen publicó las 10 heurísticas de usabilidad en 1994. Más de 30 años después, siguen siendo el marco de referencia más útil que existe para evaluar una interfaz. No porque el diseño no haya evolucionado — sino porque los problemas fundamentales de usabilidad son mayormente los mismos: visibilidad del estado del sistema, consistencia interna, prevención de errores, control del usuario sobre el flujo.
En EGO las usamos como punto de partida de cada auditoría. No como checklist que se llena y se archiva, sino como lenguaje compartido entre disciplinas. Cuando digo "problema de visibilidad del estado del sistema", cualquier persona en la sala sabe exactamente a qué me refiero, aunque no sea diseñadora. Cuando digo "falta de consistencia entre módulos", el equipo de desarrollo entiende qué hay que corregir sin necesitar otra reunión de alineamiento.
Ese lenguaje compartido es subestimado. En proyectos grandes, con equipos multidisciplinarios, la mayoría de los problemas de ejecución vienen de definiciones distintas del mismo concepto. Las heurísticas cortan esa ambigüedad.
Si tuviera que elegir la heurística que más se incumple en los proyectos que audito, elegiría consistencia. No porque los equipos no la conozcan — sino porque los sitios crecen orgánicamente, por capas, a lo largo de años, con equipos distintos, a veces con agencias distintas para secciones distintas. El resultado es una interfaz donde el mismo elemento se llama de tres formas diferentes, los patrones de formulario cambian entre páginas, y la jerarquía tipográfica no es la misma en todos los módulos.
Ese nivel de inconsistencia es invisible para quien lo construyó. Es perfectamente visible para quien llega por primera vez.
Trabajar con un screenshot real del sitio cambia el análisis. La jerarquía visual no se puede evaluar solo desde la estructura del código — hay que ver el above-the-fold, entender qué ve el usuario en los primeros tres segundos, detectar si el CTA principal compite visualmente con elementos secundarios, si la densidad de información en mobile es manejable o abrumadora.
El ojo del diseñador lee cosas que los datos no capturan. La sensación de marca que transmite un sistema tipográfico. La tensión visual entre dos elementos que pelean por atención. La coherencia — o la falta de ella — entre el diseño y lo que la marca quiere comunicar. Esas lecturas requieren criterio visual, no solo estructura.
Esta función combina las dos lecturas: la estructural (datos del sitio, navegación, forms, headings, signales técnicas) y la visual (screenshot real analizado como lo haría un diseñador senior evaluando un portfolio). El resultado es más completo que cualquiera de las dos por separado, y más honesto que una evaluación hecha solo desde adentro del proyecto.
Hay algo que siempre les digo a los equipos con los que trabajo: el análisis te dice qué hay. El diagnóstico te dice qué importa y por qué. Esta función provee el primero con una profundidad que tomaría horas hacer manualmente — jerarquía de navegación, estructura de contenidos, señales de accesibilidad, performance mobile, consistencia visual.
El diagnóstico — saber qué de todo eso es prioritario para este negocio específico, en este momento específico — sigue siendo tuyo. Y ese es exactamente el punto.
Juan Julio Spinetto — Co-fundador EGO, especialista UX/CX y Service Design. 15 años diseñando experiencias digitales en retail, banca, automotriz y telco.
Por Juan Julio Spinetto
Hay una trampa en la que caen muchos proyectos de diseño: la del sitio hermoso que no convierte. Todo está bien ejecutado — la tipografía, los colores, el sistema de grilla, las animaciones. El cliente está orgulloso del resultado. El equipo también. Y los números de conversión no se mueven.
El diseño visual no es suficiente. La conversión tiene su propia lógica, y es implacable.
Después de años auditando sitios de retail, banca y servicios, llegué a una conclusión que parece simple pero que cuesta mucho dinero ignorar: la gente convierte cuando llega al momento de decisión con las dudas resueltas. No antes. Si el CTA más importante aparece antes de que el usuario entienda el valor, no funciona. Si el precio de envío aparece recién en el checkout, una parte importante de los usuarios ya tomó la decisión de no comprar dos pantallas antes.
El trabajo de CRO es ingeniería de contexto. Cada elemento de la página construye o destruye la confianza que hace posible la acción final. El headline que aclara qué hace el producto y para quién. La prueba social que valida que otros ya tomaron esa decisión. La información de garantía que elimina el riesgo percibido. El precio presentado de forma que se entienda sin esfuerzo. Todo contribuye — o todo distrae.
La conversión no se gana en el botón. Se gana o se pierde en los diez segundos anteriores.
La mayoría de los análisis de conversión se enfocan en los botones. Color, tamaño, texto, posición. En mi experiencia, el problema rara vez está en el botón. El botón es el síntoma. El problema está en lo que pasó antes.
Un formulario con ocho campos cuando podrían ser tres. Una propuesta de valor que suena igual a la de todos los competidores. Trust signals ausentes en el momento en que el usuario más los necesita — justo antes de hacer click. Señales de urgencia que se ven fabricadas y que producen el efecto contrario al buscado. Una jerarquía de precios que no guía la decisión sino que la complica.
Esta función evalúa el funnel completo desde arriba: el mensaje, la propuesta de valor, los trust signals, las señales de urgencia, la estructura del checkout, los formularios. No solo el punto de conversión. Porque si llegás al botón con las dudas sin resolver, el color del botón no va a hacer la diferencia.
Una de las cosas más difíciles en CRO es mantener la perspectiva de usuario nuevo. Los equipos que trabajan con un sitio todos los días desarrollan una familiaridad que los vuelve ciegos a problemas obvios. El headline que "siempre estuvo ahí" y que nunca nadie cuestionó. La landing que el equipo de marketing considera clara y que un usuario nuevo no entiende en los primeros cinco segundos.
El análisis externo rompe esa inercia. No porque sea infalible, sino porque llega sin contexto previo — exactamente como llega el usuario.
Lo que esta función no puede hacer es reemplazar los datos reales de comportamiento. No tiene acceso a Google Analytics, heatmaps, grabaciones de sesión ni test A/B históricos. Lo que sí puede hacer es identificar los problemas estructurales que esos datos confirmarían — y señalar dónde mirar primero cuando se tengan. Es el diagnóstico experto antes de la instrumentación. No la reemplaza. La antecede.
Juan Julio Spinetto — Co-fundador EGO, especialista UX/CX y Service Design. 15 años diseñando experiencias digitales en retail, banca, automotriz y telco.
Por Juan Julio Spinetto
Fui jurado en Awwwards durante años. Vi sitios extraordinarios — composición impecable, animaciones sofisticadas, tipografía al milímetro, dirección de arte que te detenía. Y vi cómo muchos de esos mismos sitios fallaban en cosas que cualquier usuario con discapacidad visual encontraría inusable en los primeros treinta segundos.
El contraste insuficiente no es un detalle estético. Es una barrera de acceso. Y la cantidad de sitios premiados que tienen ese problema es incómoda.
La narrativa dominante trata la accesibilidad como un requerimiento legal o técnico. Algo que se verifica al final del proyecto, se reporta en un documento y se pasa a los devs para que lo arreglen. Eso es exactamente lo que hace que los problemas se acumulen durante años y nunca se salden del todo — porque corrergirlos a posteriori es caro, técnicamente complejo y políticamente difícil de priorizar.
La accesibilidad debería ser una consecuencia natural de diseñar bien desde el principio. El contraste de colores se define en el sistema de diseño, no en la auditoría final. La jerarquía semántica de headings se define en la arquitectura de contenidos. Los labels de formularios se definen cuando se diseñan los formularios, no cuando llega el informe de compliance. Si esas decisiones no se toman bien en origen, el costo de corregirlas es diez veces mayor — y la experiencia del usuario sufre en el proceso.
Hay un principio en diseño universal que me parece uno de los más poderosos: lo que resuelve un problema para un usuario con discapacidad, generalmente mejora la experiencia de todos los demás. El captioning de videos fue diseñado para usuarios sordos — hoy lo usa todo el mundo que ve video en transporte público. El contraste alto fue diseñado para usuarios con visión reducida — hoy es más legible para todos en pantallas bajo luz directa. Los formularios con labels claros fueron diseñados para usuarios con discapacidades cognitivas — hoy reducen el error de formulario en todos los usuarios.
La accesibilidad no es un costo. Es un estándar de calidad.
Esta función no hace estimaciones ni inferencias sobre posibles problemas. Ejecuta una auditoría real de Lighthouse powered by axe-core — exactamente la misma herramienta que usa Google Chrome DevTools para evaluar accesibilidad. Cada fallo que reporta tiene un ID de audit específico, el criterio WCAG que viola, el nivel de impacto (crítico / serio / moderado), y los selectores CSS o fragmentos HTML exactos que fallan.
No es "podría haber problemas de contraste". Es "hay 7 elementos que violan WCAG 1.4.3 AA con ratio inferior a 4.5:1, en los siguientes selectores". Esa especificidad es lo que convierte el diagnóstico en tarea accionable.
La auditoría automatizada captura alrededor del 30-40% de los problemas de accesibilidad reales. El resto requiere testing con tecnologías asistivas genuinas — lectores de pantalla como NVDA o VoiceOver, navegación exclusiva por teclado, software de magnificación, switches de acceso. Esa parte siempre va a requerir usuarios reales con necesidades reales, y criterio humano para interpretar la experiencia.
Lo que esta función hace es resolver el 30-40% verificable de forma sistemática y con evidencia técnica sólida, y señalar claramente cuáles son los criterios que requieren validación adicional con usuarios. No es la solución completa — pero es el punto de partida correcto para cualquier organización que quiera tomarse la accesibilidad en serio.
Juan Julio Spinetto — Co-fundador EGO, especialista UX/CX y Service Design. 15 años diseñando experiencias digitales en retail, banca, automotriz y telco.
Por Juan Julio Spinetto
No soy developer. Nunca lo fui, y no pretendo serlo. Pero aprendí, por las malas en más de un proyecto, que ignorar el estado técnico de un sitio cuando se toman decisiones de diseño es un error que se paga caro. Muy caro. Y generalmente lo paga el cliente, no el equipo que tomó la decisión.
El diseño vive encima de la infraestructura. Si la infraestructura tiene deuda, el diseño tiene límites que nadie nombró en el brief.
En un proyecto de rediseño para un cliente de retail, el equipo creativo propusimos una experiencia visual ambiciosa — animaciones de scroll, carga progresiva de imágenes de alta resolución, transiciones entre secciones. El cliente aprobó el concepto. La producción empezó. Y el equipo técnico tardó semanas en entregar lo que debería haber sido una implementación de días.
El problema no era la complejidad de lo que pedíamos. Era la deuda técnica acumulada en la plataforma: librerías de frontend desactualizadas que no soportaban las APIs modernas, scripts bloqueantes heredados de integraciones que nadie recordaba haber pedido, una arquitectura que nadie había tocado en tres años porque "estaba funcionando". Todo eso era invisible para nosotros en el brief. Visible — y costoso — en la implementación.
Si hubiéramos hecho el diagnóstico técnico antes del concepto creativo, habríamos propuesto algo diferente. O habríamos incluido la regularización de deuda como parte del scope del proyecto, con presupuesto y tiempo propios. En cambio, lo descubrimos cuando ya había compromisos tomados.
El stack tecnológico de un sitio dice mucho sobre las decisiones que tomó la organización en los últimos años. Un WordPress con 47 plugins activos habla de una historia de soluciones rápidas apiladas unas sobre otras. Un Shopify con un tema pesadamente customizado habla de un equipo que llegó al límite de la plataforma sin migrar. Un Next.js con versión desactualizada habla de deuda de mantenimiento que nadie presupuestó.
Esas señales no son juicios — son contexto necesario para tomar decisiones de diseño informadas. Esta función detecta el stack completo: framework front-end, CMS o plataforma, infraestructura de hosting y CDN, herramientas de analytics y tracking, versiones de librerías y su distancia de la versión actual.
Los headers de seguridad HTTP son uno de los indicadores más reveladores del estado técnico de un sitio, y también uno de los más ignorados. HTTPS activo, HSTS configurado, Content Security Policy declarada, X-Frame-Options presente — esas configuraciones no las instala solo el que sabe de seguridad. Las instala el equipo que tiene criterio sobre cómo manejar su infraestructura.
Un sitio sin esas protecciones básicas no es necesariamente un sitio inseguro. Es un sitio donde nadie se hizo la pregunta. Y eso dice algo sobre los procesos de ese equipo.
No es un reporte solo para el CTO. Es información que necesita cualquier persona que va a tomar decisiones de diseño, de negocio o de inversión sobre ese sitio.
La deuda técnica no es un problema técnico. Es una decisión de negocio diferida. Cada vez que se elige la solución rápida sobre la correcta — el parche sobre la refactorización, el plugin sobre la integración nativa, la customización excesiva sobre la migración de plataforma — se acumula interés. En algún punto esa deuda se convierte en el techo de todo lo demás: de lo que el equipo puede construir, de la velocidad con que puede iterar, del tipo de experiencia que puede ofrecer.
Nombrarla, cuantificarla y priorizarla en un roadmap con impacto de negocio es el primer paso para saldarla. Esta función lo hace posible sin necesitar acceso al código fuente ni a la arquitectura interna — solo al comportamiento observable del sitio desde afuera.
Juan Julio Spinetto — Co-fundador EGO, especialista UX/CX y Service Design. 15 años diseñando experiencias digitales en retail, banca, automotriz y telco.
Por Juan Julio Spinetto
Hay algo que siempre me pregunté antes de empezar un proyecto: qué dice la gente sobre esta marca cuando no le pregunta nadie. No en una encuesta con moderador. No en un focus group donde todo el mundo tiende a ser más amable de lo que realmente piensa. En Reddit, en Google Reviews, en Twitter, en foros de nicho donde la gente habla con franqueza porque siente que nadie del negocio los está escuchando.
Esa conversación existe siempre. Y casi nunca está en el brief.
Los briefs de proyecto incluyen arquetipos de usuario construidos en workshops internos, datos de mercado de informes sectoriales, benchmarks de competidores seleccionados cuidadosamente. Casi nunca incluyen una lectura honesta de la percepción externa real de la marca. El cliente sabe perfectamente cómo se ve a sí mismo. No siempre sabe — o no siempre quiere saber — cómo lo ven los demás.
Ese gap entre la identidad proyectada y la percepción real es donde viven los problemas de diseño más difíciles de diagnosticar. Una marca puede tener un sitio técnicamente impecable, bien diseñado, con buen SEO y buenas métricas de performance — y aun así tener una percepción de marca que el diseño no puede resolver por sí solo. Si no lo sabés de entrada, vas a diseñar para una imagen que no corresponde con la realidad que el usuario trae consigo antes de ver la primera pantalla.
Las encuestas tienen un problema estructural: la gente tiende a ser más amable cuando alguien le pregunta directamente. Y cuando la pregunta la hace la marca sobre sí misma, el sesgo de respuesta social es aún más pronunciado. Reddit, Google Reviews, foros especializados, comentarios en YouTube — ahí la gente dice lo que realmente piensa, porque siente que no hay consecuencias y que está hablando con sus pares, no con el negocio.
Esa conversación espontánea es cualitativamente distinta a cualquier dato de encuesta. Es más honesta. Es más específica. Y es extraordinariamente útil para diseñar.
¿Qué repite la gente cuando habla mal de esta marca? ¿Qué elogia cuando habla bien? ¿Qué pregunta antes de decidir? Esas respuestas deberían informar la arquitectura de contenidos, el tono del copy, los trust signals que se priorizan y los objections que hay que resolver en el flujo.
El Social Listening invierte la dirección habitual del diseño. En lugar de partir del posicionamiento interno de la marca y proyectarlo hacia afuera, parte de lo que ya existe en el exterior — la percepción real, los arquetipos de usuario que emergen de conversaciones reales, las emociones que la marca despierta sin intentarlo — y trabaja hacia adentro para que el diseño sea coherente con esa realidad.
Eso cambia decisiones concretas. Si la percepción dominante de una marca de servicios financieros es "impersonal y difícil de entender", el trabajo de diseño no es solo simplificar la interfaz — es trabajar el tono, la terminología, los puntos de contacto humano dentro del flujo digital. Si la percepción de una marca de moda es "cara pero vale la pena", el diseño debería reforzar esa ecuación de valor en cada punto del funnel, no neutralizarla.
Esta función trabaja con evidencia real de búsquedas web en tiempo real: menciones verificables, URLs reales, conversaciones que están pasando ahora. No es una proyección estadística ni una estimación basada en modelos. Es lo que hay disponible públicamente sobre esa marca en internet, analizado con criterio experto.
A veces hay mucho. A veces hay poco. Una marca nueva en un mercado chico puede tener muy pocas menciones orgánicas. Eso también dice algo — sobre su presencia digital, sobre su nivel de reconocimiento, sobre cuánto trabajo de awareness hay por delante. La ausencia de señal es una señal.
Juan Julio Spinetto — Co-fundador EGO, especialista UX/CX y Service Design. 15 años diseñando experiencias digitales en retail, banca, automotriz y telco.
Por Juan Julio Spinetto
El e-commerce es el entorno más honesto del diseño. Cada decisión tiene una consecuencia medible, a veces en cuestión de horas. El texto del botón, el orden de las imágenes del producto, el momento exacto en que aparece el precio de envío, la cantidad de campos en el formulario de checkout — todo se puede medir. Y todo importa más de lo que parece.
Es el único contexto en que el diseñador recibe feedback cuantitativo casi inmediato de sus decisiones. Eso es una responsabilidad y una oportunidad al mismo tiempo.
Trabajé con clientes de retail en proyectos que iban desde rediseños completos de plataforma hasta optimizaciones puntuales de la ficha de producto. Lo que más me sorprendió siempre — y sigue sorprendiéndome — fue la diferencia entre lo que el equipo interno creía que era el problema y lo que los datos realmente mostraban.
"Necesitamos más tráfico" — pero el verdadero problema era un 78% de abandono en el checkout, y el tráfico nuevo iba a abandonar por las mismas razones que el tráfico actual. "Necesitamos mejores fotos de producto" — pero el verdadero problema era que el precio de envío aparecía recién en el paso 3 del checkout, cuando el usuario ya había invertido tiempo y expectativa en el proceso. "El diseño está desactualizado y por eso no vendemos" — pero el verdadero problema era que el guest checkout no existía y la creación de cuenta era obligatoria antes de poder comprar.
El diagnóstico precede al rediseño. Siempre. Sin él, el rediseño es una apuesta, no una decisión.
De todas las etapas del funnel de e-commerce, el checkout es donde más conversión se pierde y donde más se puede ganar con cambios relativamente simples. Un proceso de más de tres pasos sin progress indicator pierde usuarios. La ausencia de opciones de pago locales (en Latinoamérica, la falta de cuotas sin interés es un friction point enorme) puede hacer irrelevante todo lo que pasó antes. La obligatoriedad de crear cuenta antes de comprar históricamente genera abandonos de entre el 20 y el 35%.
Estos son problemas conocidos, con soluciones conocidas. Lo que esta función hace es verificar si existen en cada sitio específico — con evidencia real del carrito y del checkout, no con suposiciones genéricas.
La conversión en e-commerce no se decide en un solo momento. Se construye desde el catálogo — ¿los filtros permiten llegar al producto correcto sin fricción? —, se consolida en la ficha de producto — ¿la información necesaria para decidir está disponible sin necesitar scroll excesivo? —, se pone a prueba en el carrito — ¿el resumen es claro y permite editar sin perder el proceso? —, y se gana o se pierde en el checkout.
Un análisis que solo mira la ficha de producto pierde la mitad del problema. Esta función analiza todo el recorrido como un sistema integrado. Porque el abandono en el carrito no siempre es un problema del carrito — a veces es la consecuencia de información insuficiente que vino desde la ficha, o de una expectativa de precio de envío que se rompe en el último paso.
En la mayoría de las categorías de e-commerce, más del 60% del tráfico viene de dispositivos móviles. Y la tasa de conversión mobile sigue siendo significativamente más baja que desktop en la mayoría de los sitios — no porque los usuarios mobile compren menos, sino porque la experiencia de compra en mobile todavía es peor en la mayoría de los casos.
Touch targets demasiado pequeños. Teclados numéricos que no se abren para el campo de tarjeta. Imágenes de producto que no soportan zoom en touch. Formularios que no utilizan autofill. Botones de checkout que no son sticky al hacer scroll en la ficha. Cada uno de esos problemas tiene una solución concreta. Y cada uno de esos problemas cuesta conversión todos los días.
El e-commerce tiene estándares globales consolidados: tasas de conversión promedio por industria y categoría, mejores prácticas en ficha de producto, patrones de checkout que minimizan abandono, niveles de social proof que correlacionan con conversión. Esos benchmarks son el contexto que le da escala a los hallazgos — no para perseguir un número ideal, sino para entender dónde está el negocio en relación con lo que se considera razonable en su categoría. La diferencia entre un 1.2% de conversión y un 2.8% en la misma industria es el tipo de información que justifica el análisis por sí sola.
Juan Julio Spinetto — Co-fundador EGO, especialista UX/CX y Service Design. 15 años diseñando experiencias digitales en retail, banca, automotriz y telco.
Para acceder al contenido tenés que iniciar sesión
Inicia sesiónKitchen es para usuarios registrados
Creá tu cuenta gratis para acceder a métodos, modelos y principios de diseño curados — y descubrir qué hacer después de tu próximo reporte.
Ingresá o registratePlan requerido
Para ejecutar funciones de análisis necesitás un plan activo.
¿Tenés preguntas?
Dejanos tu consulta y te respondemos a la brevedad
¡Gracias!
Recibimos tu consulta. Te contactaremos pronto.
Usamos Google Analytics para entender cómo se usa el producto. Podés aceptar o rechazar el seguimiento. Política de privacidad
Ingresá el email con el que te registraste y te enviamos un link para restablecer tu contraseña.
Te enviamos un link a para restablecer tu contraseña.
Si no lo encontrás, revisá la carpeta de spam.
✓ Por registrarte te damos un análisis gratis
Te enviamos un link de confirmación a . Hacé click en el link para activar tu cuenta.
Si no lo encontrás, revisá la carpeta de spam.
Mínimo 8 caracteres.
Ya podés ingresar a tu cuenta con tu nueva contraseña.