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
Un marketplace tecnológico construido en equipo: mi contribución conecta dirección UX/UI, sistema de diseño e implementación frontend.
- 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
El punto de partida no fue una pantalla, sino una pregunta: ¿qué necesita ver cada tipo de persona dentro de un marketplace para poder actuar con confianza? Un comprador, un moderador y un administrador miran el mismo producto y necesitan cosas distintas.
El benchmarking de marketplaces consolidados sirvió para mapear patrones ya validados por millones de usuarios (ficha de producto, estados de venta, señales de confianza del vendedor) y detectar dónde había espacio para decidir con criterio propio: el flujo de moderación.
La decisión estructural del research: el flujo de moderación condiciona el modelo de datos. Un producto no está simplemente "publicado o no": vive en un ciclo de estados (borrador, publicado, en revisión, retirado, reservado, vendido) que determina qué ve cada rol. Esa máquina de estados nació en el research, no en el código.
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
El sistema de diseño se construyó en Figma por atomización estricta: átomos (badge, button, icon, toast), moléculas (cards, buscador, user-card) y organismos (headers por rol, paneles de moderación, informes de administración). Cada componente se diseñó con sus variantes y estados antes de existir en código.
La prueba de que la atomización no fue cosmética: el header no es un componente, son cuatro. Guest, usuario, moderador y administrador tienen cabeceras distintas porque sus permisos son distintos. La jerarquía visual replica la jerarquía de permisos.
El prototipo funcional navegable en Figma permitió validar los flujos completos por rol antes de escribir la primera línea de Angular.
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
- Input humano
- Sistema de diseño atomizado en Figma, modelo de datos, criterios de accesibilidad y coherencia
- Output
- 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 validación combinó revisión académica del TFM, pruebas funcionales de los flujos por rol y contraste heurístico de las interfaces contra los principios de usabilidad trabajados en el máster de UX/UI. El resultado: un sistema donde diseño, código y datos cuentan la misma historia.
Del prototipo al componente
Figma · sistema atomizado
- 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
Angular · componente real
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.
Explorar la evidencia en FigmaAprendizajes
La atomización en Figma solo vale si sobrevive al traspaso: la estructura de carpetas del frontend debe replicar la del archivo de diseño.
El flujo de moderación es la parte del sistema que más condiciona el modelo de datos, no la más visible.
Tipar el frontend contra los enums de la base de datos elimina toda una familia de estados imposibles.
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 tienes un producto difícil de ordenar, una investigación que necesita forma o una idea que todavía no sabes cómo probar, cuéntame el contexto. Leo y respondo yo, sin automatismos.
También puedes encontrarme en LinkedIn