Rôle : Product Designer
Contexte : Évolution structurelle du modèle de collaboration
Enjeu : Passer d’un système de partage de fichiers à une architecture multi-organisation scalable
Repenser les rôles, les permissions et l’organisation des équipes
Concevoir un modèle de collaboration scalable
Contexte
Mixup.media est une plateforme collaborative permettant de stocker, partager et commenter différents types de fichiers.
Au départ, la collaboration se faisait surtout via le partage de fichiers entre utilisateurs, avec des rôles appliqués au cas par cas. Ce fonctionnement marchait bien pour des usages ponctuels, mais montrait ses limites dès que les équipes grandissaient.
Avec l’évolution du produit et l’arrivée de nouveaux profils (studios, équipes créatives, entreprises…), un besoin revenait souvent :
“Pouvoir travailler à plusieurs dans un même espace, avec des rôles et des responsabilités clairs.”
Ce besoin était particulièrement visible dans des contextes professionnels.
Par exemple, dans un studio, plusieurs personnes interviennent sur un même projet (production, mix, mastering), chacune avec son propre compte.
Pourtant, il n’était pas possible de travailler facilement dans un espace commun.
Les fichiers devaient être partagés individuellement, ce qui rendait l’organisation complexe, fragmentée, et difficile à suivre dans le temps. Les équipes ne pouvaient pas collaborer efficacement sur un même projet.
À mesure que les usages évoluaient, ce fonctionnement montrait ses limites : le produit, pensé à l’origine pour du partage ponctuel, ne permettait plus de répondre aux besoins d’une collaboration structurée et durable. Il devenait nécessaire de repenser le modèle de collaboration dans son ensemble.
Problèmes identifiés
Le système existant n’était pas conçu pour supporter une collaboration en équipe sur le long terme.
En l’absence d’un espace partagé structuré, les utilisateurs devaient gérer les accès fichier par fichier, multipliant les actions manuelles et les risques d’erreur.
Les rôles étaient appliqués de manière isolée, sans vision globale, rendant difficile la compréhension de qui pouvait faire quoi.
Cette approche fragmentée posait plusieurs problèmes :
– une organisation peu lisible des contenus
– des permissions difficiles à gérer et à maintenir dans le temps
– une collaboration inefficace dès que le nombre d’intervenants augmentait
À mesure que les équipes grandissaient, ces limites devenaient critiques.
Le produit ne permettait pas de structurer les membres, les contenus et les responsabilités au sein d’un cadre commun.
En parallèle, il était essentiel de préserver ce qui faisait la force du produit :
sa simplicité et sa flexibilité, notamment la possibilité de partager des fichiers facilement, même sans compte.
L’enjeu était donc double : introduire de la structure sans alourdir l’expérience, ni casser les usages existants.
Un système de partage limité, basé sur des rôles spécifiques à l’audio, sans structure claire ni hiérarchie.
L’évolution du modèle
Pour répondre à ces enjeux, nous avons fait évoluer le modèle de collaboration vers une structure plus claire et scalable.
L’objectif n’était pas simplement d’ajouter un nouveau niveau, mais de poser une logique cohérente permettant d’organiser à la fois :
– les utilisateurs
– les espaces de travail
– les contenus
– et les permissions associées
Nous avons introduit une architecture en plusieurs niveaux :
Chaque niveau répond à un besoin spécifique :
– Organization : structurer les utilisateurs au sein d’une même entité (équipe, studio, entreprise)
– Teamspace : créer des espaces de travail dédiés à des projets ou des groupes
– Files : gérer les contenus et leur partage
Ce modèle permet de passer d’une logique de partage ponctuel à une logique de collaboration structurée, où les utilisateurs évoluent dans des espaces clairement définis.
Mon rôle
En tant que Product Designer, j’ai travaillé sur toute la conception de cette évolution, de la réflexion UX jusqu’au suivi de l’implémentation.
J’ai défini la structure globale du système, les rôles et les permissions, ainsi que leur intégration dans un produit déjà existant.
J’ai également collaboré étroitement avec les développeurs pour cadrer les règles, anticiper les cas complexes et m’assurer que tout était faisable techniquement.
Décision clé n°1
Introduire un niveau Organization
Pour structurer la collaboration, nous avons introduit un niveau supérieur : l’Organization.
Le problème
Sans structure intermédiaire, les utilisateurs interagissaient uniquement via des partages individuels.
Il n’existait aucun moyen de regrouper des membres, de centraliser la gestion des accès ou d’avoir une vision globale d’une équipe.
Les options envisagées
– Rester sur un modèle centré fichier
Simple, mais impossible à faire évoluer pour des usages en équipe
– Introduire uniquement des espaces de type “projet” (Teamspaces)
Permet de collaborer, mais ne répond pas aux besoins de gestion globale (membres, rôles, billing)
– Ajouter un niveau supérieur structurant (Organization)
Plus complexe, mais permet de poser une base scalable
Le choix
Nous avons choisi d’introduire un niveau Organization, permettant de regrouper des utilisateurs au sein d’une même entité, avec une gestion centralisée des membres, des rôles et du billing.
Un utilisateur peut appartenir à plusieurs Organizations et naviguer entre elles.
Pourquoi ce choix
Ce niveau permet :
– de structurer les équipes de manière cohérente
– de centraliser la gestion des accès
– de poser les bases d’un modèle scalable (notamment pour le billing et les rôles globaux)
L’Organization devient le point d’entrée principal pour les usages professionnels.
Décision clé n°2
Clarifier les niveaux de permissions
L’introduction des Organizations a nécessité de repenser la gestion des permissions.
Le problème
Dans le système existant, les rôles étaient appliqués au cas par cas, sans hiérarchie claire.
Cela rendait difficile la compréhension et la gestion des accès, notamment dans des contextes multi-utilisateurs.
Les options envisagées
– Un système de permissions unique (plat)
Simple en apparence, mais difficile à adapter à des contextes variés
– Multiplier les rôles spécifiques selon les cas
Très flexible, mais rapidement illisible et difficile à maintenir
– Structurer les permissions par niveaux (global / local)
Introduit une logique plus complexe, mais plus cohérente
Le choix
Nous avons distingué deux niveaux de permissions :
– Au niveau Organization : rôles globaux (Super Admin, Admin, Member) → gestion des membres, création des Teamspaces, billing
– Au niveau Teamspace / Files : rôles locaux → actions sur les contenus (édition, téléchargement, commentaire…)
Pourquoi ce choix
Ce modèle permet de :
– clarifier les responsabilités à chaque niveau
– éviter les conflits entre permissions
– garder un système compréhensible malgré sa complexité
Nous avons également simplifié les noms des rôles pour les rendre plus universels et compréhensibles, au-delà du contexte initial du produit.
Défi majeur
Gérer l’héritage et les exceptions
Le problème
L’un des principaux défis du projet a été la gestion des permissions entre les différents niveaux du système.
Avec l’introduction des Organizations et des Teamspaces, les accès ne pouvaient plus être définis uniquement au cas par cas.
Il fallait établir une logique cohérente permettant de gérer à la fois :
– des règles globales (au niveau Organization)
– des règles locales (au niveau Teamspace et fichier)
Par défaut, le rôle d’un utilisateur dans un Teamspace s’applique aux fichiers qu’il contient.
Mais pour conserver la flexibilité du produit, il devait rester possible de modifier ce rôle sur un fichier spécifique.
Cela introduit une logique d’héritage avec exceptions.
La complexité
Ce type de système génère rapidement de nombreux cas complexes :
– Que se passe-t-il si le rôle d’un utilisateur change au niveau du Teamspace ?
– Comment gérer les exceptions déjà définies sur certains fichiers ?
– Que devient l’accès d’un utilisateur supprimé d’une Organization ?
– Comment éviter les incohérences entre permissions globales et locales ?
Chaque règle ajoutée pouvait avoir des effets en cascade sur l’ensemble du système.
Le risque était de créer un système difficile à comprendre pour les utilisateurs, et difficile à maintenir côté technique.
Le travail de conception
Une grande partie du travail a consisté à identifier les différents cas d’usage, repérer les conflits possibles et définir des règles de priorité claires entre les niveaux.
J’ai travaillé en étroite collaboration avec les développeurs pour confronter les choix de conception aux contraintes techniques et anticiper les comportements edge cases.
Ces échanges ont permis de clarifier les règles et d’éviter des incohérences dans le système.
Le résultat
Nous avons abouti à un système basé sur :
– une logique d’héritage par défaut (du Teamspace vers les fichiers)
– la possibilité d’ajouter des exceptions locales, de manière contrôlée
– des règles de priorité claires pour éviter les conflits
L’objectif était de trouver un équilibre entre :
– cohérence globale
– flexibilité locale
– compréhensibilité pour les utilisateurs
Refonte avec une structure plus claire, intégrant des rôles génériques et des permissions héritées.
Contraintes et arbitrages
Le projet s’inscrivait dans un contexte où il était important de préserver le fonctionnement existant et de limiter les changements techniques.
Nous avons notamment fait le choix de conserver les mêmes rôles pour le partage d’un fichier et d’un Teamspace, afin d’éviter de multiplier les variations et de complexifier la logique côté développement.
De la même manière, bien que les fichiers puissent être publics ou privés, les Teamspaces ont été limités à un fonctionnement privé. Ce choix permet de mieux contrôler les accès et d’éviter des cas trop complexes.
Ces choix ont permis de trouver un équilibre entre flexibilité, cohérence et maintenabilité.
Livraison & implémentation
Tout au long du projet, j’ai travaillé en collaboration avec les développeurs afin de valider les choix de conception et d’anticiper les contraintes techniques.
Une fois les parcours définis, j’ai rédigé des spécifications fonctionnelles détaillées en anglais sur Notion, centralisant les règles de gestion, les comportements attendus et les cas particuliers.
J’ai également créé et suivi les tâches sur Asana, en assurant la transmission des informations nécessaires à l’implémentation.
Après développement, j’ai réalisé un QA design afin de vérifier la conformité avec les maquettes et d’ajuster si nécessaire.
Recul & apprentissages
Ce projet m’a appris à voir les permissions comme un système global, plutôt que comme une succession de cas isolés.
Au début, on peut facilement ajouter des règles au fur et à mesure. Mais dès qu’il y a plusieurs niveaux (Organization, Teamspace, fichier), chaque décision a un impact sur tout le reste.
J’ai compris que ce qui compte, ce n’est pas d’avoir beaucoup de règles, mais d’avoir une logique claire et cohérente.
Ce projet m’a également confrontée à la complexité des edge cases.
En étant seule designer sur le projet, certains cas m’ont échappé au début. C’est surtout en échangeant avec les développeurs qu’on a identifié des scénarios auxquels je n’avais pas pensé. Ces discussions ont été clés. Elles m’ont permis de mieux structurer le système et d’éviter des incohérences.
Aujourd’hui, j’anticipe beaucoup plus ces cas en amont, et je travaille plus étroitement avec les développeurs sur ce type de sujets.