Un design qui se livre, pas qui décore.
Du design produit guidé par la recherche, par l'équipe qui écrit aussi le code — des parcours, des systèmes et des interfaces mesurés sur ce que font les utilisateurs, pas sur les applaudissements des parties prenantes.
De jolies interfaces échouent en production tous les jours.
Le cimetière du logiciel est rempli de beaux fichiers Figma : des parcours qui font belle démo et s'effondrent face aux données réelles, des cas limites découverts en première semaine d'ingénierie, des design systems abandonnés au deuxième sprint. Le fossé entre agence de design et studio de dev est l'endroit où les produits vont mourir.
Nos designers travaillent au sein d'un studio d'ingénierie. Chaque parcours est conçu face à des données réelles, des contraintes réelles et les ingénieurs qui le construiront — souvent la même semaine. Ce que vous approuvez est ce qui se livre, parce que ceux qui l'ont dessiné répondent à ceux qui le codent.
De la recherche au handoff.
La discipline design au complet — exercée entre les mêmes murs que l'ingénierie qui la suit.
Recherche produit
Entretiens utilisateurs, observation des workflows et démontage concurrentiel — des preuves avant les pixels.
Architecture UX & wireframes
Parcours, hiérarchies et états cartographiés en entier — y compris les états vides, d'erreur et limites que les démos cachent.
Design systems
Des systèmes de composants à base de tokens sur lesquels votre produit peut grandir des années — pas un projet d'art unique.
Design UI haute fidélité
Un design d'interface de niveau production, avec le soin dans la typographie, le mouvement et le détail que les utilisateurs sentent sans savoir le nommer.
Prototypage & tests
Des prototypes cliquables devant de vrais utilisateurs, avant que l'argent d'ingénierie ne parte sur la mauvaise idée.
Handoff design-vers-code
Tokens, specs et composants livrés dans la base de code — par des collègues, pas par-dessus un mur.
Les preuves, puis le geste.
Le goût compte — mais il vient après que la recherche a tué les mauvaises idées.
01Comprendre le travail
Nous regardons de vrais utilisateurs faire le vrai travail — les contournements, les jurons, les post-its. C'est ça, la spec.
02La structure avant la surface
Architecture de l'information et parcours validés en basse fidélité, là où un changement coûte des minutes et non des sprints.
03Façonner le système
Le design haute fidélité construit comme un système à base de tokens — chaque écran rend le suivant moins cher.
04Tester & resserrer
Des tests de prototypes avec de vrais utilisateurs, puis l'itération. Les applaudissements, c'est agréable ; l'accomplissement de la tâche, c'est la métrique.
Nous l'avons déjà livré.
Une expérience grand public conçue et développée sous un même toit — scanner, parcourir, payer, faire confiance.
FeelEat — Happy Fridge
Une expérience mobile qui devait rendre l'achat dans un frigo fluide et digne de confiance — menus, ingrédients, allergènes et paiement dans un parcours que n'importe quelle grand-mère peut terminer.
Choisis pour le problème, pas pour le CV.
Un outillage design branché droit dans le pipeline d'ingénierie — des tokens en sortie, des composants en entrée.
Une seule équipe. Zéro passation.
Les disciplines le plus souvent combinées avec le design produit — même architecture, mêmes ingénieurs, aucune taxe d'intégration.
Des questions, des réponses.
Ce que les acheteurs de design produit nous demandent le plus. Pour le reste — envoyez un brief, un ingénieur senior répond sous un jour ouvré.
Décrivez-le dans un brief. Un ingénieur senior — pas un commercial — répond sous un jour ouvré.
Q.01Peut-on utiliser votre équipe design avec nos propres développeurs ?
Oui — nous livrons des systèmes, des tokens et des specs que vos ingénieurs auront vraiment plaisir à recevoir, plus des permanences pendant l'implémentation. Les designs sont documentés pour ceux qui construisent, parce que ceux qui construisent passent leurs journées à côté de nos designers.
Q.02Comment mesurez-vous le succès d'un design ?
Accomplissement des tâches, time-to-value, taux d'erreur et rétention — fixés comme cibles pendant la recherche. Nous perdrons volontiers un débat de goût subjectif, et gagnerons le test d'utilisabilité.
Q.03Redessinez-vous des produits existants ?
En permanence. Nous commençons par un audit UX croisé avec vos analytics et vos tickets de support, puis priorisons par douleur utilisateur plutôt que par âge visuel. Souvent, la refonte au meilleur ROI touche trois écrans, pas trente.
Q.04Combien coûte une mission design ?
Un sprint recherche-plus-design sur une zone produit ciblée démarre typiquement autour de $15k–$40k, fixé après cadrage. Les missions design-et-build combinées l'intègrent au budget produit — une équipe, un chiffre.
Q.05Le design system survivra-t-il dans le code ?
Oui, car nous le transférons sous forme de design tokens (couleurs, typo, espacement) implémentés en variables Tailwind/CSS et une bibliothèque de composants dans Storybook. Designers et ingénieurs travaillent depuis la même source de vérité.
Q.06L'accessibilité est-elle incluse ?
Toujours. Nous concevons selon WCAG 2.2 AA par défaut — contraste de couleur, navigation au clavier, étiquetage pour lecteurs d'écran, états de focus. Nous ne greffons pas l'accessibilité après le lancement.
Q.07Avec combien d'utilisateurs faut-il tester pour trouver les vrais problèmes ?
Cinq à huit par tour détectent la grande majorité des problèmes d'utilisabilité — le constat de Nielsen tient en pratique. Nous préférons mener trois petits tours tout au long du projet qu'une grande étude à la fin, car la valeur est dans l'itération sur ce que vous apprenez, pas dans une grande taille d'échantillon.
Q.08Faites-vous de la recherche utilisateur, ou seulement du design visuel ?
Les deux, et la recherche est la partie qui prévient les erreurs coûteuses. Nous menons des entretiens, de la cartographie de parcours et des tests d'utilisabilité pour trouver la vraie douleur avant de concevoir quoi que ce soit. Nous pouvons faire une mission visuels-seulement, mais nous dirons d'emblée que sauter la recherche signifie que nous décorons une hypothèse plutôt que de résoudre un problème validé.
Un produit qui mérite
un meilleur design ?
Dites-nous où les utilisateurs peinent, ou bien où la vision dépasse l'interface. Un designer produit senior répond sous un jour ouvré.