Currently working with
Working at Eleshop as Content Manager, I noticed the same problem surfacing in three places: support calls, walk-ins to our pickup office, and inventory that quietly stalled. One root cause: a homepage structurally working against its own audience. This case follows the full arc, from those real-world signals to a redesigned homepage, validated with a small comparative user test, and shipped as a clickable prototype that morphs each fix live.
Trabajando como Gestor de Contenido en Eleshop, vi el mismo problema aparecer en tres lugares: llamadas a soporte, visitas presenciales a nuestra oficina de recogida e inventario que se quedaba parado en silencio. Una causa raíz: una página de inicio que estructuralmente trabajaba contra su propia audiencia. Este caso recorre el arco completo, desde esas señales reales hasta una página de inicio rediseñada, validada con un pequeño test comparativo con usuarios, y enviada como prototipo clicable que transforma cada arreglo en vivo.
Solo, end to end. Diagnosed the root cause across three customer signals. Ran a small comparative user test on the live homepage and the redesigned prototype, matched to Eleshop's real customer typology (technical institutions and non-technical hobbyists). Translated findings into a paired Before / After. Built a React + Babel prototype with an in-place morph engine so the audit plays as a guided two-phase walkthrough (red audit, green improvement) on top of a faithful BEFORE recreation.
En solitario, de principio a fin. Diagnostiqué la causa raíz a partir de tres señales de cliente. Hice un pequeño test comparativo con usuarios sobre la página de inicio en vivo y el prototipo rediseñado, ajustado a la tipología real de cliente de Eleshop (instituciones técnicas y aficionados no técnicos). Traduje los hallazgos en parejas Antes / Después. Construí un prototipo en React + Babel con un motor de morph in situ, para que la auditoría se reproduzca como un walkthrough guiado en dos fases (auditoría en rojo, mejora en verde) sobre una recreación fiel del estado ANTES.
Three signals kept landing at the same place.Tres señales seguían llegando al mismo lugar.
First, the customer service log. Repeat questions about products that already had documented answers on the site, in the wrong place to be found. Repeat phone calls asking "do you have this in store, can I come look at it?" Eleshop runs pickup lockers at our Eindhoven office, not a showroom. People kept walking in expecting one.
Primero, el registro de atención al cliente. Preguntas repetidas sobre productos que ya tenían respuestas documentadas en el sitio, en el lugar equivocado para encontrarlas. Llamadas repetidas preguntando "¿lo tienes en tienda, puedo venir a verlo?" Eleshop tiene taquillas de recogida en nuestra oficina de Eindhoven, no una sala de exposición. La gente seguía viniendo esperando una.
Second, my own day as Content Manager. On a Magento + custom PIM catalogue of 200+ listings, I spent more time than I should have hunting for products through our own homepage navigation. If I could not find them quickly, customers definitely could not.
Segundo, mi propio día como Gestor de Contenido. Sobre un catálogo Magento + PIM personalizado con más de 200 listings, dedicaba más tiempo del que debería buscando productos a través de la navegación de nuestra propia página de inicio. Si yo no los encontraba rápido, los clientes desde luego que tampoco.
Third, dead stock. Slow-moving inventory was stalling earlier and longer than category dynamics could explain. When I traced the root cause, I kept landing on the same place: the homepage. Buried search, mixed-intent product rows, undifferentiated category tiles, and a footer dense enough to lose the link you needed.
Tercero, el stock muerto. El inventario lento se estancaba antes y por más tiempo de lo que la dinámica de categoría podía explicar. Cuando rastreaba la causa raíz, acababa siempre en el mismo sitio: la página de inicio. La búsqueda enterrada, filas de productos con intención mezclada, tiles de categoría indiferenciados y un pie de página tan denso que se perdía el enlace que necesitabas.
One root, three symptoms. A systems problem, not a content problem. That framing led to two interventions running in parallel: this homepage redesign, and a separate dead-stock detection tool (see the Deadstock case). The redesign attacks the symptom upstream. The detection tool catches what slips through downstream.
Una raíz, tres síntomas. Un problema de sistema, no de contenido. Ese enmarcado llevó a dos intervenciones en paralelo: este rediseño de la página de inicio, y una herramienta separada de detección de stock muerto (ver el caso Deadstock). El rediseño ataca el síntoma aguas arriba. La herramienta de detección captura lo que se cuela aguas abajo.
Every finding lives in a single Figma file structured as three frames. Frame 1 ("Navigation"): annotated screenshots of the live navigation with numbered findings on the right, each tagged with severity and ease-to-fix. Frame 2 ("Homepage"): same treatment for the hero, hero-adjacent rows, and editorial mixing. Frame 3 ("Recommendations"): a sortable table of all findings with a severity-vs-ease matrix and a priority recommendation, written as a deliverable to Eleshop, not as an internal artefact.
Cada hallazgo vive en un único archivo de Figma estructurado en tres frames. Frame 1 ("Navegación"): capturas anotadas de la navegación en vivo con hallazgos numerados a la derecha, cada uno etiquetado con severidad y facilidad de arreglo. Frame 2 ("Página de inicio"): mismo tratamiento para el hero, las filas adyacentes al hero y la mezcla editorial. Frame 3 ("Recomendaciones"): una tabla ordenable con todos los hallazgos, una matriz severidad-vs-facilidad y una recomendación de prioridad, escrito como entregable para Eleshop, no como artefacto interno.
Eleshop sells to two distinct audiences at the same time. Technical institutions (R&D departments, universities, repair professionals) arrive knowing what they need. Non-technical hobbyists arrive curious but unsure. Both depend on the homepage to land them on the right product family fast. The live homepage was structurally working against both.
Eleshop vende a dos audiencias distintas a la vez. Instituciones técnicas (departamentos de I+D, universidades, profesionales de reparación) llegan sabiendo lo que necesitan. Aficionados no técnicos llegan con curiosidad pero sin certeza. Ambos dependen de la página de inicio para aterrizar rápido en la familia de producto correcta. La página de inicio en vivo trabajaba estructuralmente contra los dos.
The homepage buried search, mixed editorial articles into product rows, hid the new arrivals at the bottom, and gave the most important entry points (the product categories) the least visual weight.
La página de inicio enterraba la búsqueda, mezclaba artículos editoriales en las filas de producto, escondía las novedades al fondo y daba a los puntos de entrada más importantes (las categorías de producto) el menor peso visual.
For the technical visitor: friction. For the hobbyist: a maze. For both: longer paths to the product page, and a brand that feels less like a specialist shop than it is.
Para el visitante técnico: fricción. Para el aficionado: un laberinto. Para ambos: caminos más largos hasta la ficha de producto, y una marca que parece menos especialista de lo que en realidad es.
A small-n comparative user test, matched to Eleshop's actual customer typology.
Un test comparativo con usuarios, de muestra pequeña, ajustado a la tipología real de cliente de Eleshop.
Eleshop's audience splits roughly in half. Technical buyers (institutions, repair professionals) arrive with a part number in mind. Non-technical hobbyists arrive curious but unsure. The audit was only useful if it landed for both. So the test had to include both.
La audiencia de Eleshop se divide aproximadamente por la mitad. Compradores técnicos (instituciones, profesionales de reparación) llegan con un número de pieza en mente. Aficionados no técnicos llegan con curiosidad pero sin certeza. La auditoría solo era útil si funcionaba para ambos. Por eso el test tenía que incluir a los dos.
I recruited five people from my network. Three with technical backgrounds (engineer, IT operations, electronics hobbyist with strong domain knowledge), and two without (a teacher, a colleague from a non-technical role). Each completed the same two tasks. First on the live Eleshop homepage. Then on the redesigned prototype.
Reclute a cinco personas de mi red. Tres con perfiles técnicos (ingeniero, operaciones IT, aficionado a la electrónica con conocimiento sólido del dominio) y dos sin él (una profesora, una compañera de un rol no técnico). Cada uno completó las mismas dos tareas. Primero sobre la página de inicio en vivo de Eleshop. Después sobre el prototipo rediseñado.
The test was the right tool for a half-day case. It is not a replacement for a properly powered usability study. What it gives me is a defensible "yes this lands for both halves of the audience" signal before I commit to a redesigned IA. That signal is what the rest of the prototype was built on.
The full clickable case study. Click Play walkthrough to run the auto-playing tour, or toggle Before / After in the top bar to compare the stationary versions side by side.
A focused half-day observational pass through the homepage, applied through the lens of behavioural psychology and known e-commerce conversion patterns. Not a sprawling discovery exercise. The goal was a yield, not a deck.
Each finding was framed as an opportunity, never as a complaint. Findings clustered around six themes: navigation crowding, hero passivity, mixed intent in product rows, undifferentiated category tiles, hidden high-intent signals, and footer density.
A React + Babel single-page prototype that renders both the BEFORE recreation of eleshop.nl and the AFTER redesign in the same DOM, swappable section by section. Each annotated region is a custom Section component with one of three modes: morph (BEFORE to AFTER in place), add (additive, materialises from a transparent spacer), or remove (removed when fixed).
The walkthrough engine drives the swaps as a sequenced tour. Two phases per fix, 7.5 seconds each. Audit phase highlights the problem in red, then a flushSync swap atomically flips the section to its AFTER snippet and the spotlight to green for the explanation. No middle "morph" step. No perceptible drift between caption and visual.
Why: The instant flip reads as a real layout change without forcing the user through a long animation. The spotlight engine re-queries `data-wt-before` after the swap, so it follows the section to its new position automatically.
Why: The instant flip mirrors how the diagnosis actually reads in a UX audit. Problem, then solution. The user does not need three phases of dwell time to understand the change.
Honest framing first: this case ships a redesigned prototype, not a redesigned production site. So "did it work" splits into two halves. What I tested before shipping, and what I would measure if the redesign rolled live.
Enmarcado honesto primero: este caso entrega un prototipo rediseñado, no un sitio de producción rediseñado. Así que "funcionó" se divide en dos mitades. Lo que probé antes de entregar y lo que mediría si el rediseño se subiera a producción.
The five-person comparative test (see Research above) gave a directional yes from both halves of Eleshop's customer typology. Non-technical participants who bounced on the live site completed both tasks on the prototype. Technical participants reported less redundant scrolling and faster path-to-product. All five used the word "specialist" or "shop" about the prototype, language none of them used about the live site.
The test is small and network-recruited. It is a signal, not a confirmatory measurement. It is what was feasible inside a half-day case and the right tool for that scope.
Why: The redesign was diagnosed from real customer signals. The evaluation plan closes that loop. We track whether the symptoms that surfaced the problem (support calls, slow product discovery) actually attenuate when the structure changes. The A/B test is the controlled measurement. The support log is the natural-experiment measurement.
The case study cannot claim "the redesign improved conversion by X%" because the redesign has not run as the live site. It can claim a defensible diagnosis (rooted in three converging signals), a defensible design (rooted in known conversion patterns and validated against both audience halves), and a measurable hypothesis (this is how we would tell if it worked). For a UX/Product Designer reading this case, those three together are the work.
El caso no puede afirmar "el rediseño mejoró la conversión en X%" porque el rediseño no se ha puesto en producción. Sí puede afirmar un diagnóstico defendible (apoyado en tres señales convergentes), un diseño defendible (apoyado en patrones de conversión conocidos y validado en las dos mitades de la audiencia) y una hipótesis medible (así es como sabríamos si funcionó). Para un Diseñador UX / de Producto que lea este caso, las tres juntas son el trabajo.
If your team is sitting on a conversion leak that needs a quick, defensible audit, or you want to see the morph engine wired into your own catalogue, I would love to compare notes.
Si tu equipo tiene una fuga de conversión que necesita una auditoría rápida y defendible, o quieres ver el motor de morph conectado a tu propio catálogo, me encantaría comparar notas.