Aller au contenu

Hello ! Je suis Anaïs

Lightspeed

2025

Simplifier la gestion des utilisateurs dans un logiciel de caisse

Ou comment repenser les rôles et permissions du back-office pour réduire les erreurs d’accès et soulager l’équipe support

  • Stratégie UX
  • Design system
  • Prototypes

Enjeu business

Beaucoup d’employés en restauration, peu de visibilité sur leur accès

Lightspeed vend son logiciel de caisse à des groupes de restaurants, des organisations avec des dizaines d’employés, plusieurs adresses, et un turn-over élevé.

Gérer les accès au back-office et aux points de vente fait partie du quotidien des managers.

Problèmes utilisateurs

Ce que j’ai trouvé en arrivant

  • Les rôles manquaient de transparence

    Difficile de savoir exactement ce qu’un rôle autorisait. Les managers avaient besoin de plus de visibilité pour configurer les accès.

    Je ne suis pas sûr de ce que cette permission peut faire…

    Cédric, Manager de restaurant

  • La granularité des accès était limitée

    Les permissions ne permettaient pas encore d’adapter finement les droits selon les rôles métier réels.

    j'ai besoin qu'il accède au backoffice mais sans voir les finances, c'est possible ?

    Amandine, Cheffe opération multi-restaurant

  • Les permissions manquaient de structure

    Une liste longue sans explication ni regroupement. Avec un peu de guidage, l’expérience pouvait être bien plus fluide.

    c'est en vrac, je perds un temps fou à chaque fois !

    Jean-Patrick, Manager de restaurant

  • Certaines actions manquaient de clarté sur leur portée

    Désactiver un utilisateur depuis une location le supprimait sur tous les restaurant du groupe

    attends il a plus accès à rien ?? j'ai juste retiré un resto

    Akim, Responsable de 3 restaurants

Contraintes terrain

Je suis partie avec ces cartes en main

  • Une squad en construction

    Mon PM arrivait du sales, une connaissance métier pointue, mais pas de méthodo produit. C’était à moi de structurer l’approche et de capitaliser sur sa connaissance terrain.

  • 3 350 tickets support en 2025

    Un volume qui confirmait l’urgence du sujet et une mine d’informations brutes à exploiter (69 nouveaux tickets par semaine)

  • Un design system pas encore migré

    Le design system existait, mais cette section du produit n’avait pas encore été migrée. Il fallait tout repenser avec les nouveaux légos en collaboration avec les autres designers.

Méthodes

J’ai trié ce qu’on savait déjà

  • Centraliser les signaux existants

    Feedbacks Canny, tickets support, conversations Intercom, données Heap et connaissance terrain du PM. Tout était là, épars. Je l’ai agrégé et catégorisé pour faire émerger ce qui revenait le plus.

    • Recherche secondaire

  • Auditer l’existant

    J’ai croisé les problèmes remontés avec ce que je voyais réellement dans le produit. J’ai voulu comprendre d’où venaient les pain points, cela m’a permise d’identifier des problèmes structurants

    • Audit d'interface

  • Prioriser pour une V1 réaliste

    Tous les problèmes ne pouvaient pas être résolus d’un coup. J’ai croisé fréquence et criticité pour décider ce qu’on adressait maintenant et ce qu’on laissait pour plus tard.

    • Priorisation d'opportunités

  • S’inpirer des autres SaaS

    A mesure que les problèmes devenaient plus clairs, je suis allée voir ce que faisaient les concurrents ou d’autres SaaS qui gèrent les rôles et permissions (outils RH notamment) pour m’inspirer.

    • Benchmark

  • Tester en interne

    Pour gagner du temps sans sacrifier la validation, j’ai organisé des sessions de tests avec des sales et implementation consultants Lightspeed.

    • 17 test utilisateurs Maze (dont 2 synchrones)

Choix design

Jusqu’où aller sans tout casser ?

Standardiser avec les rôles sans brutaliser la transition

À terme, tout devrait passer par des rôles. Plus besoin d’attribuer des permissions une par une, plus de configurations hasardeuses.

Sauf que 12,5% des utilisateurs existants n’appartenaient à aucun groupe et une migration forcée était trop risquée.

J’ai donc gardé les deux options, en orientant doucement vers les rôles : en les mettant en avant en premier, en montrant leur flexibilité à la création.

  • Attribuer simplement un rôle à un user

    Attribuer simplement un rôle à un user

  • Switcher pour sélectionner les permissions une à une

    Switcher pour sélectionner les permissions une à une

  • Side panel pour lister les permissions activées pour ce rôle

    Side panel pour lister les permissions activées pour ce rôle

Rendre les permissions lisibles aujourd'hui pour les enrichir demain

Les permissions allaient devenir plus granulaires à terme. Mais avant d’en ajouter, il fallait déjà rendre celles qui existaient compréhensibles.

J’ai catégorisé les permissions par grande famille, ajouté un titre et une description à chacune, et intégré une recherche par mots-clés.

Une base propre qui prépare le terrain sans attendre que le back-end soit prêt.

  • Personnaliser les rôles avec des permissions catégorisées

    Personnaliser les rôles avec des permissions catégorisées

  • Trouver facilement des permisions avec des mots-clés

    Trouver facilement des permisions avec des mots-clés

Détourner une feature existante pour créer la business view

L’idée d’une vue globale sur tous les restaurants d’un groupe était évidente. La mettre en place l’était beaucoup moins.

Créer une vraie business view impliquait des développements back-end lourds et une dépendance à une autre squad dont la roadmap était incertaine.

On a trouvé une autre voie : les templates. Jusqu’ici utilisés en workaround par les grands groupes pour dupliquer rapidement une configuration, ils pouvaient devenir officiellement la business view. Même logique technique, nouveau rôle dans le produit.

  • Business view avec tous les utilisateurs auxquels le manager a lui-même accès

    Business view avec tous les utilisateurs auxquels le manager a lui-même accès

Résultats

Ce que je laisse derrière moi

  • Un langage commun

    Décisions documentées, termes définis avec la squad et les squads adjacentes. Plus de flou sur qui fait quoi ni sur ce que les mots veulent dire.

  • Des maquettes prêtes à développer

    Flows livrés et documentés dans le détail, migrés sur le nouveau design system. Chaque écran accompagné de ses règles et de ses cas limites.

  • Un Figma autoportant

    Des fichiers organisés pour être compris sans explication orale par la nouvelle designer, par les développeurs, par les parties prenantes.

Témoignages

Promis, c’est un véritable feedback

Gabriel Galindo Roman Design manager

Anaïs handles the unknown with resilience. She doesn't seek perfection right away. Instead, she iterates, gathers feedback from tech, product, and design, and critically chooses what to keep, question, or combine. I value how she maps and organizes her thoughts before jumping into Figma: it creates alignment on principles and builds trust in the design decisions. The way she documents usability testing and frames clear questions helps align everyone on objectives and results. And the motivation she brings is contagious, focusing on making things better with a "what if we try this" mindset rather than dwelling on problems.