Frédéric Oglaza

Craft product designer

Frédéric Oglaza
Portrait de Frédéric Oglaza, casquette et sweat à capuche

Je suis designer spécialisé dans les interfaces techniques

  • 15

    ans de pratique

    depuis 2k11

  • 3

    produits déployés

    depuis 2k21

  • 2

    design systems implémentés

    depuis 2k22

  • 12

    projets grand compte

    entre 2k16 → 2k21

  • 6

    formations données

    depuis 2k17

  • 6

    secteurs traversés

    culture, énergie, web3, data science, marketing et IA

ExperienceBuilder

  • Nouveau workflow

    Ce workflow centré sur les hypothèses de solution et le prototypage rapide permet une vélocité d'échange inédite avec le business.

  • Le retour au craft

    Les nouveaux outils permettent de capitaliser sur la recherche design, via le prototype et les utilisateurs. Le contact avec le business est plus fluide.

    Frédéric Oglaza dessine des wireframes à la main, devant un mur de post-it

  • Un seul langage convergent

    Au-delà du design system, toutes les ressources convergent pour améliorer la vélocité de toute l'organisation.

    • Design system
    • UX repository
    • Skills internes
    • Connaissance métier

Je fabrique des interfaces cohérentes pour les utilisateurs, rationnelles pour la tech et à forte valeur ajoutée pour le business

  1. /projets

    Passer d'une marketplace à une plateforme de productivité

    Comment une restitution terrain a cadré la roadmap et débloqué quatre chantiers produit.

    • #ux-research
    • #ux-strategy
    • #product-design

    Contexte

    La direction produit avait tranché le cap : sortir Kazaar du modèle e-shop pour en faire une plateforme de productivité.

    Objectif : changer la perception du produit pour changer le cap business. En 2025, Kazaar doit améliorer la productivité des chefs de projet Altavia d'au moins 10 %.

    Analyse des personas

    J'ai mené une étude sur tout l'écosystème qui gravite autour de Kazaar et d'Altavia. Des entretiens sur le terrain, auprès de ceux qui vivent les frictions au quotidien : chefs de projet inStore, Procurement, GBD, agences, fournisseurs, clients internationaux.

    Tableau à sept étapes, de l'expression de la demande au reporting. Pour chacune : sa description, les personas concernés, leurs objectifs, leurs irritants, leurs besoins et leurs outils de communication.
    Global experience mapping

    Comprendre les points de frictions

    Trois points de friction majeurs sont identifiés dans le workflow des différents acteurs de la chaîne de production.

    • La phase de définition du projet. Avec d'un côté un client qui pose des demandes floues, de l'autre un chef de projet avec un vocabulaire technique.
    • Pas d'espace dans la plateforme pour les acteurs externes tels que les agences ou les fournisseurs.
    • La fluidité des échanges et l'historique au cœur des problèmes de productivité.
    Schéma des acteurs. Le client transmet un brief au chef de projet, l'agence lui fournit le design, les fournisseurs, la logistique et le livreur assurent la production. Trois alertes marquent les frictions : le brief, le design et le bon de livraison qui revient au chef de projet.

    Mes solutions étaient réparties en plusieurs axes : la communication, l'accès aux tâches, l'organisation des projets et un module de prise de brief

    Task dashboard

    Une première page pour les chefs de projet, une vue sur l'ensemble des workflows en cours, qui permet un accès rapide aux actions critiques.

    Tableau de bord de Kazaar : les compteurs de commandes assignées, de tâches urgentes et en retard, puis les commandes classées par étape, de la nouvelle demande à la livraison, avec leur action à mener.

    Inbox

    Un service d'échange à l'échelle micro pour gérer l'ensemble des allers-retours est mis en place avec une page « inbox » pour centraliser les échanges et les notifications.

    Page Inbox de Kazaar : à gauche, les dernières activités, nouvelles commandes et commentaires, chacune avec son auteur et son workspace ; à droite, la commande ouverte et ses produits, chacun avec l'action en attente, et sous le premier, une demande de modification et son commentaire.

    Brief builder

    L'endroit où Altavia pouvait gagner énormément en productivité, c'était sur la prise de brief. La création d'un bot IA pouvant traduire des besoins client en brief technique était la clé de l'évolution pour Kazaar.

    Bot de prise de brief de Kazaar : l'assistant guide la création d'une commande par questions et réponses, et le récapitulatif se remplit à côté : produit, date et lieu de livraison.

    Refonte du pipeline produit

    La visualisation de l'avancement des pipelines produit d'un projet était une clé de la productivité des équipes clientes comme broker.

    Page d'un projet dans Kazaar : pour chaque produit, son pipeline en quatre étapes, demande, commande, production et livraison, avec l'avancement de chacune et l'action à mener mise en avant.

  2. Un workflow design augmenté à l'IA

    Passer de 0 à 100 en 2 semaines, c'était le but de ce « case-study ». Utiliser toutes les nouvelles ressources à ma disposition pour proposer un prototype pour un « proof-of-concept ».

    • #ia-workflow
    • #prototype
    • #case-study

    2026

    /projets

    Un workflow design augmenté à l'IA

    Passer de 0 à 100 en 2 semaines, c'était le but de ce « case-study ». Utiliser toutes les nouvelles ressources à ma disposition pour proposer un prototype pour un « proof-of-concept ».

    • #ia-workflow
    • #prototype
    • #case-study
    Tester Admiralty

    Discovery

    J'ai utilisé Perplexity pour comprendre rapidement le vocabulaire, les acteurs, les pratiques et les problèmes du secteur. Cette recherche documentaire ne remplace pas les entretiens ni la validation utilisateur. Elle sert à formuler plus vite de meilleures hypothèses et de meilleures questions.

    Premier livrable : un lexique. Tant qu'on ne nomme pas les choses comme le métier les nomme, on ne peut pas nommer correctement un écran.

    Rapport Perplexity : cinq opportunités business, de l'orchestration RH vers IT à l'expérience IT simplifiée, puis le POC recommandé, un parcours en six étapes, du profil à l'offboarding.
    Extrait du rapport Perplexity
    Lexique du domaine : les quatre familles d'outils (ITAM, SaaS Management, IAM, MDM) avec leurs objectifs et leurs acteurs, des recommandations pour Admiralty, et à côté le fichier Markdown du premier prompt.
    Préparation du premier prompt
    Planche Logo de la charte d'Admiralty : le symbole et le logotype en Geist, leurs versions positive, négative et symbole seul, et quatre couleurs, Ink, Glacier, Tonic clair et Tonic.
    Création d'une charte graphique « simple » pour poser une identité

    Passer du design au code par petites décisions

    Structuration du projet Claude Code pour avancer avec une librairie existante, une stack adaptée, des données mockées avec un « faux back » pour garantir une expérience de test cohérente.

    Schéma de mise en place : VS Code, les plugins Claude Code, puis la description du projet, d'où découlent la stack technique, le setup de Chakra UI et de ses tokens, celui de GitHub et celui d'un serveur local.

    Notion devient la source de vérité sur la gestion du projet : itération et priorisation

    Dans un workflow conversationnel, le contexte peut rapidement se perdre dans l'historique des échanges. J'ai donc traité la mémoire du projet comme un livrable design : décisions, contraintes, tâches, arbitrages et éléments archivés ont été conservés dans des fichiers Markdown et une base Notion.

    Base Notion « Admiralty Task DB » en kanban : colonnes Backlog, À faire, Fait et Archivé, chaque carte avec son identifiant, son type et sa priorité.

    Une stack complète qui se setup rapidement et qui permet les itérations

    Plusieurs choses sont nouvelles pour les designers. Au-delà de pouvoir générer des prototypes fidèles, le prototype ne devient pas obsolète avec les modifications, il peut devenir « vivant ». Grâce à GitHub et Notion, on peut itérer et versionner tout en partageant à toute son organisation l'état du prototype.

    Schéma de la stack : Claude Code dans VS Code, relié à la base de code, entouré de Perplexity pour la discovery, Figma pour l'identité visuelle, Chakra comme librairie UI, Notion pour la gestion de projet, GitHub pour le versionning et un FTP.

    L'IA au sein du produit

    Un challenge que je me suis donné, c'est d'intégrer l'IA pour répondre aux problématiques réelles des utilisateurs.

    Uno est un assistant contextuel intégré aux différents écrans du produit. Il ne se contente pas de répondre à une question : il fait remonter une information pertinente au moment où elle peut aider une décision.

    Accueil d'Uno : une phrase de synthèse sur le parc, 16 comptes encore actifs après un départ et 72 131 € de matériel sans utilisateur, un champ de question et quatre actions suggérées.
    Point de départ de l'application.
    Écran Software spend avec la revue d'Uno : 29 944 € de licences par mois, le détail des sièges inutilisés par cause, l'action proposée de récupérer 36 sièges HubSpot, puis la liste des applications.
    À tous les niveaux de l'application, Uno permet la réalisation de tâches essentielles, faisant gagner un temps précieux aux équipes IT.

    Voir le workflow en action

    L'article décrit les principes. La vidéo montre les boucles de travail réelles : comment le contexte est transmis, comment l'IA est cadrée, comment les sorties sont vérifiées et comment le prototype évolue.

  3. Un design system pour scale le produit

    Chez Kazaar, j'ai pu lead le gros projet du design system. Entre refonte, alignement avec la tech, mise au standard et déploiement, voici quelques problématiques taclées.

    • #design-system
    • #design-tokens
    • #atomic-design

    2025-2026

    /projets

    Un design system pour scale le produit

    Chez Kazaar, j'ai pu lead le gros projet du design system. Entre refonte, alignement avec la tech, mise au standard et déploiement, voici quelques problématiques taclées.

    • #design-system
    • #design-tokens
    • #atomic-design
    Supernova, espace du design system de Kazaar : la page des tokens de typographie, en cinq groupes (body, subtitle, title, display, caption), chaque token avec sa taille, son interlignage, sa police, Open Sans ou Lexend, et sa graisse.

    Contexte

    À mon arrivée chez Kazaar, la gestion du design était assez chaotique. Chaque designer faisait comme il voulait, pas d'alignement avec la tech. Aucune définition de tokens ni de règle d'usage. J'ai réussi à convaincre la direction de progressivement migrer vers un design system qui allait permettre de scale le produit dans le temps.

    Étape 1 : convaincre les équipes

    Répondre au pourquoi, comment, quand. Voilà ce que j'ai présenté au CEO, au CTO et au lead developer. Le but était que le design s'intègre parfaitement à l'écosystème de la tech, de façon à travailler ensemble et à définir une source de vérité commune.

    Schéma du circuit des tokens. Le designer maquette avec les variables Figma et construit le design system dans le plugin Tokens Studio, qui les exporte et pousse les tokens vers Bitbucket et Supernova. Depuis Bitbucket, Style Dictionary produit la config Tailwind des développeurs. Designer et développeurs documentent dans Supernova.
    Roadmap du design system, de Q1 à Q3 2025. Équipe : définition, initialisation du design system v2, puis passage de la librairie au design system, utilisable par une équipe externe dès Q2. Design : composants CORE, puis documentation des fondations et des composants. Développement : design tokens, refonte des composants CORE, documentation des fondations et des composants, et composants spécifiques.

    Étape 2 : mise en place des design tokens

    Tokens Studio est un plugin Figma qui permet de faire le lien entre les designers et un espace de stockage : GitHub par exemple. Il permet de maintenir l'ensemble des thèmes et des décisions design.

    Plugin Tokens Studio dans Figma : à gauche, les sets de tokens (primitives, alias de couleur, de taille et de typographie, thèmes clair et sombre de Kazaar) ; à droite, les tokens de taille et d'espacement, puis les palettes de couleurs.
    Structure d'un nom de token en six segments : catégorie, concept, variante, propriété, état, seconde variante. En dessous, les tokens d'épaisseur de bordure d'un champ de saisie, à côté du champ en erreur.

    Étape 3 : librairie et documentation

    Page Buttons de la librairie Figma : le bouton en trois styles (contained, outlined, ghost) et trois tailles, pour chaque couleur (primary, secondary, neutral, success) et chaque état (default, hover, active, disabled).
    Librairie graphique dans Figma
    Documentation Supernova du composant Textfield : liens vers Storybook et Figma, anatomie annotée (label, champ, message d'aide), puis ses propriétés.
    Supernova, un outil de documentation et de gestion de tokens

    Gouvernance

    Un des points essentiels pour gouverner un design system, c'est de limiter au maximum l'ajout de nouveaux composants, d'autant plus quand on est dans un environnement sans équipe dédiée. Et pour cela, il y a une méthode : accompagner les designers à se poser des questions sur leurs patterns design.

    Arbre de décision pour créer un composant. S'il existe dans la librairie, on l'utilise. Sinon, s'il fait partie des composants Tailwind, on le standardise avec la doc Tailwind et on l'ajoute à la page CORE. Sinon, s'il peut servir à d'autres projets, une décision collégiale l'ajoute à la librairie KDS, ou à défaut à la librairie spécifique du projet.

  4. IAM, concevoir une architecture produit complexe

    Passer d'un produit où les utilisateurs et leurs droits sont pilotés par les CSM à une interface multi-niveaux dont les rôles et les permissions sont gérés directement par les organisations des parties prenantes ? Comment gérer les accès cross-organisations ?

    • #architecture
    • #ux-research
    • #auth
    • #RBAC

    2026

    /projets

    IAM, concevoir une architecture produit complexe

    Passer d'un produit où les utilisateurs et leurs droits sont pilotés par les CSM à une interface multi-niveaux dont les rôles et les permissions sont gérés directement par les organisations des parties prenantes ? Comment gérer les accès cross-organisations ?

    • #architecture
    • #ux-research
    • #auth
    • #RBAC
    Admin de Kazaar, utilisateurs de l'organisation Luxury Brands. Par-dessus, le panneau des rôles d'un utilisateur : un rôle par organisation (BrightWave Cosmetics, Luxury Brands, Everyday Brands) et, dans Luxury Brands, un rôle par workspace.

    Contexte

    Les clients aux organisations de plus en plus complexes avaient un besoin clair : pouvoir gérer leurs utilisateurs et permissions directement depuis la plateforme. Ils voulaient aussi se connecter en SSO. Kazaar ne proposait ni l'un ni l'autre. Une refonte complète du workflow des utilisateurs était nécessaire. Rebuild de l'API IAM, nouveau parcours d'authentification, espace admin multi-niveaux et nouvelle architecture des permissions.

    Nouveau parcours d'authentification

    La partie la plus simple, pas la moins utile : elle a posé les bases de la collaboration entre le design et la tech. Les choix se sont faits ensemble.

    Quatre écrans de connexion de Kazaar : le mot de passe et la connexion SSO par domaine, chacun normal puis en erreur (mot de passe incorrect, domaine invalide, aucun fournisseur SSO pour ce domaine).
    Écran de création d'un nouveau mot de passe : les cinq règles à respecter, cochées une à une, et l'erreur sous la confirmation, « Passwords do not match ».

    Structurer une architecture multi-niveaux

    Kazaar, c'est 3 types d'accounts qui ont chacun leurs besoins et leur rôle dans la chaîne de production. Chacun a sa propre organisation interne et intervient à des endroits différents de la chaîne. La première décision fut de redonner la gouvernance des commandes à l'Advertiser et non au Broker, comme cela était le cas.

    Schéma de l'architecture des comptes. Advertiser, Broker et Supplier ont chacun leur compte et leurs organisations, reliées entre elles. L'organisation de l'Advertiser contient les workspaces, où se créent les commandes, auxquels Broker et Supplier accèdent. À gauche, qui fait quoi : le CSM Kazaar crée les comptes et les organisations, que leurs admins modifient ; le CSM et l'admin créent les workspaces ; les contributeurs créent et gèrent les commandes.

    Anticiper la collaboration entre les parties par le « partnership »

    Schéma du partnership : un compte Advertiser, son organisation et ses quatre workspaces, chacun avec ses commandes ; en face, un compte Broker et ses deux organisations. Par le partnership, l'Advertiser ouvre ses workspaces à des utilisateurs du Broker, chacun relié aux workspaces auxquels il a accès.
    Schéma pour comprendre visuellement la dynamique des droits entre les différentes parties
    Admin de Kazaar, onglet Partnership d'une organisation : les marques partenaires cochées, et le panneau « Org partnership » qui liste les utilisateurs partagés, avec un champ pour en ajouter et un bouton pour retirer chacun.
    Interface de gestion des droits de partnership

    Rendre les permissions accessibles et évolutives

    Rendre lisible et « friendly » la gestion des rôles et permissions. Un challenge qui a nécessité des tests utilisateurs et une formation des équipes.

    Onglet Roles & permissions du compte L'Oréal : la liste des rôles (Admin et Maker verrouillés, un rôle créé par l'utilisateur) et, pour le rôle choisi, une permission par interrupteur, regroupées par domaine : brief, catalogues, produits, livraison, commandes, épreuves, devis, rapports.

    Les difficultés d'une UX multi-niveaux

    À la difficulté d'apporter une interface claire sur un admin multi-niveaux s'ajoute la difficulté de rendre lisible l'héritage des rôles au fil de ces niveaux. Les admins du dessus ont des droits que ceux d'en dessous n'ont pas.

    Utilisateurs d'un workspace de La Roche-Posay : pour chacun, son e-mail, son rôle, hérité de l'organisation ou du compte, ou propre au workspace, et sa date d'ajout. Seuls les rôles propres au workspace se retirent à ce niveau.
    Deux panneaux de rôles côte à côte. Pour le premier utilisateur, le rôle Admin de la division Luxe descend sur ses trois workspaces, marqués « Inherit ». Pour le second, chaque workspace a son propre rôle. À droite, les trois niveaux, compte, organisation et workspace, avec le même choix : Admin, Maker ou aucun rôle.

  5. Starton, du web2 au web3

    Starton avait comme ambition d'apporter une couche web2 au web3 pour onboarder les développeurs sur cette technologie qui était en plein essor en 2024.

    • #web3
    • #ux
    • #branding

    2022-2024

    /projets

    Starton, du web2 au web3

    Starton avait comme ambition d'apporter une couche web2 au web3 pour onboarder les développeurs sur cette technologie qui était en plein essor en 2024.

    • #web3
    • #ux
    • #branding
    Plateforme Starton, activité d'un smart contract dans un projet NFT : la liste des transactions, chacune avec son hash, son émetteur, son état (réussie, échouée ou en alerte), son ancienneté et ses logs.

    Contexte

    Starton vient de lever 3,8 millions pour transformer son MVP en plateforme capable de scale. Je suis recruté peu après la levée pour transformer la marque et l'UX de la plateforme. Objectif : garantir un design pertinent pour ce domaine et poser toutes les bases pour développer le produit.

    Refonte de l'identité

    En parallèle du produit, j'ai doté Starton d'une identité de marque forte. Une typo Inktrap et grasse pour l'impact, un affinage du logo, des couleurs contrastées et le passage au dark mode. Enfin, une iconographie néo-brutaliste pour coller au caractère de la marque.

    Charte graphique de Starton, en cinq pages : le logo et sa signature « The web3 frameworks », l'échelle typographique, l'affiche d'une Pizza Dev Night, le visuel d'une soirée Beer & Web3 et des icônes isométriques, sur fond clair et sur fond sombre.

    Flow d'abonnement et de suivi de consommation de l'API

    La plateforme Starton était avant tout une interface de suivi et de pilotage de projet web3. Les clients consommaient l'API de Starton pour traiter un grand nombre de requêtes à la blockchain.

    Flow de passage à l'offre Team : la page Billing et ses cinq offres, de Developer à Custom, puis la fenêtre « Upgrade my plan », avec le formulaire de facturation ou, si elles sont déjà enregistrées, les informations de paiement, jusqu'au paiement validé.
    Dashboard d'un projet dont le quota est épuisé : l'alerte « Your project has been frozen » et un bouton pour gérer la limite, puis les services utilisés, la jauge des compute units, pleine, leur évolution sur le mois, la prévision de consommation avec un risque de gel élevé, et la consommation par service.

    Une plateforme developer first

    Fenêtre Withdraw en trois étapes : le wallet d'origine, l'adresse de destination et le choix de la blockchain, testnets et mainnets. À côté, le code de l'appel à l'API, en JavaScript, React, Python ou Go.
    L'interface permet de générer un code prêt à coller
    Page Developer, onglet API keys : un avertissement sur la sécurité des clés, puis trois clés, chacune avec son nom, sa valeur masquée à copier, son réseau, mainnet ou testnet, son expiration et sa date de création.
    Gestion des clés d'API

    Qui dit dev-tool, dit documentation

    La documentation de l'API, accompagnée des cas d'usage et de tutoriels ciblés sur les besoins principaux, était une des clés pour l'adoption et le développement de la plateforme.

    Documentation de Starton, page Smart contracts management : déployer, importer ou interagir avec un smart contract, une vidéo, trois tutoriels pour démarrer, les endpoints de l'API, puis des guides signés par l'équipe.
    Tutoriel avancé de la documentation, « How to sell NFTs to a list of approved addresses » : les prérequis, une note, les étapes et un extrait de code, avec à côté son auteur, Fred, product designer, et le sommaire.

    Les événements web3

    Afin de réunir les curieux du web3 et de transmettre autour de cette pratique, Starton participait à de nombreux événements spécialisés. Ici aussi, la présence visuelle était importante dans ce milieu.

    Visuel de la soirée Beer & Web3 de Starton, le 30 mai 2023 de 19 h à 21 h, 134 voie Georges Pompidou à Paris : le titre en grandes capitales et un bracelet aux couleurs de la soirée.
    Visuel du hackathon en ligne de Starton, du 21 au 24 novembre 2022, finale le 28 : des fenêtres en noir et blanc aux lettres pixelisées, des extraits de code de l'API, « Unleash web 3.0 » et une ampoule en fil de fer.
    Visuel d'une soirée Beer & Web3, le mardi 24 janvier 2023 de 18 h à 21 h au Player One, 224 rue Saint-Denis à Paris : un cube en 3D dans un tunnel de mots « Beer » et « Web3 ».

PrototypageRapide

  • ARCA : une nouvelle approche pour Kazaar

    Prototype pour imaginer une nouvelle UX de la plateforme qui réponde à l'ensemble des besoins formulés par les utilisateurs.

    Tester ARCA

  • Advanced Searchbar

    Naviguer dans un grand nombre de données peut s'avérer être compliqué. Les utilisateurs réguliers savent où ils veulent aller, cette searchbar leur permet de naviguer dans la donnée sans quitter la page où ils se trouvent. Le gain est autant du côté des utilisateurs que des ressources de serveur.

    Tester la searchbar

  • Design tokens documentation

    L'IA permet aujourd'hui de générer une documentation très satisfaisante sans qu'elle soit une source de perte de temps. Elle peut même être automatisée dans le workflow d'amélioration du design system.

    Voir la doc générée

OffWork