Aller au contenu

Collaboration Design (à 2 PD)

Définition

Comment deux Product Designers travaillent ensemble chez Bricks : répartition des sujets, arbitrage des décisions, gouvernance du design system à deux, et passation d'un sujet d'un PD à l'autre (handoff designer↔designer, distinct du handoff design↔dev). Le but : qu'un 2nd PD soit autonome sans fragmenter le design.

Page concept V1 — à roder sur les premiers sujets partagés, puis à valider ensemble.

Les deux PD

  • PD référent du domaine — owner de l'area design et garant du DS core.
  • Second PD — pair du PD référent, owner des sujets qui lui sont attribués.
  • Les deux PD partagent le même management et travaillent comme pairs.

Répartition des sujets

Par sujet, au fil de l'eau — pas de découpage produit fixe. Un sujet à impact UI est attribué à l'un ou l'autre selon la charge et les sujets en cours, pas selon une frontière Investors / EF / Uimmo.

  • Chaque sujet a un PD owner clairement identifié (celui qui le porte de la discovery à la QA design).
  • L'autre PD est reviewer naturel du sujet (œil neuf en design review).
  • Les deux peuvent travailler en parallèle sur des sujets distincts — d'où l'importance de l'arbitrage et de la gouvernance DS ci-dessous.

Arbitrage des décisions

Quand les deux PD ont un avis divergent sur un sujet design :

  1. Le PD owner du sujet décide par défaut, l'autre challenge en review.
  2. Le PD référent du domaine tranche si la review et le retour au problème utilisateur ne permettent pas de résoudre le désaccord.
  3. Lentille lean comme juge de paix : en cas de blocage, on retombe sur le problème user + l'outcome visé, pas sur les goûts.

Gouvernance du DS à deux

Complète la gouvernance du Design System Uimmo :

  • DS core Uimmo — les deux PD sont co-owners. Ils peuvent proposer et modifier un composant.
  • Composants propres produit — le PD owner du sujet les valide dans le respect des tokens.
  • Promotion vers Uimmo — les deux PD la reviewent ; le PD référent tranche en cas de désaccord.
  • Implémentation — le référent technique du design system est consulté et review le code.

Handoff designer ↔ designer

Cas nouveau non couvert par le handoff design↔dev : quand un sujet passe d'un PD à l'autre (congés, rééquilibrage de charge, spécialisation). Pour qu'il n'y ait pas de perte de contexte :

  • Où en est le sujet : étape du cycle (discovery / zoning / … / QA).
  • Problème + hypothèse + outcome (lentille lean) — pourquoi ce sujet existe.
  • Directions explorées et écartées (et pourquoi).
  • États et edge cases déjà listés vs restant à couvrir.
  • Décisions de review déjà actées + compromis ouverts.
  • Liens : frame Figma, ticket Linear, fiche projet.

Un sujet repris sans ce contexte = re-discovery silencieuse. À tracer dans la fiche projet ou le ticket, pas à l'oral seul.

Rituels & cadence

Principe : minimal, async par défaut. L'ADN Bricks (vitesse, pragmatisme) veut le moins de réunions possible. À 2 PD le risque n'est pas le manque de coordination — c'est de sur-réunionner. Contexte hybride : la weekly se fait en visio, l'async est la colonne vertébrale pour les jours à distance.

Le seul rituel fixe — Weekly design sync

  • 1×/semaine, 30 min, en visio avec les deux PD.
  • Répartition des sujets de la semaine (qui owne quoi — cf. Répartition), charge, blocages.
  • Standing item gouvernance DS : composants ajoutés/modifiés depuis la semaine passée, fragmentation, promotions vers Uimmo (cf. Gouvernance du DS). Évite une réunion DS séparée.

À la demande (pas de cadence fixe)

  • Design review — l'autre PD comme œil neuf, dès qu'une maquette le mérite.
  • Handoff designer↔designer — checklist écrite quand un sujet passe de l'un à l'autre.
  • Point impromptu 15 min — si un sujet bloque, plutôt que d'attendre la weekly.

Async — la colonne vertébrale

  • Canal #design, un thread par sujet : les décisions se tracent à l'écrit (crucial les jours en remote).
  • Partage de veille 1×/semaine (async).
  • Pas de daily formel.

Team-level (léger)

  • Démo design ≥1×/mois — montrer ce qui a shippé à produit / tech / care. Se brancher sur un rituel démo existant si possible plutôt qu'en créer un.

Hors design-à-design (rappel, à ne pas dupliquer)

1-1 avec Romain (manager) · cadrage feature avec un dev avant design · QA design avant ship.

Gouvernance documentaire

  • Le PD référent reste DRI du domaine design dans le Brain.
  • Les deux PD contribuent aux canons et au DS Uimmo.
  • L'owner d'une page spécialisée suit l'owner du domaine concerné. Il ne reste pas chez Romain par héritage historique.

Anti-patterns

Anti-pattern Signal Correction
Deux PD, zéro owner sur un sujet « On le prend à deux » → personne ne tranche Désigner un PD owner par sujet
Divergence de goût sur le DS Deux styles qui cohabitent dans Uimmo PD référent garant du core ; lentille lean comme arbitre
Passation à l'oral Sujet repris sans contexte écrit Handoff designer↔designer tracé (checklist ci-dessus)
Double validation systématique Tout sujet relu par les 2 → lenteur Owner décide, l'autre challenge en review, pas en gate

État actuel

Dernière mise à jour : 2026-09-16

  • 2026-08-20 : premier chantier Storybook partagé. Review design croisée entre PD, review technique du code et merge confié au référent technique. (ADR 2026-08-20)

  • V1 créée le 2026-06-10 pour cadrer la collaboration à deux PD.

  • Répartition par sujet au fil de l'eau (pas de découpage produit).
  • Arbitrage : le PD référent tranche si un désaccord persiste.
  • DS core : les deux PD sont co-owners d'Uimmo ; la tech review l'implémentation.
  • Handoff designer↔designer formalisé (checklist de passation).
  • 2026-09-14 : gouvernance DS et ownership documentaire clarifiés.
  • 2026-06-10 : section « Rituels & cadence » ajoutée (cadence minimale, hybride : weekly sync fixe + review/handoff/DS à la demande, async par défaut).

Pages liées

Sources