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.
How Buy&Sell was implemented.
From system to experience.
Decisions, components and real marketplace code.Problem
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.
Before designing the screens, we studied the needs of each role. We reviewed familiar patterns—product pages, sale states and seller signals—to understand what information each journey needed. 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. Each state changes who can view, modify or manage the product.
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.
I designed headers with different access points based on each role's permissions, so people could find the options available to them.
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
We used AI to explore component variants, generate repetitive code structures and assess architectural decisions. We documented its use, and the team made the final decisions after reviewing 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.
During implementation, we had to adapt the design to the application's shared structure, API dependencies and components developed by other team members.
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