Alice Bonneau.
Retour au portfolioPortfolio

Cas 01 · Holaspirit · Product design · UX/UI · Gestion de projet

Quand le travail traverse les équipes, quelqu'un doit toujours savoir qui en est responsable.

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.

Rôle
Product Designer : de la recherche à l'UI
Produit
Holaspirit · Échelle entreprise
Périmètre
Système d'assignation, multi module
Statut
Livré
UX designUI designGouvernanceGestion de projet

Mon rôle

Ce que j'ai conçu, et ce sur quoi je me suis appuyée.

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

Une équipe, un cercle : jusqu'à ce que les projets en demandent plus.

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.

Schéma : une tâche mobilisant des rôles et des membres des cercles Marketing et Sales.

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

Les tableaux se sont ouverts entre cercles. Le modèle d'assignation, lui, n'était pas prêt.

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.

01

Trois rôles, un seul nom

« 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.

02

Une information de plus à faire tenir

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.

03

Verrouillé sur un seul cercle

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

D'où viennent ces trois frictions.

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.

Entretiens utilisateurs

Là où la confusion apparaissait vraiment, dans les usages réels.

Tickets de support

Des plaintes récurrentes sur l'assignation et la responsabilité.

Mesure Mixpanel

L'ancien flux mesuré à 19,4 s par assignation.

Benchmark

Comment d'autres outils gèrent l'assignation entre équipes.

Tableau de cartographie des risques : mes questions sur ce que l'ouverture des projets entre cercles pourrait casser, regroupées selon les trois problèmes que le système devait résoudre

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

« Assigner la bonne personne, rapidement. »

Veut ajouter la personne qui doit faire la tâche sans avoir à penser aux cercles ni aux rôles.

Le lead / admin

« Garder une responsabilité claire, même dans les grandes organisations. »

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

La plateforme imposait des limites strictes. Chaque décision répond à l'une d'elles.

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

La gouvernance ne peut pas être rompue

Les assignations inter cercles ne pouvaient jamais outrepasser les permissions des rôles ni la logique structurelle en dessous.

Décision

Le modèle d'assignation, toujours dans les règles

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

Doit passer à l'échelle de centaines de rôles

Les grandes organisations comptent des centaines d'utilisateurs et de rôles. L'interface doit rester gérable à cette échelle.

Décision

Un filtrage progressif, comme un entonnoir

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

Cohérent dans chaque module

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

Un motif d'assignation réutilisable

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

Cercles, rôles, membres à la fois = bruit visuel

Afficher les trois niveaux de structure ensemble risquait de surcharger l'interface.

Décision

Une hiérarchie révélée à la demande

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

Trois tentatives pour faire de l'assignation une seule action.

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.

01

Lignes d'assignés

Rejeté

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 de la piste « une ligne par assigné » : cercle, rôle et menu de membres sur chaque ligne.

Wireframe : assigner par cercle → rôle → membres, une ligne à la fois.

Ce qui s'est amélioré
  • Facile de voir tout le monde sur une tâche d'un coup d'œil
  • N'importe quelle ligne supprimée en un clic
Ce qui a manqué
  • Trop de clics pour assigner une seule personne
  • Un bouton de confirmation qui ajoutait une étape pour rien
  • Deux boutons d'assignation dans un espace restreint
02

Menu déroulant par contexte

Rejeté

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 de la piste « menu par contexte » : choisir un contexte, puis rechercher le rôle exact.

Wireframe : choisir un contexte, puis rechercher le rôle exact.

Ce qui s'est amélioré
  • Un pas à pas clair qui réduisait l'ambiguïté
  • Une recherche de rôle qui tenait la charge pour les grandes organisations
  • Les rôles rattachés à leur cercle, rendant la responsabilité compréhensible
Ce qui a manqué
  • Toujours beaucoup de clics, toujours ce bouton de confirmation
  • Trop catégorisé : chaque section ajoutait un clic
  • Trop centré sur la structure (rôles, cercles) plutôt que sur l'utilisateur en train de faire la tâche
03

Les personnes d'abord

Livré

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.

Ce qui s'est amélioré
  • Un seul menu, avec la recherche toujours en haut
  • Navigable au clavier ; les membres choisis directement dans la cascade
  • Assigner toute une équipe par cercle ou par rôle, ou seulement les bonnes personnes
  • Les membres peuvent être assignés en dehors de tout cercle ou rôle, pour plus de flexibilité
Le coût
  • Une logique de survol/modale plus riche à construire et à maintenir
  • La structure est à une interaction près, pas toujours visible

Le système livré

Les personnes d'abord. La structure quand vous la demandez.

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.

Panneau de tâche avant toute assignation : aucun assigné, avec cercles, rôles et membres prêts à être choisis.

Avant l'assignation : ajouter des membres directement, cliquer pour réassigner, recherche toujours en haut.

Panneau de tâche après l'assignation : cercles et avatars des membres affichés sous Assignés, menu toujours ouvert.

Après l'assignation : les informations des utilisateurs ajoutés apportent plus de contexte.

Ajout d'un membre aux assignés d'une tâche.

Ajouter un membre directement

Survoler un cercle le met en évidence et prévisualise son équipe.

Survoler un cercle pour prévisualiser son équipe

Cliquer un cercle ouvre des options pour retirer le rôle ou ses membres.

Cliquer un cercle pour retirer un rôle ou ses membres

Cliquer un membre affiche ses équipes, avec un bouton pour le désassigner.

Cliquer un membre pour voir ses équipes, ou le désassigner

CERCLE : toutes les équipes RÔLES : dans ce cercle MEMBRES : les personnes dont vous avez besoin

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

Rapide pour explorer. Précis pour décider.

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.

Synthèse
Claude AIChatGPT

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.

Écriture de scénarios
Claude AIChatGPT

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.

Benchmark
ChatGPT

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.

Pression des cas limites
Claude AIChatGPT

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.

Création de l'approche
Figma MakeClaude Design

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

Plus rapide, plus clair, et enfin une approche inter équipes.

+34pts
0% → 34%

Rôles assignés à travers plusieurs cercles. Parti de 0 % parce que la collaboration était tout simplement impossible avant.

−39%
19.4s → 11.8s

Temps pour réaliser une assignation, mesuré dans Mixpanel sur des sessions réelles.

+43pts
41% → 84%

Retours positifs lors des tests utilisateurs sur l'expérience d'assignation.

Collaboration inter équipes

Les projets peuvent désormais impliquer des membres, des rôles et des cercles de toute l'organisation.

Visibilité transparente

Le lien entre membres, rôles et cercles devient visible. Moins d'ambiguïté, moins de doublons.

S'adapte aux autres modules

Le même schéma se retrouve dans les réunions et les métriques, en restant performant pour les grandes organisations.

À retenir

La victoire, c'était une flexibilité qui restait claire sous pression.

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.

Image agrandie