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
PASSER D’UN PARTAGE SIMPLE À UNE COLLABORATION STRUCTURÉE ET SCALABLE
Structurer la collaboration sur Mixup.media
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.”
Problèmes identifiés
Le système existant n’était pas adapté au travail en équipe sur le long terme. Les utilisateurs ne pouvaient pas se regrouper au sein d’un espace commun avec une gestion claire des rôles et des responsabilités. La collaboration restait fragmentée, sans véritable hiérarchie ni structure pour organiser les membres, les contenus et les accès.
En même temps, il était important de garder la flexibilité du produit, notamment la possibilité de partager des fichiers sans compte. L’enjeu était donc d’ajouter de la structure sans casser l’existant ni complexifier l’expérience.
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 l’architecture du produit vers un modèle structuré :
Cette nouvelle logique permet de passer d’un partage ponctuel à une organisation du travail plus claire, où les utilisateurs collaborent au sein d’espaces 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.
Chaque Organization permet de regrouper des utilisateurs au sein d’une même entité, avec une gestion centralisée des membres, des rôles et du billing. Elle devient le point d’entrée principal pour les équipes.
Un utilisateur peut appartenir à plusieurs Organizations et naviguer entre elles via un dropdown.
Cette structure permet d’organiser plus clairement le produit et de le rendre plus adapté à des usages professionnels.
Décision clé n°2
Clarifier les niveaux de permissions
L’introduction des Organizations a nécessité de distinguer deux niveaux de permissions.
Au niveau global, les rôles Organization (Super Admin, Admin, Member) définissent la gestion des membres, la création des Teamspaces et le contrôle du billing.
Au niveau local, les rôles appliqués aux Teamspaces et aux fichiers déterminent les actions possibles sur les contenus (édition, téléchargement, commentaires, etc.).
Nous avons aussi simplifié les noms des rôles pour les rendre plus universels et compréhensibles, au-delà du contexte musical.
L’objectif était d’avoir un système clair, cohérent, et facile à comprendre pour les utilisateurs.
Défi majeur
Gérer l’héritage et les exceptions
Le principal défi du projet a été la gestion des permissions entre les différents niveaux.
Par défaut, le rôle d’un utilisateur dans un Teamspace s’applique aux fichiers qu’il contient. Toutefois, afin de conserver de la flexibilité, il est possible de modifier ce rôle sur un fichier spécifique.
Ce fonctionnement introduit une logique d’héritage avec des exceptions locales, qui génère de nombreux cas à gérer : changements de rôle, suppression d’un utilisateur, conflits entre permissions, propagation des accès.
Une grande partie du travail a consisté à clarifier ces règles pour garder un système cohérent, sans perdre 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, et pas comme une suite 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.