Product designer ( ux ui) — Ciudad de Mexico
Actualmente dando forma a la experiencia de streaming musical en Claro Música para más de 10M de usuarios en LATAM.
Diseñé la interfaz nativa de Claro Música para Android Automotive OS: una app independiente en dashboard donde cada decisión impacta seguridad real.
Diseñé la interfaz nativa de Claro Música para el dashboard del vehículo. Sin teléfono, sin espejo. Una app independiente donde cada decisión de diseño tiene implicaciones de seguridad real.
Claro Música ya vivía en Android Auto, donde la app se espeja desde el teléfono. El nuevo proyecto fue distinto: llevar Claro Música a Android Automotive OS, integrado al sistema nativo del vehículo con Google Automotive Services.
La app se espejaba desde el teléfono. Sin diseño específico para el vehículo. Sin integración nativa con el sistema.
Corriendo en el OS del vehículo. El teléfono puede no estar presente. La sesión y el estado viven en el auto.
Eso significaba diseñar desde cero 11 pantallas para un contexto donde el usuario tiene las manos en el volante y los ojos en la carretera.
Antes de bocetar una sola pantalla, necesitaba entender qué significa realmente interactuar con un dashboard mientras se conduce. Este contexto de usuario era fundamentalmente distinto a cualquier cosa en el producto móvil de Claro Música.
Problema central: Los usuarios de Claro Música en el auto necesitan controlar su experiencia musical con atención visual mínima — pero la app existente en Android Auto era un espejo del teléfono sin ningún diseño consciente de la seguridad, haciendo imposible el uso sin distracción.
Del research salieron tres principios de diseño. No eran aspiracionales: eran restricciones que sobrepasaban cualquier solicitud de stakeholder que los contradijera.
Cada desafío mayor de diseño tuvo múltiples enfoques viables. Los exploré mediante bocetos y flujos de baja fidelidad antes de converger en una dirección.
Opción 1 — Email + contraseña: Port directo desde móvil. Descartada porque requiere teclado completo en el dashboard, creando una interacción peligrosa en el momento de setup.
Opción 2 — Auto-login desde teléfono vinculado: Más simple técnicamente, pero rompe la premisa de independencia de AAOS — el teléfono puede no estar presente.
Opción 3 — QR + código numérico de 6 dígitos: Elegida. Cero teclado en el dashboard. El pad numérico ya estaba validado como patrón de baja distracción en la experiencia de Claro Música para Smart TV.
Opción 1 — Replicar densidad móvil: La petición inicial de Marketing. Múltiples tipos de contenido, alta densidad de información por pantalla. Descartada porque violaba la regla de los 2 segundos — demasiadas decisiones visuales por vistazo.
Opción 2 — Carruseles paginados con límites estrictos: Elegida. Cuatro filas de carruseles, máximo 8 elementos por fila. Cada fila responde a una sola intención (recientes, personalizado, top, nuevos). El costo cognitivo por vistazo se reduce a una decisión.
Opción 1 — Scroll libre: Preferencia de Desarrollo por consistencia con móvil y menor complejidad de implementación.
Opción 2 — Paginación fija: Elegida. El movimiento del vehículo genera microvibraciones que incrementan la activación accidental del scroll libre. La paginación hace que cada gesto de navegación sea intencional y discreto.
Pruebas remotas de usabilidad simulando condiciones de conducción. El tiempo de completación se usó como proxy de carga cognitiva — menos tiempo significa menos atención visual requerida.
| Tarea | Escenario | Tiempo promedio | Resultado |
|---|---|---|---|
| T1 | Reproducir contenido desde historial | ~3.1s | Por debajo del umbral de 5s ✓ |
| T2 | Encontrar y reproducir por género | ~5.4s | Único caso sobre el umbral — derivó a priorizar carruseles sobre búsqueda |
| T3 | Reproducir contenido descargado offline | ~4.1s | Por debajo del umbral ✓ |
El resultado de T2 impactó directamente la arquitectura final del home: la búsqueda fue deprioritizada visualmente en favor de carruseles personalizados, que servían la navegación por género más rápido a través de filas precuradas.
El usuario entra por login QR, aterriza en home con carruseles paginados y navega sin perder control de reproducción gracias al miniplayer persistente.
En automotive, las decisiones de diseño tienen implicaciones de seguridad que la mayoría de productos digitales no tienen. Eso generó fricción real — y requirió evidencia, no opiniones, para resolverse.
Postura del stakeholder: El equipo de Backend prefería adaptar email + contraseña. Menor esfuerzo de desarrollo, consistente con la infraestructura de auth existente.
Postura de Diseño: Cualquier login que requiera teclado completo en el dashboard es un riesgo de seguridad vial. La interacción es demasiado compleja incluso en un vehículo estacionado.
Resolución: QR + código de 6 dígitos. Referencié la implementación de Smart TV ya en producción — el mismo equipo ya había construido el backend para ese flujo. Costo: un endpoint adicional de generación de QR. Beneficio: cero interacción con teclado en el dashboard.
Postura del stakeholder: Desarrollo empujó por scroll libre — consistente con móvil, menor esfuerzo de implementación, más fácil de mantener.
Postura de Diseño: La vibración del vehículo genera activaciones accidentales del scroll. El scroll libre en movimiento es impredecible e incrementa el misclick.
Resolución: Test en Maze con ambos patrones. 25% de misclick con scroll libre vs 7% con paginación fija. Los datos cerraron el debate sin necesitar autoridad organizacional para resolver el desacuerdo.
Postura del stakeholder: Marketing quería replicar la densidad móvil — más contenido visible, más descubrimiento, más señales de engagement.
Postura de Diseño: Alta densidad en un dashboard viola la regla de los 2 segundos. Más contenido por vista significa más decisiones por vistazo, lo que implica más tiempo con los ojos fuera de la carretera.
Resolución: 4 filas de carruseles, máximo 8 elementos por fila. La restricción se enmarcó como una ventaja — el contenido curado tiene mejor rendimiento que el contenido denso en contextos de baja atención.
Postura del stakeholder: Producto propuso mostrar estados vacíos sin redirección explícita — más simple de construir, UX aceptable según estándares móviles.
Postura de Diseño: En el auto, un callejón sin salida es peor que en móvil — el usuario no puede recuperarse fácilmente sin desviar atención significativa. Cada estado vacío necesita un camino claro hacia adelante.
Resolución: Tres estados visuales diseñados (disponible, descargando, offline listo) con redirección consistente a Descargas desde cualquier sección vacía. Costo: 3 variantes de estado adicionales por sección. Beneficio: sin callejones sin salida en ninguna condición de red.
Diseñar para automotive no es adaptar móvil con botones más grandes: es un paradigma donde seguridad y contexto son constraints primarios. Cada decisión de pantalla tiene un peso que no existe en otros productos digitales.
Las decisiones más fuertes se cerraron con datos. La intuición señaló el problema, pero la evidencia de pruebas resolvió los debates con stakeholders — eliminando la necesidad de autoridad organizacional para resolver desacuerdos de diseño.
Para la siguiente iteración, la oportunidad más clara es profundizar comandos de voz con Google Assistant para reducir la interacción visual a casi cero en las acciones más frecuentes.
Rediseñé la landing de suscripción premium de Claro Música en un flujo mobile-first para reducir fricción en 18 mercados de LATAM.
Cómo transformé una página de ventas confusa y orientada a desktop en un flujo de suscripción mobile-first con mejora real en conversión en 18 mercados de LATAM.
Antes de proponer cualquier solución, necesitaba entender la fricción real — no asumirla. Los datos pintaron un cuadro claro de un producto desalineado con cómo llegaban sus usuarios.
Problema central: Los usuarios mobile que llegan a la landing de suscripción de Claro Música no pueden entender la diferencia entre planes ni confiar en la oferta de prueba — porque la página obliga a tomar decisiones paralelas en una sola vista diseñada para desktop, generando abandono antes de cualquier compromiso.
Dos causas raíz emergieron del research:
Mostrar múltiples planes lado a lado requiere comparación activa. En mobile, esto genera indecisión — los usuarios se bloquean en lugar de decidir.
El mensaje de prueba inconsistente ("1 mes" vs "1 semana") creaba la percepción de condiciones ocultas, generando abandono antes de la validación del número.
Hice una fase corta de ideación con el PM y un desarrollador para explorar soluciones arquitectónicamente distintas antes de prototipar. El objetivo era encontrar una estructura que redujera la carga cognitiva en el momento de decisión.
Mejorar jerarquía, tipografía y peso del CTA en la estructura de página única existente. Más rápido de construir, sin cambios estructurales.
Por qué se descartó: El problema era el modelo de decisión paralela en sí, no la ejecución visual. Pulir el layout no resolvería el patrón de indecisión confirmado en las grabaciones.
Cada plan tiene su propia pantalla completa. El usuario selecciona una pestaña y ve un plan en contexto completo — precio, beneficios, condiciones de prueba — sin competencia visual de otras opciones.
Por qué se eligió: Elimina la parálisis por comparación. Cada pantalla hace una sola cosa. El compromiso secuencial reemplaza la selección paralela.
Un flujo guiado que hace una pregunta a la vez: número de usuarios → preferencia de duración → plan. Reduce carga cognitiva por paso.
Por qué se descartó: Añade pasos para usuarios que ya saben lo que quieren. Alta fricción de reentrada para usuarios que comparan planes. También requiere más lógica de backend para reconstruir la intención entre pasos.
Trabajé en ciclos cortos de divergencia-convergencia con PM y desarrollo. Cada ronda tenía una hipótesis específica que validar, no solo usabilidad general.
El plan Familiar tuvo el mayor salto relativo (+51%), probablemente porque la arquitectura por tabs lo convirtió en una opción visible y de primer nivel, en lugar de una elección secundaria enterrada debajo del pliegue.
El objetivo era conversión calificada, no conversión máxima. Algunos constraints mejoraban la confiabilidad del cobro y el control de fraude de maneras que importaban más que reducir el abandono marginal.
Postura del stakeholder: PM y algunos stakeholders presionaron para eliminar la verificación SMS y reducir el abandono en ese paso. Un flujo solo por email o de un clic sería más simple.
Postura de Diseño + Negocio: La activación dependía de validar la titularidad de línea Claro/Telcel para el billing integrado con el carrier. Eliminar el SMS rompería el modelo de cobro, no solo simplificaría el flujo.
Costo aceptado: ~3% más de abandono frente a un flujo solo por email.
Mitigación: Copy clara, temporizador de cuenta regresiva y prellenado del número para usuarios recurrentes redujeron la ansiedad sin eliminar la verificación.
Postura del stakeholder: Los equipos regionales en otros países de LATAM querían un lanzamiento simultáneo para capturar resultados en todos los mercados a la vez.
Postura de Diseño: Los patrones de confianza y las expectativas de onboarding varían por país. Lanzar en todos los mercados a la vez significaba no poder reaccionar a fricción específica antes de que afectara volúmenes grandes.
Resolución: México primero con expansión por fases. Monitoreo por país y ajustes de copy local antes de que cada mercado entrara en producción.
Restricción: Los plazos de entrega ajustados hicieron impracticable el testing exhaustivo de conectividad en las primeras rondas.
Costo aceptado: Posible experiencia degradada en regiones de menor ancho de banda durante el lanzamiento inicial.
Mitigación: Plan de progressive enhancement definido antes del lanzamiento — assets más ligeros, lazy-loading y priorización de CSS crítico — para aplicarse antes de la expansión al resto de LATAM.
Este proyecto reforzó que los problemas de conversión suelen ser arquitectónicos, no visuales. En mobile, las elecciones paralelas generan indecisión; las elecciones secuenciales generan impulso. El fix no era mejor diseño — era una estructura diferente.
Si lo repitiera, involucraría al equipo de soporte desde el inicio. Los tickets relacionados con cobros resultaron ser la señal más rápida para decisiones de microcopy de confianza — información que estaba disponible pero no estaba en el proceso de diseño.
Diseñé una herramienta de gestión para Felpuditos MX que centraliza cotización, órdenes, clientes y configuración financiera en un solo sistema.
Diseñé una herramienta desde cero para Felpuditos MX, centralizando cotización, seguimiento de órdenes, gestión de clientes y configuración financiera en un sistema cohesivo.
Las fundadoras de Felpuditos eran también las usuarias finales. Eso me dio acceso directo a su trabajo real — no a una descripción de él. Realicé sesiones de shadowing observando toda su operación diaria, desde la recepción del pedido hasta la entrega.
Problema central: Felpuditos no puede escalar más allá de 3-4 órdenes por día porque cada tarea administrativa — cotizar, rastrear órdenes, calcular márgenes — es manual, frágil y está dispersa en herramientas desconectadas.
| Problema | Impacto en el negocio |
|---|---|
| Cálculo manual de precios | 40+ fórmulas frágiles. Cambios de costo: 30-40 min. Errores frecuentes. |
| Órdenes en 3 canales | Detalles perdidos, duplicados, sin visibilidad de estado. |
| Sin visibilidad de margen real | Ingresos rastreados, ganancia desconocida. IVA y comisiones sin contabilizar por orden. |
| Archivos de diseño sin estructura | 20-40 min por orden para preparar guía de producción. |
| Sin histórico de clientes | Sin rastreo de recurrencia ni datos de preferencias. |
| Distribución de ganancias opaca | Acuerdo 52/48 calculado manualmente, sin trazabilidad. |
Antes de comprometerse con una herramienta personalizada, explore tres enfoques con las fundadoras para entender qué nivel de solución encajaba realmente con su contexto y capacidad técnica.
Usar bases de datos de Notion o Airtable para centralizar órdenes y calcular precios con fórmulas.
Por qué se descartó: La lógica de precios era demasiado compleja para herramientas basadas en fórmulas sin que se rompieran al actualizar costos. Las socias también necesitaban una cotización lista para compartir con clientes de inmediato — ninguna herramienta manejaba eso sin personalización profunda que se romperia con cualquier actualización.
Reconstruir la hoja de cálculo con estructura más limpia, celdas protegidas y una sola hoja de entrada.
Por qué se descartó: Excel ya había probado su fragilidad — el problema no eran las fórmulas, era el modelo de interfaz. Una hoja rediseñada seguiría requiriendo capacitación, seguiría rompiéndose con entradas inesperadas, y no ofrecería rastreo de órdenes ni histórico de clientes.
Una herramienta interna a medida con navegación lateral persistente y cinco módulos: Calculadora, Pedidos, Inventario, Clientes y Configuración.
Por qué se eligió: La única solución capaz de manejar precios encadenados en tiempo real, historial de órdenes, datos de clientes y parámetros financieros configurables en un solo lugar — sin requerir conocimiento técnico para mantenerla.
Dentro de la app, la arquitectura del módulo de calculadora también tuvo dos direcciones: un layout denso de pantalla única vs. un layout de tres columnas que hacía visibles los inputs, variables y desglose de costos simultáneamente. Se eligió el de tres columnas porque la transparencia en el cálculo era en sí misma una feature — las socias necesitaban verificar los resultados, no solo confiar en ellos.
Como las fundadoras eran las usuarias, el testing estaba embebido en el proceso de diseño — no era una ronda de validación formal al final. Hice dos ciclos de iteración con prototipos funcionales antes del build final.
| Área | Antes | Después |
|---|---|---|
| Velocidad de cotización | ~5 min | ~30 seg |
| Capacidad diaria de cotizaciones | 3–4 | 10+ |
| Errores de cálculo | 2–3 por semana | 0 en 71 órdenes |
| Preparación guía de producción | 20–40 min/orden | Segundos |
| Registros de clientes | 0 estructurados | 14 con historial completo |
El cuello de botella se movió de cotización a capacidad real de producción — que es el problema correcto a tener.
Trabajar directamente con usuarias finales que también son stakeholders crea una tensión específica: sus preferencias inmediatas no siempre se alinean con lo que el producto necesita para escalar.
Postura de las socias: Querían seguir recibiendo órdenes por WhatsApp — era su canal de relación con los clientes, y pedir a los clientes usar una nueva herramienta era un riesgo que no estaban dispuestas a tomar en el lanzamiento.
Postura de Diseño: Un sistema donde las órdenes llegan fuera de la herramienta significa que la herramienta nunca tiene datos completos y el historial de órdenes siempre es parcial.
Resolución: La herramienta de V1 se diseñó para uso interno — las socias ingresan manualmente las órdenes recibidas por cualquier canal. WhatsApp no fue reemplazado, solo desacoplado del registro operativo. El cotizador público para clientes se reservó para V2, cuando los datos de comportamiento soportaran el cambio.
Postura de las socias: Inicialmente preferían una interfaz más simple — solo mostrar el precio final. El desglose se sentía como complejidad innecesaria.
Postura de Diseño: El desglose era la única forma de construir confianza en el sistema. Si un número parecía incorrecto y no podían auditarlo, volverían al Excel.
Resolución: Desglose completo mantenido, presentado en una sección colapsable para que no domine la interfaz pero siempre esté accesible. Después de la iteración 1, las socias usaron activamente el desglose para detectar un costo de material mal configurado en Ajustes — lo que validó la decisión.
Postura de las socias: Querían el rastreo de inventario incluido en V1 — el stock de materiales era un pain point real.
Postura de Diseño: Construir inventario antes de validar los módulos core de cotización y pedidos dividiría la atención y retardaría las features de mayor impacto.
Resolución: Inventario reservado para V2 con un placeholder visible en la navegación lateral para que las socias pudieran ver dónde viviría. Entregar el resto primero significó que la herramienta estaba en producción 3 semanas antes que si el inventario hubiera sido incluido.
Felpuditos no fue una app bonita para un negocio pequeño. Fue un sistema que movió el cuello de botella operacional de la administración a la capacidad real de producción.
La decisión de diseño más importante no fue un patrón de UI — fue elegir una herramienta personalizada sobre adaptar software existente. Esa elección hizo posible todo lo demás.
El research de campo continuo surfacó oportunidades que una entrevista inicial nunca hubiera revelado — especialmente el cuello de botella de la guía visual de producción, que resultó ser tan costoso como el problema de cotización.
Hola. Soy diseñador UX/UI, vivo en CDMX y llevo 3.5 años en Claro Música diseñando para una de las plataformas de streaming más grandes de la región. Me gusta hacer productos digitales donde las metas del negocio y las de los usuarios no se peleen entre sí.
Trabajo de forma pragmática: prefiero un prototipo feo testeado con 5 personas que un Figma impecable que nadie validó. Me interesa especialmente el diseño de flujos de suscripción y conversión —ahí donde un buen patrón de UX cambia el resultado del trimestre.
Fuera del trabajo, paso tiempo con mi novia, juego Valorant con amigos, y casi siempre tengo la Steam Deck cerca para algún indie o backlog pendiente.
