Cas 01 · Holaspirit · Product design · UX/UI · Gestion de projet
Holaspirit fonctionne sur des cercles et des rôles, un modèle de gouvernance où chaque tâche a un propriétaire clair. Ouvrir les projets à la collaboration entre cercles a rompu cette clarté. Voici le système d'assignation qui a permis aux équipes de travailler au delà des frontières sans perdre de vue qui fait quoi.
Mon rôle
J'étais la seule product designer sur le système d'assignation, du cadrage jusqu'à la passation aux équipes de développement. Pour être transparente sur mon rôle : je n'ai pas conçu le modèle de gouvernance. J'ai conçu le système d'assignation qui vient s'appuyer dessus.
Ce dont j'ai hérité
Le modèle de gouvernance (cercles, rôles, permissions) et une partie du design system existant. Je devais aussi respecter le fonctionnement de l'Holacratie au sein des projets.
Ce que j'ai piloté
Le système d'assignation inter-cercles de bout en bout : cadrage et synthèse, les trois directions explorées, le design en haute fidélité et la passation.
Avec qui j'ai travaillé
Un product manager sur le périmètre et les contraintes, les utilisateurs pour les tests et les développeurs sur la faisabilité.
Contexte
Dans Holaspirit, les personnes travaillent au sein de cercles (l'équipe Marketing, l'équipe Sales, etc.) et y occupent des rôles spécifiques. C'est un modèle de gouvernance conçu pour la clarté : chaque responsabilité a un propriétaire designé.
Pour permettre aux équipes de collaborer plus librement, les tableaux de projet ont été ouverts. Chacun pouvait désormais rejoindre un projet piloté par un autre cercle. Un membre du Marketing contribuant à un projet mené par les Sales, par exemple. La flexibilité était l'objectif, mais elle a aussi brisé ce qui faisait fonctionner les cercles : savoir exactement qui était responsable de quoi.
Avant, un projet puisait dans un seul cercle. Après, il mobilise des rôles et des membres de n'importe quel cercle. Une fonctionnalité puissante, mais la responsabilité devient compliqué.
Le problème
Rien n'était encore livré, et c'est précisément là que le travail commençait : cartographier ce que l'ouverture allait casser, avant de l'ouvrir.
« Team Lead » existe dans chaque cercle. Sur un projet qui en mobilise plusieurs, trois rôles au nom identique se retrouveraient sur la même tâche : trois responsabilités différentes, une seule étiquette.
Le rôle s'affiche déjà mais pas le cercle. En s'ouvrant, il devient indispensable avec un niveau de plus à ajouter dans un flux déjà dense, sur un espace contraint.
Aujourd'hui, l'assignation ne propose que les membres du cercle porteur. C'est exactement la limite que l'ouverture doit lever, et le flux n'a jamais été construit pour ça.
Le flux existant était déjà lent : 19,4 s par assignation, plusieurs étapes et changements de contexte, avant même que l'inter-cercles ne s'y ajoute. Regroupé à partir d'entretiens utilisateurs, tickets de support, mesure de l'ancien flux.
Discovery
Les problèmes ci-dessus n'étaient pas des suppositions. Ils viennent de quatre sources que j'ai réunies avant même de toucher à une interface : des échanges avec les utilisateurs, les tickets de support, la mesure Mixpanel de l'ancien flux, et un benchmark de la façon dont d'autres outils gèrent l'assignation inter-équipes.
Là où la confusion apparaissait vraiment, dans les usages réels.
Des plaintes récurrentes sur l'assignation et la responsabilité.
L'ancien flux mesuré à 19,4 s par assignation.
Comment d'autres outils gèrent l'assignation entre équipes.
Avant de construire, j'ai listé toutes les questions que soulèverait l'ouverture des projets entre cercles. Elles se sont regroupées selon les trois problèmes que le système devait résoudre : la responsabilité, la lisibilité de la structure, et le fait d'ajouter quelqu'un hors de son cercle.
Derrière chaque question, il y avait deux besoins. Le design devait satisfaire les deux, pas trancher pour l'un.
Le membre
Veut ajouter la personne qui doit faire la tâche sans avoir à penser aux cercles ni aux rôles.
Le lead / admin
A besoin de voir comment s'articulent membres, rôles et cercles pour que la responsabilité reste claire à l'échelle de centaines de rôles.
Ce que le système exigeait
C'est un logiciel de gouvernance d'entreprise. Le design ne pouvait pas contourner les règles pour être plus agréable. Chaque décision ici est une réponse directe à une contrainte.
Contrainte 01
Les assignations inter cercles ne pouvaient jamais outrepasser les permissions des rôles ni la logique structurelle en dessous.
Décision
Une interface unique qui reste fidèle à la gouvernance tout en s'adaptant au travail inter équipes.
Compromis : plus de complexité d'interface, en échange de l'intégrité structurelle.
Contrainte 02
Les grandes organisations comptent des centaines d'utilisateurs et de rôles. L'interface doit rester gérable à cette échelle.
Décision
Choisir un cercle → les rôles → les membres. La liste se réduit d'elle-même avant de devenir écrasante.
Compromis : plus de clics pour choisir le membre assigné, mais plus facile à trouver.
Contrainte 03
L'assignation apparaît dans les réunions, les métriques et d'autres modules de gouvernance. Elle devait donner l'impression d'un seul et même système.
Décision
La même logique et la même interaction, partout où l'assignation apparaît. Pas seulement pour les projets.
Compromis : moins de liberté, bien plus de cohérence globale.
Contrainte 04
Afficher les trois niveaux de structure ensemble risquait de surcharger l'interface.
Décision
Les états au survol et des fenêtres modales compactes montrent la relation uniquement lorsque c'est nécessaire.
Compromis : la structure est à une interaction près, pas toujours à l'écran.
Trois façons d'assigner
Le plus difficile n'était pas d'afficher les données. C'était de faire de l'assignation un geste unique et évident, alors que 3 niveaux de structure se cachaient en dessous. J'ai testé 3 directions.
Chaque ajout d'assigné créait une ligne : choisir un cercle, choisir un rôle, puis sélectionner les membres. Le filtrage fonctionnait comme un entonnoir, avec une étape de confirmation avant l'enregistrement, et disposait la structure de façon visuelle.
Wireframe : assigner par cercle → rôle → membres, une ligne à la fois.
Cliquer sur + Assigné ouvrait un menu déroulant pour choisir le contexte : cercle, rôle ou membre. En choisir un ouvrait un second menu déroulant avec une barre de recherche pour écrire ou faire défiler jusqu'au rôle exact.
Wireframe : choisir un contexte, puis rechercher le rôle exact.
La direction finale a inversé la priorité. Ajouter des membres directement, ou les atteindre via un cercle ou un rôle quand on veut le contexte. Le survol révèle sous quelle équipe agit une personne ; un clic ouvre une petite fenêtre modale pour réassigner ou désassigner. Le cercle et le rôle sont devenus des entonnoirs optionnels, pas des barrières.
Le système livré
Le flux final commence par l'utilisateur, puisque c'est lui qui accomplit la tâche, tandis que le cercle et le rôle restent des filtres optionnels lorsqu'une partie de l'équipe est nécessaire.
Ajouter un membre directement, ou via un cercle ou un rôle pour un contexte supplémentaire. Cliquer sur un membre ouvre une petite fenêtre modale indiquant sous quelle équipe il agit, avec un bouton pour désassigner. Survoler cercles, rôles et membres pour lire rapidement qui est dans quelle équipe.
Avant l'assignation : ajouter des membres directement, cliquer pour réassigner, recherche toujours en haut.
Après l'assignation : les informations des utilisateurs ajoutés apportent plus de contexte.
Ajouter un membre directement
Survoler un cercle pour prévisualiser son équipe
Cliquer un cercle pour retirer un rôle ou ses membres
Cliquer un membre pour voir ses équipes, ou le désassigner
Filtrage progressif : chaque choix restreint la liste suivante, si bien qu'une organisation comptant des centaines de rôles reste une sélection en deux étapes.
Comment j'ai travaillé avec l'IA
L'IA dans le processus, pas au dessus. Sur un produit de gouvernance, le jugement est tout le métier. Un mauvais modèle d'assignation casse les permissions. L'IA m'a aidée à chercher plus large, mais c'est moi qui tranchais, et chaque étape garde ces deux choses séparées.
Ce que l'IA a fait
Regroupé les notes d'entretien et les signaux du support en frictions récurrentes.
Ce que j'ai décidé
Lesquelles étaient structurelles plutôt qu'isolées, et lesquelles méritaient une approche à grande échelle.
Ce que l'IA a fait
Généré la liste complète des scénarios d'assignation, y compris tous les cas limites, plus vite que je ne pouvais les nommer.
Ce que j'ai décidé
Gardé seulement les cas que la gouvernance devait réellement gérer, et écarté ceux que les permissions interdisaient.
Ce que l'IA a fait
Recherché et résumé la manière dont d'autres outils gèrent l'assignation entre équipes.
Ce que j'ai décidé
Quels schémas convenaient réellement à la gouvernance et lesquels semblaient convenir mais en cassaient la logique.
Ce que l'IA a fait
Mis le flow à l'épreuve face aux règles de permission et à l'échelle des grandes organisations avant que je ne m'engage.
Ce que j'ai décidé
Corrigé ce qui cassait et gardé chaque parcours dans la logique de gouvernance jusqu'à la passation.
Ce que l'IA a fait
Créé des variations de mise en page pour le flux d'assignation et transformé de simples croquis en écrans cliquables.
Ce que j'ai décidé
Travaillé la version qui gardait un flux d'assignation dense sans l'alourdir, puis affiné.
Les décisions étaient les miennes. L'IA a élargi la recherche, pas le niveau d'exigence.
Résultats
Rôles assignés à travers plusieurs cercles. Parti de 0 % parce que la collaboration était tout simplement impossible avant.
Temps pour réaliser une assignation, mesuré dans Mixpanel sur des sessions réelles.
Retours positifs lors des tests utilisateurs sur l'expérience d'assignation.
Les projets peuvent désormais impliquer des membres, des rôles et des cercles de toute l'organisation.
Le lien entre membres, rôles et cercles devient visible. Moins d'ambiguïté, moins de doublons.
Le même schéma se retrouve dans les réunions et les métriques, en restant performant pour les grandes organisations.
À retenir
Flexibilité et clarté se font généralement concurrence. Plus le système est ouvert, plus il devient compliqué.
Le défi était d'avoir les deux : laisser les équipes collaborer au delà de leur cercle sans perdre la clarté de la responsabilité que la gouvernance est censée protéger.