Ketea • E-commerce
Rediseño de e-commerce B2C y dashboard de gestión
Role
Product Designer
Timeline
2025
Team
1 Designer
1 Data Analyst
1 Backend Developer
Skills
UX/UI Design
Design System
Frontend
180 tokens
en capas primitiva y semántica, publicados como paquete vía Style Dictionary
86 componentes
del e-commerce, con su story en Storybook, documentados en 62 piezas, y 9 estados secundarios en Figma (vacío, error, éxito)
2 productos · 0 redefiniciones
e-commerce y dashboard construidos sobre el mismo sistema de tokens
Contexto
Un sistema de tokens → dos productos implementados.
No rediseñamos dos productos. Construimos el sistema que los produce.
Los mismos tokens en el e-commerce y el dashboard. El sistema permite sincronización entre diseño y código a través de tokens compartidos.
−20/30%
abandono de carrito proyectado (checkout rediseñado de un paso único sin validación a 3 pasos con validación inline, Baymard Institute)
2 productos
implementados sobre el mismo sistema de tokens (sin retrabajo de handoff entre e-commerce y dashboard)
86
componentes de la tienda con su story en Storybook, documentados en 62 piezas
El problema
Dos síntomas. El mismo origen.
El e-commerce funcionaba correctamente a nivel técnico, pero su arquitectura no acompañaba el proceso de decisión en productos de alto compromiso. El dashboard, en paralelo, acumulaba métricas sin jerarquía clara. Misma raíz: ningún producto estaba organizado alrededor de cómo decide su usuario.
E-commerce
El análisis permitió identificar los momentos del funnel de compra donde la experiencia aumentaba innecesariamente la carga de decisión.
Dashboard
Métricas fragmentadas entre ventas, marketing y operación sin jerarquía. Marketing por sí solo estaba repartido en 5 pantallas separadas (campañas, cupones, email, carritos abandonados, segmentos de clientes) sin ninguna vista que las conectara. Los usuarios escaneaban sin encontrar el insight que guiara la lectura.
Objetivos de diseño
Construir el sistema primero
Tokens en tres capas, exportados a GitHub, como base compartida de ambos productos.
Rediseñar el e-commerce por decisión
Orientado al proceso de decisión del comprador técnico, no a la lógica de inventario.
Diseñar el dashboard por decisión, no por dato
Un sistema de decisiones de negocio, no una acumulación de métricas.
Research
Señales que definieron todas las decisiones de diseño.
Antes de diseñar cualquier pantalla, hice una auditoría heurística del e-commerce existente para identificar las principales fricciones del sistema. Complementé el análisis con benchmarking de e-commerce especializados del rubro y principios de UX para catálogos complejos. En paralelo, para el dashboard analicé referentes de dashboards operativos y patrones de lectura de usuarios de negocio, para entender cómo sintetizar información compleja en vistas de escaneo rápido.
El objetivo no era validar una hipótesis con usuarios, sino detectar problemas estructurales que impedían encontrar, comparar y comprar productos (y leer el negocio) de forma eficiente.
Patrones (E-commerce)
Del cruce entre la auditoría heurística y el benchmark surgieron 5 patrones recurrentes, la base de las decisiones que siguen.
Patrones (Dashboard)
En paralelo, para el dashboard se analizaron referentes de dashboards operativos (SaaS de analytics y paneles internos de proyectos anteriores) y patrones de lectura en 3 áreas de negocio, priorizando 4 insights accionables.
Un mismo patrón, dos productos
Las fricciones no eran errores puntuales de interfaz, sino un problema estructural: ninguno de los dos productos distribuía la toma de decisiones de forma clara (el e-commerce a lo largo del recorrido de compra, el dashboard a lo largo de la lectura del negocio). El desafío no era optimizar pantallas aisladas, sino reorganizar el sistema de decisión completo.
Arquitectura de información
Cada producto organiza la información según cómo decide su usuario, no según cómo está guardada.
Antes de diseñar cualquier pantalla, se definió cómo se estructura la información en cada producto y en qué orden se lee. El e-commerce pasa de una taxonomía por lógica de inventario a una por proceso de decisión de compra. El dashboard pasa de métricas acumuladas a vistas organizadas por pregunta de negocio. Estas dos decisiones sostienen todo lo que sigue en Decisiones de diseño.
Arquitectura del e-commerce
La navegación agrupaba 19 categorías de primer nivel sin criterio consistente, mezclaba marcas con categorías genéricas y términos vagos, con profundidad inconsistente entre secciones y clasificación por lógica de inventario en vez de decisión de compra. La nueva taxonomía organiza el catálogo en un mega-menú de tres niveles fijos, por proceso de decisión del comprador técnico.
Arquitectura del dashboard
3 vistas por pregunta de negocio, sin solapamiento (Resumen, Ventas y Marketing), cada una con su propio set de métricas.
Modelo de lectura
Cada vista sigue la misma secuencia: insight principal → KPIs clave → análisis → insights accionables.
Decisiones de diseño
5 decisiones que convirtieron el research en sistema.
Transformar el funnel de compra en una secuencia clara de decisiones: simplificar la entrada eliminando redundancias entre navegación, categorías y búsqueda; asignar un rol específico a cada etapa del recorrido; evitar la acumulación de validaciones en el checkout; y reducir fricción sin depender de estímulos promocionales. Cada decisión que sigue traduce estos principios a un componente o patrón del sistema.
Dashboard
El dashboard no es parte del funnel de compra, es el segundo producto del sistema. Mismo criterio: organizar la decisión en vez de acumular datos, aplicado ahora a la lectura del negocio en vez de al proceso de compra.
Design System
El sistema que sostiene ambos productos.
Antes de diseñar cualquier pantalla, construimos el Design System: tokens, componentes y principios compartidos entre el e-commerce y el dashboard. Una única fuente de verdad entre Figma, GitHub y el código.
180
tokens en 3 capas: primitiva, alias y semántica
122 stories
del e-commerce, en 62 piezas documentadas en Storybook
v3.0.0
versionado con changelog
Workflow
- Figma Variables
- Tokens Studio
- GitHub
- Style Dictionary
- GitHub Actions
- Storybook
Implementación
El sistema, en su forma final.
Los mismos tokens y componentes del Design System, aplicados en el e-commerce y en el dashboard interno.
E-commerce
Ver prototipo online
Impacto
El impacto no viene de rediseñar dos productos, viene de unificarlos en un sistema.
Las métricas son consecuencia del sistema, no de decisiones aisladas de pantalla.
KPIs (3 niveles)
Proyecciones de usuario y negocio, más lo que el sistema ya habilitó como infraestructura.
Abandono de carrito
-20–30%
Tasa de conversión
+15–25%
Errores en formularios
-40–60%
Diagnóstico del estado del negocio
Visible en <10s
Separación de decisiones por área
3 preguntas → 3 vistas
Componentes documentados con variantes y estados secundarios
+70 componentes
Tokens compartidos entre dos productos
3 capas sincronizadas
Decisiones no duplicadas en el segundo producto
0 redefiniciones
Reflexión
Diseñar el sistema antes que los productos evita el retrabajo.
El dashboard heredó los tokens ya sincronizados con código, solo hizo falta crear los componentes de datos, no un segundo lenguaje visual.
El problema de negocio no siempre es el problema de experiencia.
A mitad de proyecto surgió la métrica real: ventas en canal propio, no conversión general. Cambió qué se medía y qué se priorizaba.
Qué haría diferente hoy
Alinear las métricas de negocio antes del brief, no a mitad de proyecto.
Auditar la calidad de datos del catálogo en research, los filtros técnicos asumen atributos que no estaban estandarizados.
Diseñar estados vacíos y de carga del dashboard desde el inicio, no como deuda técnica de último momento.