Context and architecture
One product. Three ways to make decisions.
Buyers, sellers and moderators share the system but need different permissions, signals and journeys.
Case study
Buy&Sell Marketplace
In a marketplace built as a team, I connected UX/UI direction, the design system and the frontend implementation I was responsible for.
- 3 roles
- distinct permissions and user journeys
- Figma → Angular
- design system translated into components
- Full stack
- interface connected to an API and data
Collaboration: A team project completed for the master's final project; my authorship is limited to the contribution described in this case study
A working academic project. It is not presented as a commercial product or an individual project.
An identity that becomes a productFrom material to marketplace.
Design system
The foundations take shape.
Tokens, navigation, states and components are organised before the screens are built.
Product experience
Explore, understand and act.
The interface turns the catalogue, trust and each item's status into clear choices.
Implemented product
The system survives the handoff.
Figma defines the language; Angular, Node and MySQL demonstrate how it works with components, permissions and real data.
The introduction ends. The product begins.
From system to experience.
Decisions, components and real marketplace code.Problem
I started with a question, not a screen: what does each role need to see to make informed decisions in a marketplace? Buyers, moderators and administrators look at the same product but make different decisions.
We reviewed familiar patterns—product pages, sale states and seller signals—to understand the information supporting each journey. That analysis drew my attention to the moderation flow, where we had to decide what should be shown and what should be blocked.
From that analysis, we defined a lifecycle—draft, published, under review, withdrawn, reserved and sold—that shapes the data model and each role's experience. I did not treat the product as an isolated screen: every state changes who can do what.
Methods:Benchmarking of reference marketplaces · User hypotheses by role: buyer/seller, moderator, administrator · Information architecture and product state map · Site map and role-based flows before drawing a single screen.
System
In Figma, I organised the system into atoms, molecules and organisms so we could discuss variants and states before opening Angular. Badges, buttons, cards, search and panels were designed as elements that needed to retain the same logic in code.
The differences between roles soon became clear in the headers: we did not need a generic header, but access points matched to each permission. I used that distinction to align the visual hierarchy with what each person can view or manage.
The interactive prototype let us walk through each role's flows, identify unresolved decisions and adjust the structure before I implemented my parts of the frontend.
AI in the process
AI was integrated as a documented accelerator, not as an author. It was used to explore component variants, speed up repetitive scaffolding and assess architectural decisions. People made the final decisions at every stage, considering clarity, accessibility, consistency with the system and technical feasibility.
- Tool
- Claude · Codex (coding and design assistants)
- Phase
- Variant exploration, component scaffolding and architectural assessment
- Human contribution
- Atomic design system in Figma, data model, accessibility and consistency criteria
- AI output
- Component variants and candidate structures for review
- Selection criteria
- Clarity, accessibility, system consistency, user evidence and technical feasibility
- Identified limitations
- AI proposes hierarchies and flows; it does not decide them. Every output is reviewed against the prototype and data model
- Final decision
- Human decisions at every stage. AI accelerates; judgement guides
Implementation
As UX/UI lead, I defined the visual language and the structure of the shared system. During development, I implemented the registration, profile and profile-editing flows in Angular, maintaining consistency with their desktop and mobile designs.
The complete product connected Angular, a Node/Express API and MySQL. Another team member was responsible for the backend and database; my work was to design the experience and connect my part of the frontend to the team's contracts.
Implementation revealed the gap between an ideal prototype and a team-built product: constraints in the shared shell, API dependencies and components developed by different people. That negotiation is part of the case study, not something to hide.
Evidence
The evidence I can share combines the academic review of the master's final project, functional tests of role-based flows and a heuristic assessment against the principles studied in the UX/UI master's programme. It helped me review the alignment of design, code and data without presenting an academic exercise as commercial validation.
From prototype to component
System structure
- 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
Code · implementation evidence
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
An actual component from the master's final project: the Badge atom in Angular (signals). Its typed variants map directly to the MySQL enum—from prototype to component, and from component to data.
BadgeEstado = 'Borrador' | 'Publicado' | 'En_revision' | 'Retirado' | 'Reservado' | 'Vendido' ← MySQL enum in the productos table
Evidence
The work, open for review.
The prototype is one part of the process: it documents the system, decisions and flows behind the product.
Open the design in FigmaLessons learned
I learned that atomic design in Figma only adds value if it survives the handoff: the frontend structure needs to preserve that logic.
The moderation flow shapes the data model even when it is barely visible on the product's homepage.
Typing the frontend against the database enums helped me constrain states the interface should not allow.
Open question:How does information architecture affect the adoption of a management system by people in non-technical roles?
Contact
Let's talk.
If you think the way I work would fit your team, or you have a product or research project you would like to develop, I would love to hear about it. Tell me what you need and where you are now. I will read your message personally.
You can also find me on LinkedIn