E-commerce · 2025
E-commerce Day Market
Diseño end-to-end del e-commerce de una tienda de alimentación latina en Madrid que gestionaba 80 páginas de catálogo en un PDF y sus pedidos por WhatsApp, mientras atendía el mostrador.
Antes
La atención partida entre el mostrador y el móvil.
Después
Diseño de la app: navegación por país y acceso al catálogo.
Producto B2C · Ecommerce · End-to-end design · Proyecto desde cero
Contexto
Trabajé como Product Designer freelance, con ownership de extremo a extremo: desde entender el problema hasta la UI completa y la conducción del traspaso a desarrollo.
El cliente era la dueña de una tienda física de alimentación latina en Madrid, un negocio real, en funcionamiento y en crecimiento. Ella era a la vez clienta, experta de dominio y clave para todo lo que vino después: la persona que tendría que mantener la plataforma una vez construida.
El producto se concibió como una app híbrida, entregada por fases: la web fue la primera en salir, y es la que hoy está operativa.
Qué hice yo
Discovery, flujos, arquitectura de información, toda la UI en Figma, la iteración de las fichas de producto y el cross-selling, y ser el punto de continuidad del proyecto durante todo el desarrollo.
Qué aportaron otros
La dueña puso el conocimiento del negocio, del catálogo y de cómo compraban sus clientes. La implementación recayó en un rol de desarrollo externo que, como se cuenta más abajo, rotó varias veces.
El Problema
La dueña atendía el mostrador y, en paralelo, gestionaba los pedidos por WhatsApp: la atención partida en dos y los chats acumulándose fuera de control.
El catálogo vivía en un PDF de unas 80 páginas. Cualquier cambio de precio obligaba a editar el documento entero, así que mantener los precios al día era insostenible. Y para el cliente no había buscador: encontrar un producto concreto significaba recorrer el PDF página por página.
A medida que el negocio crecía y los pedidos se multiplicaban, el método manual aguantaba cada vez menos. El detonante fue justo ese: la gestión de pedidos se rompía por su propio crecimiento. Y por debajo había una necesidad más silenciosa: la dueña tenía que poder añadir y editar productos ella misma, sin llamar a un desarrollador cada vez.
Proceso
Entender antes de dibujar. Empecé por conversaciones con la dueña para ver cómo trabajaba de verdad: cómo cambiaba el catálogo, cómo le llegaban los pedidos y qué necesitaba para no depender de nadie en el mantenimiento. El discovery buscaba entender la operación real de una persona que vende y gestiona a la vez, más que recoger una lista de requisitos.
Buscar referencias donde sí las había. La "competencia" directa no servía como referencia: los pocos e-commerces de alimentación latina existían, pero sin buenas prácticas de diseño detrás. Así que tomé referencias del e-commerce general y de los supermercados online, porque el núcleo del problema (buscar, navegar entre productos, carrito y checkout) es el mismo que esos productos ya han resuelto bien mil veces.
La IA como acelerador del criterio. Todo el material del discovery (notas de las conversaciones, referencias, hallazgos) corría el riesgo de quedarse en un montón de notas sueltas. Usé IA para organizarlo, resumir el research y priorizar acciones y procesos, de modo que la fase de entendimiento se convirtiera en una base ordenada sobre la que decidir en lugar de un cajón de desastre. El criterio de qué priorizar siguió siendo mío; la IA me quitó la fricción de ordenar y me devolvió tiempo para decidir.
Secuencia deliberada. Diseñé primero los flujos, después la arquitectura de información y dejé la UI para el final. Resolver el movimiento del usuario y el orden del catálogo antes de tocar la interfaz fue una decisión consciente.
Iteración. La ficha de producto se iteró para mejorar la jerarquía de la información y dar cabida al cross-selling: que un producto abriera la puerta a otros sin saturar la vista.
Handoff, la parte más dura. Diseñamos "a ciegas" a nivel técnico, porque el desarrollador se incorporó después de la fase de diseño. A partir de ahí, el desarrollo cambió de manos tres veces: uno lo dejó por motivos personales; otro implementaba componentes que no eran fieles a la UI y hubo que sustituirlo. Cada relevo obligó a repetir reuniones para poner al día al siguiente. Fui el punto de continuidad del proyecto: quien sostenía el criterio de diseño y el contexto mientras la implementación rotaba.
Decisiones Clave
Diseñar para quien mantiene el producto, además de para quien compra
Prioricé que la dueña pudiera gestionar el catálogo (altas y cambios de precio) sin depender de un desarrollador. Trade-off: un catálogo estático habría sido más rápido y simple de construir, pero habría reproducido justo el problema del PDF: depender de otra persona para cada cambio. Elegí la autonomía a costa de más complejidad, porque el dolor real del negocio estaba en el mantenimiento, más que en la estética.
Patrones probados de supermercado online, con un eje de navegación por país
Basé navegación, búsqueda y checkout en patrones probados de e-commerce general, en lugar de en las webs de alimentación latina existentes, y añadí sobre esa base un eje propio del dominio: explorar el catálogo por país de origen (Venezuela, Colombia, Perú, México, Ecuador…), además de por categoría de producto. La razón es de comportamiento real: la mayoría de clientes son latinoamericanos y buscan primero por su país, porque cada cultura tiene productos propios que no se fabrican fuera. Trade-off: apoyarse en patrones de súper convencional arriesgaba parecer "otro súper más", y sumar el eje por país añade complejidad de navegación y de mantenimiento del catálogo. Asumí ambas cosas porque las referencias de nicho no aportaban buenas prácticas que copiar, y porque el eje por país es justo lo que hace la tienda reconocible y rápida para quien la usa.
Navegación por país
Flujos y arquitectura antes que UI
Resolví primero cómo se mueve el usuario y cómo se ordena el catálogo, y dejé la interfaz para el final. Trade-off: con una clienta no técnica y con ganas de ver algo "real", enseñar flujos y arquitectura es menos vistoso que enseñar pantallas acabadas, y cuesta más sostener la confianza en esa fase. A cambio, evité retrabajo estructural: cambiar la arquitectura con la UI ya montada habría salido mucho más caro.
Ficha de producto densa pero jerarquizada, para abrir cross-selling
Iteré la ficha para incorporar productos relacionados y trabajar el ticket medio. Trade-off: cada elemento añadido compite por atención y puede enterrar lo esencial (precio, disponibilidad, añadir al carrito). Lo resolví con jerarquía: primero la decisión de compra, el cross-selling después, nunca por delante.
Diseñar la app híbrida completa, aunque la entrega empezara por web
El producto se diseñó como una app híbrida, pero el presupuesto del cliente marcó empezar la construcción por la web, así que esa fue la primera fase en salir. Trade-off: ajustarse al presupuesto significaba posponer parte del producto y lanzar primero solo una porción; a cambio, el cliente pudo empezar a vender antes, sobre una base de diseño pensada para el conjunto y no solo para la web. El desarrollo de la app está arrancando ahora.
