Refonte SaaS Linkedin
+2x de conversion, -42% d’abandon à l’onboarding
Comment piloter la croissance et les évolutions d’un SaaS sans asphyxier ses utilisateurs ? Nous voyons trop souvent le même piège se refermer sur les produits en forte croissance : le syndrome de la boîte à outils.

Le problème n'était pas l'UI. C'était la logique.
MagicPost avait des centaines d'utilisateurs et un taux de transformation après essai qui stagnait. Le réflexe aurait été de "rafraîchir", ou tout revoir dans l'interface. On a d'abord cherché à comprendre pourquoi les gens partaient. Puis avancé de manière très granulaire.
"On a compris que le problème n'était pas le manque de fonctionnalités, c'était l'abondance de micro-décisions imposées à l'utilisateur avant qu'il publie son premier post."
Abandon à l'Onboarding
VS baseline pré-refonte
Conversion Essai → Payant
J+30 post-lancement
Discovery → Handoff Dev Ready
Délai tenu & scope tenu
Nous avons tranché. Trois fois.
Nous avons tué le dashboard d’accueil.
Un choix radical : forcer l’utilisateur à atterir directement sur la création de post. Zéro distraction par les stats. Le premier usage doit être une victoire, pas une visité guidée.
Nous avons réduit le parcours de 11 étapes à 4.
En remontant les choix stylistiques dans le profil utilisateur, et non dans chaque création, on a éliminé les décisions répétitives qui épuisaient l’utilisateur à chaque session.
Nous avons priorisé le mobile first contre l’avis initial du client.
Les données d’usage montraient 68% de sessions mobiles. On a présenté les chiffres, assumé la recommandation, et décalé la version desktop à la V2.
Ce qu’on a refusé de faire.
La version tablette dans le scope initial
Budget concentré sur une expérience mobile offline-first irréprochable. La tablette aurait dilué la qualité sans adresser le vrai usage.
Protéger le produit contre sa propre ambition.
Le module “Analytics avancés” demandé en cours de mission
Feature creep identifié en semaine 4. Nous avons documenté le besoin, estimé l’effort, et renvoyé à la roadmap V2 avec une priorisation argumentée.
Un bon partenaire protège le périmètre autant qu’il livre dedans.
Chaque écran a une raison d’être.

Plug & play pour l’équipe tech.
Les livrables sont structurés pour que les développeurs n’aient aucune ambiguïté. Chaque composant documente ses états, ses variantes et ses contraintes d’intégration.
Atomic Design — atoms → organisms.
Nommage aligné sur le codebase existant.
Zéro ambiguïté, intégration en 3 semaines.
“Jujotte n’est pas venu nous livrer des maquettes. Ils ont compris notre produit, challengé nos hypothèses, et tenu leurs décisions même quand ça n’allait pas dans notre sens. C’est exactement ça qu’on cherchait.”
Avant / Après
Une expérience challengeant pour l’équipe
Les designers du projet ont aimé le challenge que relevait le projet dans sa complexité UX. Depuis, pour orchestrer la transition vers la V2, Jujotte a mis en place un partenariat design récurrent à raison d’un jour par semaine. Ce format d’abonnement agile nous permet de rejeter la logique destructrice du "Grand Soir" pour privilégier une évolution progressive et continue.
Chaque semaine, nous intervenons comme un véritable binôme stratégique pour l'équipe de MagicPost : défier les idées, conceptualiser, maquetter et ajuster en continu, sans jamais de rupture (faire évoluer l'UI Kit de manière incrémentale pour que les développeurs avancent sans friction, sans jamais devoir tout reconstruire).

