Contexte et architecture
Un même produit. Trois façons de décider.
Acheteurs, vendeurs et modérateurs partagent le système, mais ont besoin de permissions, de signaux et de parcours différents.
Étude de cas
Buy&Sell Marketplace
Dans une marketplace construite en équipe, j’ai relié la direction UX/UI, le système de design et l’implémentation frontend dont j’étais responsable.
- 3 rôles
- permissions et parcours différenciés
- Figma → Angular
- système transposé en composants
- Full stack
- interface connectée à une API et aux données
Collaboration : Projet réalisé en équipe dans le cadre du mémoire de master ; mon travail d’auteur se limite à la contribution décrite dans cette étude de cas
Projet académique fonctionnel. Il n’est présenté ni comme un produit commercial ni comme un travail individuel.
Une identité qui devient un produitDe la matière à la place de marché.
Système de design
Les fondations prennent forme.
Tokens, navigation, états et composants sont organisés avant la construction des écrans.
Expérience produit
Explorer, comprendre et agir.
L’interface transforme le catalogue, la confiance et l’état de chaque article en choix compréhensibles.
Produit implémenté
Le système résiste au passage au développement.
Figma définit le langage ; Angular, Node et MySQL montrent son fonctionnement avec des composants, des permissions et des données réelles.
Comment Buy&Sell a été développé.
Du système à l’expérience.
Décisions, composants et code réel de la place de marché.Problème
Que doit voir chaque rôle pour prendre des décisions éclairées dans une marketplace ? Acheteurs, modérateurs et administrateurs regardent le même produit, mais prennent des décisions différentes.
Avant de concevoir les écrans, nous avons étudié les besoins de chaque rôle. Nous avons examiné les schémas habituels — fiche produit, états de vente et informations sur le vendeur — pour comprendre de quelles informations chaque parcours avait besoin. Cette analyse a attiré mon attention sur le parcours de modération, où il fallait décider ce qui serait affiché ou bloqué.
À partir de cette lecture, nous avons défini un cycle d’états — brouillon, publié, en révision, retiré, réservé et vendu — qui conditionne le modèle de données et l’expérience de chaque rôle. Chaque état détermine qui peut consulter, modifier ou gérer le produit.
Méthodes :Analyse comparative de marketplaces de référence · Hypothèses utilisateur par rôle : acheteur/vendeur, modérateur, administrateur · Architecture de l’information et carte des états du produit · Plan du site et parcours par rôle avant de dessiner le moindre écran.
Système
Dans Figma, j’ai organisé le système en atomes, molécules et organismes pour parler des variantes et des états avant d’ouvrir Angular. Badge, bouton, carte, recherche et panneau ont été conçus comme des éléments devant conserver la même logique dans le code.
J’ai conçu des en-têtes avec des accès différents selon les permissions de chaque rôle, pour que chaque personne puisse trouver les options auxquelles elle avait accès.
Le prototype navigable nous a permis de parcourir les flux par rôle, de repérer les décisions en suspens et d’ajuster la structure avant d’implémenter mes parties du frontend.
L’IA dans le processus
Nous avons utilisé l’IA pour explorer des variantes de composants, générer des structures de code répétitives et évaluer des choix d’architecture. Nous avons documenté son utilisation et l’équipe a pris les décisions finales en examinant la clarté, l’accessibilité, la cohérence avec le système et la faisabilité technique.
- Outil
- Claude · Codex (assistants de code et de design)
- Phase
- Exploration de variantes, structuration des composants et confrontation de l’architecture
- Contribution humaine
- Système de design atomique dans Figma, modèle de données, critères d’accessibilité et de cohérence
- Résultat de l’IA
- Variantes de composants et structures candidates à examiner
- Critères de sélection
- Clarté, accessibilité, cohérence avec le système, éléments issus des utilisateurs et faisabilité technique
- Limites identifiées
- L’IA ne décide pas des hiérarchies ni des parcours ; elle propose. Chaque résultat est confronté au prototype et au modèle de données
- Décision finale
- Décision humaine à chaque phase. L’IA accélère ; le discernement dirige
Implémentation
En tant que responsable UX/UI, j’ai défini le langage visuel et la structure du système partagé. En développement, j’ai implémenté dans Angular les parcours d’inscription, de profil et de modification du profil, en veillant à leur correspondance avec les versions ordinateur et mobile.
Le produit complet reliait Angular, une API Node/Express et MySQL. Un autre membre de l’équipe était responsable du backend et de la base de données ; mon travail consistait à concevoir l’expérience et à connecter ma partie du frontend aux contrats de l’équipe.
Pendant l’implémentation, nous avons dû adapter le design à la structure partagée de l’application, aux dépendances de l’API et aux composants développés par d’autres membres de l’équipe.
Éléments probants
Les éléments que je peux montrer associent l’évaluation académique du projet de fin de master, des tests fonctionnels des parcours par rôle et une analyse heuristique fondée sur les principes étudiés dans le master UX/UI. Ils m’ont permis de vérifier la correspondance entre design, code et données sans présenter l’exercice académique comme une validation commerciale.
Du prototype au composant
Organisation du système
- 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 · preuve d’implémentation
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
Composant réel du projet de fin de master : l’atome Badge dans Angular (signals). Ses variantes typées correspondent exactement à l’enum MySQL — du prototype au composant, puis du composant à la donnée.
BadgeEstado = 'Borrador' | 'Publicado' | 'En_revision' | 'Retirado' | 'Reservado' | 'Vendido' ← enum MySQL de la table productos
Éléments de preuve
Le travail, ouvert à la critique.
Le prototype est une partie du processus : il documente le système, les décisions et les flux qui soutiennent le produit.
Ouvrir le design dans FigmaEnseignements
J’ai appris que l’atomisation dans Figma n’apporte de valeur que si elle résiste au passage au développement : la structure du frontend doit conserver cette logique.
Le parcours de modération conditionne le modèle de données, même s’il apparaît à peine sur la page d’accueil du produit.
Typer le frontend à partir des enums de la base de données m’a aidé à limiter les états que l’interface ne devrait pas autoriser.
Question ouverte :Comment l’architecture de l’information influence-t-elle l’adoption d’un système de gestion par des personnes occupant des rôles non techniques ?
Contact
Parlons-en.
Si ma façon de travailler vous semble adaptée à votre équipe, ou si vous souhaitez développer un produit ou un projet de recherche, je serais heureux d’en savoir plus. Dites-moi ce dont vous avez besoin et où vous en êtes. Je lirai votre message personnellement.
Vous pouvez aussi me retrouver sur LinkedIn