Contesto e architettura
Un solo prodotto. Tre modi di decidere.
Acquirenti, venditori e moderatori condividono il sistema, ma hanno bisogno di permessi, segnali e percorsi diversi.
Caso studio
Buy&Sell Marketplace
In un marketplace realizzato in team, ho collegato la direzione UX/UI, il design system e l’implementazione frontend di cui ero responsabile.
- 3 ruoli
- permessi e percorsi differenziati
- Figma → Angular
- sistema tradotto in componenti
- Full stack
- interfaccia collegata ad API e dati
Collaborazione: Progetto svolto in team durante il lavoro finale del master; la mia paternità è limitata al contributo descritto in questo caso
Progetto accademico funzionante. Non viene presentato come prodotto commerciale né come lavoro individuale.
Un’identità che diventa prodottoDalla materia al marketplace.
Design system
I fondamenti prendono forma.
Token, navigazione, stati e componenti vengono organizzati prima di costruire le schermate.
Esperienza di prodotto
Esplorare, comprendere e agire.
L’interfaccia trasforma catalogo, fiducia e stato di ogni articolo in scelte comprensibili.
Prodotto implementato
Il sistema supera il passaggio allo sviluppo.
Figma definisce il linguaggio; Angular, Node e MySQL mostrano come funziona con componenti, permessi e dati reali.
Come è stato sviluppato Buy&Sell.
Dal sistema all’esperienza.
Decisioni, componenti e codice reale del marketplace.Problema
Che cosa deve vedere ogni ruolo per prendere decisioni consapevoli in un marketplace? Acquirenti, moderatori e amministratori osservano lo stesso prodotto, ma prendono decisioni diverse.
Prima di progettare le schermate abbiamo studiato le esigenze di ogni ruolo. Abbiamo esaminato schemi comuni — scheda prodotto, stati di vendita e informazioni sul venditore — per capire di quali informazioni avesse bisogno ogni percorso. L’analisi ha portato la mia attenzione sul flusso di moderazione, dove bisognava decidere cosa mostrare e cosa bloccare.
Da questa lettura abbiamo definito un ciclo di stati — bozza, pubblicato, in revisione, ritirato, prenotato e venduto — che condiziona il modello dati e l’esperienza di ogni ruolo. Ogni stato cambia chi può consultare, modificare o gestire il prodotto.
Metodi:Benchmarking di marketplace di riferimento · Ipotesi sugli utenti per ruolo: acquirente/venditore, moderatore, amministratore · Architettura dell’informazione e mappa degli stati del prodotto · Mappa del sito e flussi per ruolo prima di disegnare una sola schermata.
Sistema
In Figma ho organizzato il sistema in atomi, molecole e organismi per discutere varianti e stati prima di aprire Angular. Badge, pulsante, scheda, ricerca e pannello sono stati progettati come elementi che dovevano mantenere la stessa logica nel codice.
Ho progettato intestazioni con accessi diversi in base ai permessi di ogni ruolo, affinché ciascuna persona potesse trovare le opzioni a sua disposizione.
Il prototipo navigabile ci ha permesso di percorrere i flussi per ruolo, individuare decisioni ancora aperte e adattare la struttura prima di implementare le mie parti del frontend.
L’IA nel processo
Abbiamo usato l’IA per esplorare varianti dei componenti, generare strutture di codice ripetitive e valutare scelte architetturali. Ne abbiamo documentato l’uso e le decisioni finali sono rimaste al team, che ha valutato chiarezza, accessibilità, coerenza con il sistema e fattibilità tecnica.
- Strumento
- Claude · Codex (assistenti di codice e design)
- Fase
- Esplorazione di varianti, scaffolding dei componenti e confronto architetturale
- Contributo umano
- Design system atomico in Figma, modello dati, criteri di accessibilità e coerenza
- Risultato dell’IA
- Varianti dei componenti e strutture candidate da esaminare
- Criteri di selezione
- Chiarezza, accessibilità, coerenza con il sistema, evidenze sugli utenti e fattibilità tecnica
- Limiti individuati
- L’IA non decide gerarchie o flussi: propone. Ogni risultato viene verificato rispetto al prototipo e al modello dati
- Decisione finale
- Decisione umana in ogni fase. L’IA accelera; il giudizio guida
Implementazione
Come responsabile UX/UI ho definito il linguaggio visivo e la struttura del sistema condiviso. Nello sviluppo ho portato in Angular i flussi di registrazione, profilo e modifica del profilo, curando la corrispondenza con le versioni desktop e mobile.
Il prodotto completo collegava Angular, un’API Node/Express e MySQL. Backend e database erano responsabilità di un altro membro del team; il mio lavoro era progettare l’esperienza e collegare la mia parte del frontend ai contratti del gruppo.
Durante l’implementazione abbiamo dovuto adattare il design alla struttura condivisa dell’applicazione, alle dipendenze dell’API e ai componenti sviluppati da altre persone del team.
Evidenze
Le evidenze che posso mostrare combinano la revisione accademica del progetto finale, i test funzionali dei flussi per ruolo e una valutazione euristica rispetto ai principi studiati nel master UX/UI. Mi hanno aiutato a verificare la corrispondenza tra design, codice e dati, senza presentare l’esercizio accademico come validazione commerciale.
Dal prototipo al componente
Organizzazione 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
Codice · evidenza di implementazione
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 reale del progetto finale del master: l’atomo Badge in Angular (signals). Le sue varianti tipizzate corrispondono letteralmente all’enum MySQL — dal prototipo al componente e dal componente al dato.
BadgeEstado = 'Borrador' | 'Publicado' | 'En_revision' | 'Retirado' | 'Reservado' | 'Vendido' ← enum MySQL della tabella productos
Evidenze
Il lavoro, aperto alla revisione.
Il prototipo è una parte del processo: documenta il sistema, le decisioni e i flussi che sostengono il prodotto.
Apri il design in FigmaCosa ho imparato
Ho imparato che l’atomizzazione in Figma porta valore solo se supera il passaggio allo sviluppo: la struttura del frontend deve conservarne la logica.
Il flusso di moderazione condiziona il modello dati anche se è quasi invisibile nella homepage del prodotto.
Tipizzare il frontend rispetto agli enum del database mi ha aiutato a delimitare gli stati che l’interfaccia non dovrebbe consentire.
Domanda aperta:In che modo l’architettura dell’informazione influisce sull’adozione di un sistema gestionale da parte di ruoli non tecnici?
Contatti
Parliamone.
Se pensi che il mio modo di lavorare sia adatto al tuo team, o hai un prodotto o una ricerca che vorresti sviluppare, mi piacerebbe saperne di più. Raccontami di cosa hai bisogno e a che punto sei. Leggerò personalmente il tuo messaggio.
Puoi trovarmi anche su LinkedIn