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.
Il preambolo finisce. Il prodotto comincia.
Dal sistema all’esperienza.
Decisioni, componenti e codice reale del marketplace.Problema
Ho iniziato da una domanda, non da una schermata: che cosa deve vedere ogni ruolo per agire con criterio in un marketplace? Acquirenti, moderatori e amministratori osservano lo stesso prodotto, ma prendono decisioni diverse.
Abbiamo esaminato schemi comuni — scheda prodotto, stati di vendita e segnali sul venditore — per capire quali informazioni sostengono 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. Non ho trattato il prodotto come una schermata isolata: ogni stato cambia chi può fare cosa.
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.
Le differenze tra i ruoli sono emerse subito nelle intestazioni: non serviva un header generico, ma accessi coerenti con ogni permesso. Ho usato questa distinzione per allineare la gerarchia visiva a ciò che ogni persona può consultare o gestire.
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
L’IA è stata integrata come acceleratore documentato, non come autrice. È stata usata per esplorare varianti dei componenti, velocizzare lo scaffolding ripetitivo e confrontare scelte architetturali; la decisione finale è rimasta umana in ogni fase, valutando 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.
L’implementazione ha rivelato la distanza tra un prototipo ideale e un prodotto collettivo: vincoli della struttura applicativa condivisa, dipendenze dall’API e componenti sviluppati da persone diverse. Questa negoziazione fa parte del caso, non viene nascosta.
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