Orali • E-commerce
Rediseño de e-commerce de alimentos
Role
Product Designer
Timeline
2026
Team
1 UX/UI Designer
1 Graphic Designer (Orali)
1 Backend Developer
Skills
UX Research
UX/UI Design
Design System
Frontend
100%
encontró y agregó un producto sin ayuda (validación de prototipo)
84%
completó el checkout de punta a punta (validación de prototipo)
0 de 10
participantes del card sorting agruparon por línea comercial: la evidencia que justificó reorganizar el catálogo
Contexto
Orali tiene un buen producto y un e-commerce que lo esconde.
Fábrica familiar de pastas frescas con más de 50 años de trayectoria en la industria alimenticia argentina. tiendaorali.com es su canal de venta directa al consumidor
Rediseño propuesto, el sitio actual sigue activo. El cliente revisó los prototipos y el front de staging ya está implementado: lo desarrollé yo con Next.js, React y Tailwind CSS, desplegado en Vercel. El lanzamiento a producción está en evaluación.
El rediseño parte de una premisa: si el producto es bueno, el sitio no debería esconderlo. Cada decisión apunta a hacer visible el catálogo desde el primer ingreso, comunicar el mínimo de compra como guía en lugar de bloqueo, y mover el registro al momento en que tiene sentido, no como barrera de entrada.
Rediseño propuesto · desktop y mobile
El problema
7 hallazgos de la auditoría, agrupados en las cuatro decisiones de diseño que guiaron el rediseño.
Auditoría heurística sobre tiendaorali.com, el sitio en producción, no una reconstrucción.
Resultados clave
Validamos el flujo con 25 usuarios y repetimos la tarea del mínimo tras detectar un error en la herramienta.
El punto más débil fue el checkout (16% no lo completó): es la prioridad para la próxima iteración del flujo de pago.
100%
encontró y agregó un producto sin ayuda (Validación de prototipo)
86.67%
encontró Ñoquis Sin TACC por tipo de producto, no por categoría (Tree test)
7 de 10
llegó al mínimo de compra por el camino directo, guiado por la barra de progreso; nadie abandonó la tarea (Retest, n=10)
84%
completó el checkout de punta a punta: 21 de 25 (Validación de prototipo)
Research
Research mixto para entender el problema desde adentro y desde afuera.
10 entrevistas con compradores habituales de pastas frescas online, auditoría heurística del sitio, card sorting con 20 productos y 10 participantes, tree testing con 15-16 participantes según la tarea (8 tareas en total), y análisis de comportamiento del sitio actual.
De la cita a la decisión
Cada hallazgo, con la decisión de diseño que originó.
Arquitectura de información
Los usuarios organizan por tipo de producto. Las líneas comerciales son un modelo interno de la fábrica.
Validamos dos aspectos clave para definir cómo organizar el catálogo: card sorting para entender el modelo mental del usuario y tree testing para verificar que la nueva estructura funcionara en navegación real.
10
participantes en card sorting
15-16
participantes en tree test, 8 tareas
0
participantes agruparon por línea comercial
3/8
tareas superaron el 85% de éxito; las 2 más bajas suben de 40% a 73% contando la segunda respuesta válida
Qué encontramos: 3 de 8 tareas superaron el 85% y ningún participante buscó por línea comercial.
Qué revisamos: Empanadas rellenas y Ravioles vegano quedaron al 40% porque el test aceptaba una sola respuesta cuando había dos válidas; con ambas, el éxito sube a 73%. Miel y Tortillas (53%) marcan ubicaciones poco obvias, y Texturizado de soja (67%) no se busca como categoría sino como relleno.
Qué decidimos: mantener la agrupación por tipo de producto, mover Tortillas a Tapas y Miel a Especiales, y resolver Texturizado de soja con el filtro Vegetariano dentro de cada tipo de pasta.
De líneas comerciales a tipos de producto.
La nueva arquitectura reduce la carga cognitiva, mejora la velocidad para encontrar productos y alinea la navegación con el modelo mental de los usuarios.
Flujos de usuario
De un carrito bloqueado a un pedido confirmado, con el registro en el momento justo y no como barrera de entrada.
El mínimo es a nivel de pedido (12 unidades, 4 packs de cualquier combinación), no por producto.
Decisiones de diseño
Cada hallazgo, con las versiones que se descartaron antes de llegar a la decisión final.
Wireframes mid-fi
Prototipo navegable. 5 pantallas clave del flujo principal.
Validación
25 participantes, 4 tareas y un retest de la tarea del mínimo. El flujo principal funcionó; el checkout mostró dónde ajustar.
Test no moderado con Maze, sobre wireframes mid-fi, con usuarios del segmento real. En la tarea del mínimo detecté un error de Maze: las instrucciones tapaban el botón de finalizar tarea y generaban clics fallidos. Descarté esos resultados y repetí la tarea con 10 participantes nuevos: nadie abandonó y 7 de 10 llegaron al mínimo por el camino directo. Como el prototipo no deja avanzar sin el mínimo, el dato relevante es el camino, no la tasa de completitud. El checkout fue el punto más débil: 21 de 25 lo completaron, pero solo el 12% por el camino directo. Queda como prioridad de la próxima iteración. Se testeó en desktop por decisión del cliente: según sus datos, la mayoría de los usuarios llega desde desktop. Mobile queda para la validación posterior al lanzamiento.
Design System
El sistema convierte las decisiones del rediseño en reglas que el código no puede romper.
Tokens en Figma, versionados en GitHub, consumidos por Storybook y el sitio.
298
tokens en 3 capas: primitiva, semántica y componente
9 rutas × 2
viewports migrados
v1.2.1
versionado con changelog
Workflow
- Figma Variables
- Tokens Studio
- GitHub
- Style Dictionary
- GitHub Actions
- Storybook
Implementación
6 pantallas clave en desktop y mobile. Frontend implementado en staging; el lanzamiento está en evaluación por parte del cliente.
Ver prototipo
Impacto
Lo que ya se validó en el prototipo, y lo que se va a medir al lanzar.
Resultados de validación (prototipo): 100% descubrimiento (n=25) · mínimo de compra: 7 de 10 por el camino directo, 0 abandonos (retest, n=10) · 84% checkout (21 de 25). Métricas a medir después del lanzamiento: el sitio actual no tiene datos confiables, así que la línea de base de cada KPI se toma en el primer mes, con GA4, Clarity y Maze. Los objetivos relativos se calculan contra esa base.
A medir
> 2.5%
A medir
-25% vs. base
Registro completado (sobre quienes llegan al checkout)
A medir
> 60%
A medir
< 5 min
A medir
> 25%
A medir
< 2.5 seg
Aprendizajes
El problema real no era visual, era una restricción operativa sin mediación de UX.
El bloqueo real no era estético: era un mínimo de compra de 12 unidades comunicado solo como texto pasivo, sin guía de progreso. El diseño visual era consecuencia, no la causa, ahora audito restricciones operativas antes de abrir Figma.
La arquitectura se valida con datos, no con opiniones.
Reorganizar el catálogo por tipo de producto contradecía 50 años de estructura comercial interna. Lo que cerró la discusión no fue una opinión: fue el card sorting: ningún participante agrupó por línea comercial.
El argumento de negocio es parte del entregable de diseño.
El cliente quería mantener el registro obligatorio y la objeción a sumar OAuth fue de costo. El benchmark cerró el debate: los 5 competidores analizados permiten comprar sin cuenta y Orali era el único que bloqueaba el checkout detrás de un registro. El registro se mantuvo, pero con OAuth y al iniciar el checkout, después de armar el pedido.