Adresse email copiée
Mathieu, product designer depuis plus de 12 ans basé à Paris. J'ai conçu des interfaces et réfléchi à des solutions pour tout type de secteur, de la plateforme technique basée sur l'IA à l'e-commerce. Cette ouverture m'a permis d'élargir mes compétences et d'être capable de créer n'importe quelle interface.
En dehors du travail, l'essentiel de mon temps va à ma famille : ma compagne, nos 2 enfants et notre chien. Je passe le temps restant à jouer au tennis, faire du vélo et cuisiner.
Clients
Alien Intelligence
Alias
Sofinco
Scaleway
Mozza
Effinity
JobTeaser
Blablacar
Simplifield
KissKissBankBank
Cheerz
Pages Jaunes
Compétences
Product Design
User Research & Discovery
Architecture de l'information
Prototypage & tests utilisateurs
Stratégie produit
Design system
Motion design
Ecouter.
Concevoir.
Ajuster.
Depuis plus de 12 ans, j'aide des start-ups et scale-ups à délivrer des produits qui font sens, de la recherche jusqu'au pixel.
Mathieu Manchin
Créateur d'interfaces
A PROPOS
ME CONTACTER
{{ c.label }}
{{ c.years }}
Alien Intelligence — depuis 2025
Concevoir de zéro une marketplace bilatérale, seul designer à bord
WEB
SAAS
B2B
RÔLE
Founding designer
DURÉE
Depuis 2025, en cours
PÉRIMÈTRE
Discovery, UX, UI, design system
Problème
Les équipes AI manquent de données licenciées et prêtes à l'emploi : trouver un dataset, négocier les droits, valider la conformité, c'est 3 à 6 mois dans le meilleur des cas. En face, les détenteurs de données n'ont aucun outil simple pour les monétiser sans s'exposer juridiquement.
Challenge
Deux profils aux besoins opposés dans une seule interface, sans équité initiale entre supply et demande. Il fallait un produit assez cohérent pour convaincre les deux côtés d'y venir en même temps.
Approche
La discovery avant tout écran. Cinq proto-personas issus du terrain et de sessions de co-design avec deux partenaires, des deux côtés du marché : data consumers (développeurs AI, ingénieurs ML) et data owners (startups tech, éditeurs de contenu). Une user story map par segment pour repérer les moments de valeur et les frictions les plus coûteuses.
Priorisation : le MVP cible les profils les plus autonomes des deux côtés, ceux qui évaluent et adoptent sans cycle d'achat long. Le protocole MCP a émergé des besoins des deux camps, sans qu'on l'impose.
L'architecture reflète cette dualité : une navigation structurée par intention, ce que je publie (Clusters, Workflows, MCP), ce que je consomme (Marketplace, Consumption).
Décisions
Naviguer par intention plutôt que par type d'objet. L'alternative, une arborescence par entité (datasets, workflows, accès), était plus simple à construire et reflétait le modèle de données. Mais elle obligeait chaque profil à traverser des écrans qui ne le concernaient pas. J'ai tranché pour deux territoires distincts : ce que je publie, ce que je consomme. Coût assumé : quelques objets apparaissent deux fois, avec deux traitements différents.
Un seul produit, pas deux applications. Séparer supply et demande aurait clarifié chaque parcours, mais cassé l'effet marketplace : sans preuve visible de l'autre côté du marché, aucun des deux ne s'engage. Le compromis a été de garder une coquille commune et de faire basculer le contenu selon l'intention.
Ne pas dessiner l'onboarding en premier. Contre-intuitif sur un produit sans utilisateurs : j'ai commencé par les écrans de valeur (le dataset publié, la requête facturée), pour que l'onboarding n'ait plus qu'à mener jusqu'à eux au lieu de les préfigurer.
Résultat
Un MVP couvrant tout le cycle data owner : onboarding guidé, clusters et datasets, workflows et accès MCP, revenus et monitoring de la consommation. Côté data consumer, une marketplace de discovery avec pricing à la requête et datasets certifiés par catégorie.
Apprentissages
En solo designer, la tentation de designer pour valider une solution déjà en tête est permanente. J'ai appris à taguer chaque insight avec sa source, et à distinguer ce qui vient du terrain de ce qui vient de l'intuition.
La marketplace bilatérale est l'un des modèles les plus durs à servir dans une interface unique : chaque décision de navigation structure différemment le mental model des deux profils. C'est un arbitrage permanent entre cohérence produit et clarté pour chacun.
Projets suivants
{{ o.label }}
{{ o.title }}
alias.studio — depuis 2024
Concevoir de zéro un studio IA et sa marketplace, founding designer
WEB/MOBILE
MARKETPLACE
B2B2C
Problème
Les artistes n'ont aucun moyen de contrôler l'utilisation de leur style à l'ère de l'IA générative, ni de le monétiser. Alias.studio leur donne les outils pour entraîner un modèle sur leur propre travail, le certifier sur la blockchain, et le licencier à des collectionneurs ou des entreprises.
Produit
Deux interfaces dans un seul produit : un studio pour les artistes (entraînement du modèle, test & refine, deployment, gestion du portfolio) et une marketplace pour les acheteurs (discovery, génération en langage naturel, achat de droits). Un an de conception from scratch en tant que founding designer.
Approche
Partir des deux journeys séparément avant de les assembler. Côté artiste : rendre un process technique (entraîner un modèle) accessible à des créatifs non-développeurs. Côté acheteur : permettre à des entreprises de générer des visuels à leurs attentes sans expertise prompt. La difficulté principale était de maintenir la cohérence entre les deux interfaces tout en gardant chaque expérience simple pour son propre utilisateur.
Apprentissages
On peut bien designer un mauvais timing. Le marché NFT s'est effondré pendant le développement. Les artistes, ciblés en priorité, sont précisément le groupe le plus méfiant vis-à-vis de l'IA. Ce projet m'a appris à distinguer le problème de design du problème de marché : le produit est solide, c'est le contexte qui a bougé.
Projets suivants
{{ o.label }}
{{ o.title }}
Scaleway — 2022
Concevoir de zéro la gestion des droits d'accès aux ressources cloud
WEB
CLOUD SERVICE
B2B
Problème
Dans un environnement cloud partagé, la gestion des accès était binaire : un membre d'équipe avait accès à tout, ou à rien. Pour des entreprises qui font tourner des infrastructures critiques avec des équipes aux responsabilités distinctes, c'est un risque de sécurité réel et un frein à la collaboration.
Challenge
Concevoir from scratch un système de gestion des droits d'accès complet, sans existant sur lequel s'appuyer, seul designer face à une équipe technique exigeante. Mon rôle était aussi de challenger les inputs de la user research, d'identifier ce qui manquait, en restant suffisamment simple pour qu'un administrateur non-technique puisse s'en emparer.
Approche
Avant de toucher au moindre écran, benchmark conséquent des systèmes IAM existants sur le marché. En parallèle, analyse et challenge des données récoltées en amont. De là, une série d'itérations avec l'équipe produit et technique pour s'assurer que ce qu'on designait était implémentable sans compromis sur l'expérience. Prototype testé avec de vrais clients, ajusté, validé. Puis handoff et mise en production.
Impact
Les user tests ont confirmé que même un process complexe comme la création de policies était compris et navigable de manière autonome. Un signal fort sur la clarté de l'architecture d'information. J'ai mis en place un handoff détaillé basé sur une global view permettant à toute l'équipe de s'approprier la solution sans friction.
Apprentissages
Travailler sur un domaine aussi technique que l'IAM m'a forcé à développer une vraie compréhension des mécaniques sous-jacentes avant de designer quoi que ce soit. Confirmation d'une conviction : les utilisateurs préfèrent des étapes claires et découpées à un formulaire monolithique. La progression rassure.
Projets suivants
{{ o.label }}
{{ o.title }}
BlaBlaCar — 2021 - 2022
Unifier et structurer le design system cross-platform web et mobile
E-COMMERCE
DESIGN SYSTEM
PRODUCT DESIGNER
Problème
Des composants disparates entre web et mobile, pas de référentiel commun. Chaque équipe réinventait les patterns à sa façon.
Approche
Audit de l'existant, définition des tokens, construction d'une bibliothèque de composants partagée et gouvernance du système.
Apprentissages
Un design system n'est pas un livrable, c'est un produit. Il faut autant de soin sur la documentation et l'adoption que sur les composants eux-mêmes.
Projets suivants
{{ o.label }}
{{ o.title }}
SimpliField — 2017 à 2021
Refondre une plateforme retail mobile et web et bâtir son design system
WEB/MOBILE
SAAS
B2B
Produit
Deux ans de collaboration continue : refonte visuelle complète, création et maintenance d'un design system, et delivery régulier de nouvelles features sur mobile et web pour la plateforme retail operations.
Approche
Mission de refonte qui s'est transformée en collaboration longue durée : création du design system, delivery régulier de nouvelles features, et sessions de discovery avec les product owners pour cadrer les priorités.
Apprentissages
Travailler seul sur un produit en croissance force une rigueur sur le craft et la documentation. La continuité sur 2 ans permet un niveau de maîtrise du produit rare en freelance.
Projets suivants
{{ o.label }}
{{ o.title }}