PrestaShop · enero de 2026 – agosto de 2026
El matching entre comerciantes y agencias del portal Expert de PrestaShop, encuadrado por una auditoría de los datos y probado en código en el navegador
Capacidad demostrada
Reducir el riesgo de una promesa de producto decidiendo sobre la prueba y no sobre la intención
Wireframe deliberado · las pantallas reales se muestran a petición
Contexto
El portal Expert de PrestaShop conecta a los comerciantes con las agencias del programa Expert. La primera versión del directorio de agencias había vuelto a poner el programa en producción, pero seguía siendo pasiva: el comerciante busca solo, sin ayuda para decidir, sobre fichas heredadas de una migración desde la antigua herramienta de partners que nadie había saneado. Perfect Match transforma ese directorio en un motor de matching: el comerciante describe su proyecto y recibe las agencias adecuadas.
Problema abordado
La credibilidad del matching descansa por completo en los datos de las agencias. Y ese stock de fichas migradas nunca fue validado por las agencias: servicios mapeados automáticamente, campos vacíos, información declarativa sin confirmar. Prometer las agencias adecuadas sobre esa base es arriesgarse a recomendar ruido, decepcionar al comerciante y desestabilizar a las agencias. El verdadero tema no era dibujar un recorrido de matching: era decidir sobre qué podía girar honestamente ese matching.
Mi rol
Head of Product Design del portal, en dupla con producto: retomar una discovery detenida seis meses antes, definir los dos recorridos (comerciante y agencia), definir las reglas de matching con producto y data, diseñar las pantallas en código. Sin autoridad sobre los datos en sí: las preguntas de fiabilidad se zanjan con evidencia en mano por la persona que tiene acceso, no por el diseño.
Enfoque
Auditar antes de dibujar. Cada criterio de matching considerado fue clasificado (filtro eliminatorio, criterio de pertinencia, criterio de desempate) con su fuente, su fiabilidad y su comportamiento en caso de ausencia. Las reglas del algoritmo se definieron con producto y data a partir de esa matriz. Luego la misma exigencia de prueba se aplicó a las pantallas: los dos recorridos construidos en un playground interactivo dentro del repositorio del producto, con PUIK y Claude Code, y revisados en el navegador en lugar de en maqueta.
Decisión clave
Resultados
Implicación de la IA
Claude Code sirvió como herramienta de diseño: las pantallas de los dos recorridos se produjeron en Vue con PUIK, el design system open source de PrestaShop, en ramas dedicadas, dentro de un playground aislado con datos simulados, sin API ni autenticación. La orquestación se apoya en reglas escritas en el repositorio (convenciones de código, perímetro autorizado, estados a cubrir, revisión antes del merge): la IA ejecuta rápido, la dirección de diseño y las decisiones siguen siendo humanas.
Pruebas
Estos visuales son wireframes deliberados: el trabajo real vive en demos jugables, que se muestran en directo. Pide verlas .
Perfect Match le promete al comerciante describir su proyecto para recibir las agencias adecuadas, en lugar de buscar solo en una lista. Detrás de la promesa, una herencia: fichas de agencia salidas de una migración desde la antigua herramienta de partners, servicios mapeados automáticamente, campos vacíos. Las exploraciones de producto que precedieron convergían en la misma constatación: el déficit de confianza existe de los dos lados. El comerciante quiere pruebas al momento de elegir; la agencia aparece en proyectos fuera de su calibre, sobre la base de una ficha que nunca construyó. Ese déficit no se arregla con un filtro más. Se arregla decidiendo qué puede prometer el producto con los datos de los que realmente dispone.
La discovery había quedado detenida a mitad de camino seis meses antes. Retomarla fue primero un replanteamiento. La lectura inicial hacía del recorrido del comerciante el tema: un brief, una página de resultados, un algoritmo. Insuficiente: sin datos de agencia confiables, ese recorrido promete un match que no puede cumplir. El ciclo se encuadró entonces sobre dos casos de uso indisociables y jerarquizados: el recorrido del comerciante, atendido primero porque carga la promesa, y los datos de agencia, instrumentados porque solo ellos pueden cumplirla. Dos poblaciones de agencias se distinguieron desde ese planteamiento: la agencia histórica, cuya ficha migrada debe ser reapropiada antes de cualquier matching, y la agencia nueva, que construye la suya desde cero.
Ese planteamiento hizo emerger un desacuerdo real: ¿eran confiables los datos migrados? Una lectura decía que sí, las fichas están ampliamente completas. La otra decía que no, completa no significa validada, y hacer matching sobre información declarativa sin confirmar equivale a hacer matching sobre ruido. En lugar de zanjar por intuición, la divergencia se asentó como tal en el registro de decisiones del proyecto, con un arbitraje sobre evidencia por parte de la persona que tiene acceso a los datos. Un desacuerdo nombrado vale más que un consenso tibio: dentro de seis meses, el equipo sabrá por qué se definió la regla, no solamente cuál.
La intuición de partida sostenía que un buen matching exigía campos nuevos: tamaño de proyecto gestionado, presupuesto, disponibilidad. Bastaba con pedirles a las agencias que los llenaran. Esa hipótesis merecía verificarse antes de dibujar cualquier cosa. Cada señal disponible o considerada pasó entonces por revisión y se clasificó en tres familias: los filtros eliminatorios que excluyen del pool, los criterios de pertinencia que ordenan, los criterios de desempate que deciden entre buenos candidatos. Y para cada una, cuatro preguntas: el dato existe, de dónde viene, está probado o es declarativo, qué pasa cuando falta.
El resultado contradecía el plan. Los campos planteados al inicio eran los más frágiles de la matriz: declarativos, inverificables, y la disponibilidad caduca en unas semanas. En el sentido contrario, señales ya probadas dormían en lo existente: el ranking del directorio, el nivel de expertise otorgado por el programa, las certificaciones verificadas.
El dilema quedó planteado. Primera opción: esperar los datos nuevos, pedirles a las agencias que llenaran los campos faltantes, y lanzar un matching rico sobre información declarativa cuya fiabilidad seguiría siendo inverificable. Segunda opción: lanzar más sobrio, únicamente sobre los datos probados, asumiendo un matching menos fino pero donde cada regla se defiende. El razonamiento cupo en una pregunta: ¿con qué se va a encontrar el comerciante en el lanzamiento? Con un stock de fichas incompletas, un matching exigente en datos excluye agencias por una migración que no eligieron, y vacía las páginas de resultados.
La decisión: la primera versión gira exclusivamente sobre los datos probados existentes, y los campos declarativos llegan después, como refinamiento. Una regla por defecto completa el dispositivo: un dato ausente da un puntaje neutro y nunca excluye, fuera de los filtros duros. Consecuencias directas: el lanzamiento ya no depende de una recolección todavía hipotética, la reapropiación de la ficha migrada se convierte en el punto de partida del recorrido de agencia, y los casos límite se convierten en pantallas a diseñar primero.
La misma lógica se aplicó al diseño. Una maqueta habría mostrado el recorrido donde todo sale bien: tres agencias impecables, perfiles completos, un match evidente. La realidad del lanzamiento son datos incompletos, zonas casi vacías, briefs sin correspondencia. Los dos recorridos se construyeron entonces en un playground interactivo dentro del repositorio del producto, en Vue con PUIK, el design system open source de PrestaShop. Claude Code produjo las pantallas dentro de un marco definido de antemano; la dirección de diseño, las decisiones y la revisión siguieron siendo humanas. Cuando un componente faltaba en el design system, se convertía en un candidato propuesto al sistema y no en una divergencia local: un design system no se consume, se alimenta.
La página de resultados se diseñó a partir de los casos límite. Ninguna agencia corresponde al brief: la pantalla lo dice, propone ampliar la búsqueda y remite a la lista completa. La shortlist está incompleta: muestra lo que existe, anuncia el número, no infla nada. En un deck de maquetas, esos estados son los frames que nadie abre. En un playground, son situaciones contra las que la revisión tropieza, como tropezaría un comerciante. La revisión de producto cambió de naturaleza: el equipo ya no comenta una intención, pone a prueba un comportamiento.
Perfect Match no se presenta aquí como una funcionalidad en producción. Se apoya en la base descrita en Portal Expert: reemplazar una herramienta con una squad de tres. La prueba del proyecto está en otra parte: el directorio anterior podía mostrar perfiles, el nuevo portal puede calificar una necesidad de comerciante, convertirla en dato explotable y preparar su envío a las agencias seleccionadas.
Lo que está ganado cabe en tres puntos: un modelo de pertinencia donde cada regla es trazable hasta un hecho, un futuro lanzamiento calibrado sobre los datos que el producto realmente posee, y una práctica de revisión en playground que ya desborda este proyecto para volverse un hábito de equipo. La pregunta que contará antes de una puesta en producción no es si las pantallas quedaron bien: es si la regla del puntaje neutro basta para proteger la confianza mientras el stock de fichas se sanea.
Mi mandato terminó en agosto de 2026. El proyecto se transmitió con sus instrumentos: el playground reproducible, el registro de decisiones, los criterios de éxito definidos. Un diseño que no sobreviviera a ese traspaso no habría merecido la palabra.
Enseñanza
Una promesa de producto vale lo que valga la prueba que la sostiene. El dato real, la pantalla real, el estado real: toda decisión tomada sobre otra cosa es una intención, y una intención no protege a nadie en el lanzamiento.
Última actualización ·
Escrito con terquedad colombiana, en el sur de Francia.
No con amor, con contexto y un agente paciente.
Sigo aprendiendo.
© 2026 Todos los derechos reservados.