Contexto y arquitectura
Un mismo producto. Tres formas de decidir.
Compradores, vendedores y moderación comparten el sistema, pero necesitan permisos, señales y recorridos diferentes.
Caso
Buy&Sell Marketplace
En un marketplace construido en equipo, conecté la dirección UX/UI, el sistema de diseño y la implementación frontend que asumí.
- 3 roles
- permisos y recorridos diferenciados
- Figma → Angular
- sistema llevado a componentes
- Full stack
- interfaz conectada a API y datos
Colaboración: Proyecto realizado en equipo durante el TFM; mi autoría se limita a la contribución descrita en este caso
Proyecto académico funcional. No se presenta como producto comercial ni como trabajo individual.
Una identidad que se convierte en productoDe la materia al marketplace.
Sistema de diseño
Los fundamentos toman forma.
Tokens, navegación, estados y componentes se organizan antes de construir las pantallas.
Experiencia de producto
Explorar, comprender y actuar.
La interfaz convierte el catálogo, la confianza y el estado de cada artículo en decisiones legibles.
Producto implementado
El sistema sobrevive al traspaso.
Figma define el lenguaje; Angular, Node y MySQL demuestran cómo funciona con componentes, permisos y datos reales.
El preámbulo termina. El producto empieza.
Del sistema a la experiencia.
Decisiones, componentes y código real del marketplace.Problema
Empecé por una pregunta, no por una pantalla: ¿qué necesita ver cada rol para actuar con criterio en un marketplace? Comprador, moderación y administración miran el mismo producto, pero toman decisiones distintas.
Revisamos patrones habituales —ficha de producto, estados de venta y señales sobre el vendedor— para entender qué información sostiene cada recorrido. Ese análisis llevó mi atención al flujo de moderación, donde había que decidir qué se muestra y qué se bloquea.
Con esa lectura definimos un ciclo de estados —borrador, publicado, en revisión, retirado, reservado y vendido— que condiciona el modelo de datos y la experiencia de cada rol. No traté el producto como una pantalla aislada: cada estado cambia quién puede hacer qué.
Métodos: Benchmarking de marketplaces de referencia · Hipótesis de usuario por rol: comprador/vendedor, moderador, administrador · Arquitectura de la información y mapa de estados del producto · Site map y flujos por rol antes de dibujar una sola pantalla.
Sistema
En Figma organicé el sistema en átomos, moléculas y organismos para poder hablar de variantes y estados antes de abrir Angular. Badge, botón, tarjeta, buscador y panel se diseñaron como piezas que debían mantener una misma lógica al llegar al código.
La diferencia entre roles apareció enseguida en las cabeceras: no necesitábamos un header genérico, sino accesos acordes con cada permiso. Usé esa distinción para que la jerarquía visual acompañara lo que cada persona puede consultar o gestionar.
El prototipo navegable nos permitió recorrer los flujos por rol, detectar decisiones pendientes y ajustar la estructura antes de implementar mis partes del frontend.
IA en el proceso
La IA se integró como acelerador documentado, no como autor. Se utilizó para explorar variantes de componentes, acelerar scaffolding repetitivo y contrastar decisiones de arquitectura; la decisión final fue humana en cada fase, contrastando claridad, accesibilidad, coherencia con el sistema y viabilidad técnica.
- Herramienta
- Claude · Codex (asistentes de código y diseño)
- Fase
- Exploración de variantes, scaffolding de componentes, contraste de arquitectura
- Aportación humana
- Sistema de diseño atomizado en Figma, modelo de datos, criterios de accesibilidad y coherencia
- Resultado de la IA
- Variantes de componentes y estructuras candidatas para revisión
- Criterio de selección
- Claridad, accesibilidad, coherencia con el sistema, evidencia de usuario, viabilidad técnica
- Límites detectados
- La IA no decide jerarquías ni flujos; propone. Todo output se revisa contra el prototipo y el modelo de datos
- Decisión final
- Humana en cada fase. La IA acelera; el criterio dirige
Implementación
Como lead UX/UI definí el lenguaje visual y la estructura del sistema compartido. En desarrollo llevé a Angular los flujos de registro, perfil y edición de perfil, cuidando la correspondencia con sus versiones desktop y mobile.
El producto completo conectó Angular, una API Node/Express y MySQL. Backend y base de datos fueron responsabilidad de otro integrante; mi trabajo consistió en diseñar la experiencia y conectar mi parte del frontend con los contratos del equipo.
La implementación reveló la distancia entre un prototipo ideal y un producto colectivo: restricciones del shell compartido, dependencias del API y componentes desarrollados por distintas personas. Esa negociación forma parte del caso, no se oculta.
Evidencia
La evidencia que puedo mostrar combina la revisión académica del TFM, pruebas funcionales de los flujos por rol y un contraste heurístico con los principios trabajados en el máster de UX/UI. Me sirvió para revisar la correspondencia entre diseño, código y datos, sin presentar el ejercicio académico como una validación comercial.
Del prototipo al componente
Organización del sistema
- atoms / badge · button · button-icon · icon · link-icon · toast
- molecules / cards · buscador · user-card · user-contact · breadcrum · report-modal
- organisms / guest-header · user-header · moderator-header · admin-moderator-header
- organisms / admin · reports · incidents · historic-moderator
Código · evidencia de implementación
import { Component, computed, input } from '@angular/core';
import { BadgeIcon, BadgeIconPosition } from './badge.types';
@Component({
selector: 'atom-badge',
templateUrl: './badge.html',
styleUrl: './badge.css',
})
export class Badge {
variant = input<string>('Como nuevo');
icon = input<BadgeIcon>('none');
iconPosition = input<BadgeIconPosition>('left');
protected label = computed(() =>
this.variant().replace(/_/g, ' ')
);
protected classes = computed(() =>
`app-badge app-badge--${this.cssVariant()}`
);
}frontend/src/app/components/atoms/badge/badge.ts
Componente real del TFM: el átomo Badge en Angular (signals). Sus variantes tipadas mapean literalmente el enum de MySQL — del prototipo al componente, y del componente al dato.
BadgeEstado = 'Borrador' | 'Publicado' | 'En_revision' | 'Retirado' | 'Reservado' | 'Vendido' ← enum MySQL de la tabla productos
Evidencias
El trabajo, abierto a revisión.
El prototipo es una pieza del proceso: documenta el sistema, las decisiones y los flujos que sostienen el producto.
Abrir diseño en FigmaAprendizajes
Aprendí que la atomización en Figma solo aporta valor si sobrevive al traspaso: la estructura del frontend necesita conservar esa lógica.
El flujo de moderación condiciona el modelo de datos aunque apenas se vea en la portada del producto.
Tipar el frontend contra los enums de la base de datos me ayudó a acotar estados que la interfaz no debería permitir.
Pregunta abierta: ¿Cómo afecta la arquitectura de la información a la adopción de un sistema de gestión por parte de roles no técnicos?
Contacto
Hablemos.
Si crees que mi forma de trabajar encaja en tu equipo, o tienes un producto o una investigación que quieras desarrollar, me gustaría conocerlo. Cuéntame qué necesitas y en qué punto estás. Leeré tu mensaje personalmente.
También puedes encontrarme en LinkedIn