Start-up qui lance son SaaS
Une première version à concevoir sans dette d’interface : parcours testés, écrans clés et une bibliothèque légère qui grandira avec le produit.
Design UX/UI
et un design system qui tient dans le temps.
Le design UX/UI rend un logiciel évident : des parcours qui suivent la logique du métier, des écrans lisibles et des composants cohérents d’une page à l’autre. Nous concevons ces interfaces pour des éditeurs SaaS B2B comme pour des applications métier, puis nous les structurons en design system que vos développeurs réutilisent.
Concevoir avant de dessiner.
L’UX décide de ce que l’utilisateur doit faire et dans quel ordre ; l’UI décide de la façon dont il le voit. Le design UX/UI couvre les deux : architecture de l’information, parcours, wireframes, puis interface finale avec ses états vides, ses erreurs et ses chargements. Un écran soigné qui répond à la mauvaise question reste un mauvais écran, d’où l’ordre que nous suivons.
Le design system en est la suite logique. Il rassemble les composants, les tokens de couleur et de typographie, les règles d’usage et les exemples, dans Figma comme dans le code. Pour un éditeur qui ajoute sans cesse des fonctionnalités, il évite que chaque nouvel écran invente ses propres boutons, ses propres tableaux et ses propres messages d’erreur.
Ce service s’adresse aux équipes qui lancent un produit, à celles dont l’interface s’est fragmentée au fil des versions, et aux entreprises qui veulent un outil métier enfin agréable. Erreurs fréquentes : commencer par une maquette haute fidélité, copier une bibliothèque générique sans l’adapter au métier, ou livrer un design system sans documentation, que l’équipe finit par contourner.
Pour qui nous concevons.
Le design UX/UI répond à des besoins différents selon le stade du produit.
Éditeur dont l’interface s’est fragmentée
Plusieurs équipes, plusieurs époques, plusieurs styles. Nous inventorions l’existant, unifions les composants et refondons l’interface module par module.
Entreprise avec une application métier
Un outil interne utilisé des heures par jour, où chaque clic économisé compte. Nous le concevons à partir de l’observation des postes de travail.
Produit qui intègre de l’IA
Copilote, suggestions, automatisations : ces fonctionnalités demandent des écrans qui expliquent, rassurent et laissent la main à l’utilisateur.
Ce que nous concevons.
Du squelette de l’écran au composant documenté, chaque livrable prépare le suivant.
Architecture et parcours
L’organisation des menus, des objets et des tâches, testée sur papier avec vos utilisateurs avant de produire le moindre pixel.
Wireframes des écrans clés
Des maquettes en niveaux de gris pour valider le contenu, la hiérarchie et les actions, sans débat prématuré sur les couleurs.
Interface complète
Les écrans finaux avec tous leurs états : vide, chargement, erreur, droits limités, données longues. Ce sont souvent eux qui font la qualité perçue.
Design system documenté
Composants, tokens, règles d’accessibilité et exemples d’usage, synchronisés entre Figma et le code pour que vos développeurs gagnent en autonomie.
Prototypes testés avec vos utilisateurs
Des parcours cliquables dans Figma, soumis à quelques utilisateurs en atelier ou à distance, pour corriger avant de développer plutôt qu’après.
Du design au code
Nous pouvons aussi développer l’interface conçue : le design system devient alors une vraie bibliothèque de composants, et non une intention restée dans Figma.
Les livrables remis à votre équipe.
Tout est livré dans Figma et, si nous développons, directement dans le code de votre application.
- Une architecture de l’information et les parcours principaux, validés avec vos utilisateurs
- Les wireframes des écrans clés, annotés pour expliquer chaque choix de conception
- Des prototypes cliquables, utilisés pendant les tests utilisateurs
- L’interface haute fidélité de chaque écran, avec ses états vides, de chargement, d’erreur et de droits limités
- Une bibliothèque de composants Figma construite sur des variables et des design tokens
- Une documentation d’usage : quel composant employer, quand, et avec quels libellés
- Des règles d’accessibilité appliquées aux composants : contrastes, focus clavier, tailles de cible
- Un accompagnement de vos développeurs pendant l’intégration, ou le développement par notre studio
Un design system créé de zéro.
Des écrans cohérents reposent sur un système, pas sur la bonne volonté. Pour l’application Bouygues Telecom, utilisée par quinze millions de clients, Victor Michel, fondateur du studio, a construit un design system complet, tokens, composants et guidelines, maintenu tout au long du projet, après un card sorting mené avec des utilisateurs et plusieurs rounds de validation. C’est ce lien entre architecture, composants et usage réel que nous livrons.
Bouygues Telecom · Télécoms · Application mobile grand public · 2019–2020
- 15 M
- clients mobiles
- 0→1
- design system créé de zéro
Du wireframe au composant.
Une progression qui fige les décisions dans le bon ordre, de la plus structurante à la plus visuelle.
- 01
Comprendre le métier
Entretiens et observation des utilisateurs, inventaire des écrans existants, vocabulaire du domaine : on part de leur réalité, pas de la nôtre.
- 02
Structurer
Arborescence, parcours principaux et wireframes basse fidélité, discutés avec vos équipes et confrontés à quelques utilisateurs.
- 03
Mettre en forme
Interface haute fidélité, typographie, couleurs, iconographie et états de chaque écran, vérifiés pour la lisibilité et le contraste.
- 04
Industrialiser
Extraction des composants récurrents, documentation des règles et passation aux développeurs, avec un accompagnement pendant l’intégration.
Ce qu’il faut savoir sur le design UX/UI.
Les choix qui séparent une belle maquette d’un produit qui tient dans la durée.
Design system, UI kit, bibliothèque : ne pas confondre
Un UI kit est un ensemble de composants graphiques prêts à l’emploi. Une bibliothèque de composants les organise dans Figma ou dans le code. Un design system va plus loin : il ajoute les design tokens, les règles d’usage, le vocabulaire, les principes d’accessibilité et la manière de faire évoluer l’ensemble. Pour une start-up, un UI kit adapté au métier suffit souvent au départ. Dès que plusieurs designers ou plusieurs équipes de développement interviennent, seul un design system documenté empêche chaque module d’inventer ses propres règles.
Les design tokens, pont entre Figma et le code
Les design tokens nomment les décisions visuelles : couleurs, typographie, espacements, rayons, ombres. Organisés en niveaux, des valeurs brutes jusqu’aux usages sémantiques comme « texte secondaire » ou « fond d’alerte », ils permettent de changer un thème, d’ajouter un mode sombre ou un mode contraste élevé sans retoucher chaque écran. Dans Figma, ils prennent la forme de variables ; côté développement, ils sont exportés vers le code. Posés dès le début, ils simplifient chaque évolution de la marque ou du produit.
Concevoir des interfaces pour l’IA
Une fonctionnalité d’IA générative, ou un agent qui agit pour l’utilisateur, pose des questions de design nouvelles. Que montrer pendant que le modèle travaille ? Comment signaler une réponse incertaine ? Où l’utilisateur valide-t-il avant qu’une action parte ? Nous concevons ces écrans selon le principe de notre méthode CRAFT : l’humain reste dans la boucle. Concrètement, cela donne des suggestions placées dans l’écran de travail plutôt qu’un chatbot isolé, des sources visibles, des actions réversibles et une trace de ce que l’IA a proposé.
L’accessibilité n’est plus optionnelle
Depuis juin 2025, l’European Accessibility Act étend les exigences d’accessibilité à plusieurs catégories de produits et services numériques destinés aux consommateurs, avec pour référence technique la norme EN 301 549, qui reprend les WCAG. Même un logiciel B2B a intérêt à s’y préparer : ses utilisateurs travaillent sur des écrans variés, dans des conditions variées, et attendent une interface lisible. Intégrer contrastes, ordre de focus, tailles de cible et libellés explicites dans les composants du design system coûte peu ; corriger une application entière après coup coûte bien davantage.
Les mots font partie du design
Un bouton mal nommé, un statut ambigu ou un message d’erreur technique ruinent un écran bien composé. L’UX writing, c’est-à-dire le choix des mots de l’interface, fait donc partie de notre travail de design UX/UI : libellés d’action, statuts, aides contextuelles, écrans vides, confirmations. Nous partons du vocabulaire de vos utilisateurs, recueilli en entretien, plutôt que du jargon interne. Ces règles de rédaction rejoignent ensuite le design system, pour que les prochaines fonctionnalités parlent la même langue.
Qui conçoit votre interface ?
Les trois options les plus courantes pour un projet de design UX/UI et de design system, comparées honnêtement.
| Critère | Brutux Studio | Agence UX/UI classique | Designer UI freelance |
|---|---|---|---|
| Point de départ | Recherche utilisateur et parcours, avant toute maquette | Recherche puis design, selon le budget alloué | Souvent directement les maquettes |
| Design system | Tokens, composants et documentation, dans Figma et dans le code | Bibliothèque Figma, plus ou moins documentée | UI kit Figma, rarement documenté |
| Tests utilisateurs | Ateliers et tests sur prototype à chaque étape clé | Inclus dans les offres les plus complètes | Rares, faute de temps |
| Développement | Possible avec le même studio, design system compris | En général confié à une autre équipe | Rarement proposé |
| Interlocuteur | Un designer senior, sans intermédiaire | Chef de projet et équipe qui tourne | Un designer, seul |
| Durée type | 2 à 6 mois, par cycles de 6 semaines | Selon le périmètre | Selon la disponibilité |
Questions fréquentes.
Design UX/UI et design system : les réponses aux questions qu’on nous pose.
Quelle différence entre design UX et design UI ?
Le design UX traite la logique : quelles tâches, dans quel ordre, avec quelles informations. Le design UI traite la présentation : hiérarchie visuelle, composants, couleurs. Les deux se décident ensemble, mais l’UX vient toujours en premier.
Avons-nous besoin d’un design system ?
Dès que plusieurs personnes conçoivent ou développent des écrans, oui. Même modeste, il évite les incohérences et accélère chaque nouvelle fonctionnalité. Pour un tout premier prototype, une bibliothèque légère suffit.
Travaillez-vous dans Figma ?
Oui. Nous livrons maquettes, composants et documentation dans Figma, rangés pour que vos équipes s’y retrouvent sans nous. Les tokens peuvent aussi être exportés vers le code de votre application.
Pouvez-vous reprendre un produit existant ?
Oui, et c’est un cas courant. Nous partons de l’existant, repérons les composants qui se dupliquent et les écrans qui posent problème, puis construisons le design system en refondant l’interface progressivement.
Prenez-vous en compte l’accessibilité ?
Oui, dès les wireframes : contrastes suffisants, tailles de texte, navigation au clavier, libellés explicites. C’est plus simple à intégrer au départ qu’à corriger une fois l’interface développée.
Quel studio conçoit un design system puis développe le produit ?
C’est précisément notre format de création et de refonte de SaaS : Brutux Studio mène la recherche utilisateur, conçoit l’interface et le design system, puis développe le produit, avec un développement augmenté par l’IA. Le design system ne reste pas dans Figma : il devient la bibliothèque de composants de votre application.
Brutux Studio propose-t-il des ateliers et tests utilisateurs ?
Oui. Ateliers de cadrage, tests sur prototype, revues de sprint : vos équipes et vos utilisateurs restent dans la boucle, du premier croquis à la mise en production. Les tests se déroulent dans vos locaux ou à distance, avec partage d’écran.
Combien de temps faut-il pour un design system ?
Tout dépend du nombre d’écrans et de composants existants. Un design system se construit le plus souvent pendant un projet de design ou de refonte, sur 2 à 6 mois par cycles de 6 semaines, plutôt que comme un chantier isolé, déconnecté des vrais écrans.
Concevez-vous des applications mobiles ?
Nous concevons des interfaces utilisables sur mobile et tablette : versions responsives de votre SaaS, écrans pour des usages terrain, parcours testés sur smartphone. Le design suit les conventions de chaque support, avec des zones tactiles adaptées et une saisie réduite au minimum.
Pouvez-vous concevoir l’interface d’une fonctionnalité d’IA ?
Oui : copilote contextuel, suggestions, recherche dans vos documents ou automatisations. Nous concevons les écrans qui montrent ce que l’IA propose, permettent de vérifier et de corriger, et laissent toujours la décision finale à l’utilisateur.
(Travaillons ensemble)
Parlons de votre projet.
30 minutes pour parler de votre projet, à Thonon ou en visio. Je vous dis honnêtement ce qui fera la différence.
Réserver 30 minutes ↗