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.
Le préambule s’achève. Le produit commence.
Du système à l’expérience.
Décisions, composants et code réel de la place de marché.Problème
J’ai commencé par une question, pas par un écran : que doit voir chaque rôle pour agir avec discernement dans une marketplace ? Acheteurs, modérateurs et administrateurs regardent le même produit, mais prennent des décisions différentes.
Nous avons examiné les schémas habituels — fiche produit, états de vente et signaux concernant le vendeur — pour comprendre quelles informations soutiennent chaque parcours. Cette analyse a attiré mon attention sur le flux 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. Je n’ai pas traité le produit comme un écran isolé : chaque état change qui peut faire quoi.
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.
La différence entre les rôles est vite apparue dans les en-têtes : il ne fallait pas un en-tête générique, mais des accès adaptés à chaque permission. J’ai utilisé cette distinction pour aligner la hiérarchie visuelle sur ce que chaque personne peut consulter ou gérer.
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
L’IA a été intégrée comme accélérateur documenté, et non comme auteur. Elle a servi à explorer des variantes de composants, à accélérer les structures répétitives et à confronter les choix d’architecture ; la décision finale est restée humaine à chaque phase, en considérant clarté, accessibilité, cohérence avec le système et 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.
L’implémentation a révélé l’écart entre un prototype idéal et un produit collectif : contraintes de la structure applicative partagée, dépendances à l’API et composants développés par différentes personnes. Cette négociation fait partie du cas ; elle n’est pas dissimulée.
É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