Aller au contenu

Product Design Bricks — cadre opératoire

Contexte

Cadre opératoire Bricks pour tout sujet Product Design : cadrage UI/UX, spec d'écran, parcours, composant DS, design review, projet à impact UI. Pas un cours — une lentille imposée aux points de décision (cf. règle design, AGENTS.md § Lentille design).

S'articule avec :

  • Lean PM Bricks — la lentille produit (problème, hypothèse, outcome) reste prioritaire. La lentille design s'enclenche après pour cadrer la solution UI.
  • Career Path Product Designer — référentiel d'évaluation autoritaire (3 piliers × 8 dimensions × 5 niveaux). Ce concept en extrait la méthode opérationnelle ; la grille reste source de vérité pour la progression individuelle.
  • Criticité features / AI Coding 2 voies — Vibe/Engineer = risque tech, indépendant du risque design.

Owner : remy (Product Designer). Ownership repris de romain le 2026-07-02 à l'arrivée du PD interne — cf. area design. V2 du canon à co-construire avec le PD (Rémy, + Pierre).

Périmètre

Inclus : UI produit (écrans Bricks, EF, back-office, outil d'analyse, PDP, app investisseur), parcours utilisateur, recherche utilisateur appliquée au produit, design system, ergonomie, accessibilité, prototypage testable.

Hors scope : branding / marketing design (à scinder si pertinent un jour — composante séparée).

Lexique imposé

Terme Définition Bricks
Zoning Découpage spatial brut d'un écran (blocs, hiérarchie), avant toute UI. Sur papier, whiteboard, ou cadres Figma vides.
Wireframe Structure d'écran en basse fidélité (boîtes, libellés, navigation), sans style visuel. Pas Figma final.
Mid-fi Maquette avec composants du DS, hiérarchie visuelle posée, sans pixel perfect. Niveau suffisant pour test UX et alignement tech.
High-fi Maquette de fidélité finale = spec dev. Inclut tous les états (vide, chargement, erreur, succès, edge).
Prototype interactif Maquettes liées avec interactions Figma, utilisé pour test user ou démo.
Parcours Enchaînement d'écrans / d'états du point de vue user pour accomplir un job. Englobe entrée, happy path, sorties, retours en arrière.
Edge case État ou enchaînement non standard mais réaliste (vide, erreur, lenteur réseau, donnée tronquée, refus permission, double clic, abandon).
État Variante d'un écran selon contexte : vide, chargement, succès, erreur, partiel, désactivé, hors ligne.
QA design Vérification après dev que l'implémentation respecte la maquette ET couvre tous les états spécifiés. Avant ship.
Handoff Transmission de la maquette finale au dev avec contexte, états, edge cases, et 1-1 préalable. Pas un dépôt Figma.
Design review Rituel d'équipe pour challenger une maquette en cours (zoning, mid-fi, ou high-fi). Différent du QA design.
Discovery design Phase amont : benchmarks, interviews légères (2-3 en 48h), formalisation hypothèses → directions.
Niveau de fidélité Choix conscient du degré de détail (zoning, wireframe, mid-fi, high-fi) selon ce qu'on cherche à apprendre ou valider.

Marqueurs wiki quand l'info manque dans un artefact (spec, ticket, projet, ADR) :

  • [parcours non spécifié] — pas d'enchaînement utilisateur décrit
  • [edge cases non couverts] — uniquement happy path
  • [fidélité non justifiée] — high-fi demandé sans justification
  • [QA design non passée] — implémentation non vérifiée vs maquette
  • [états non listés] — pas de couverture vide / erreur / chargement
  • [accessibilité non vérifiée] — contraste, navigation clavier, lecteur d'écran

Distinction output / outcome côté design

Output design Outcome associé (exemple)
Maquette KYC update Figma livrée Taux de complétion KYC périodique ≥ X % à J+30, drop-off identifié sur étapes 2 et 3 (kyc-update-lemonway)
Composant DS « Card projet » publié Réutilisation sur ≥ 3 surfaces dans le mois, 0 variante one-off créée à côté
Refonte parcours analyse projet Temps user pour analyser un dossier passe de N min à M min, # erreurs de saisie ↓ (outil d'analyse)
Écran de réception fonds PDP Aucun appel support « où en est mon projet » sur la fenêtre J→J+7 post-financement

Livrer ≠ réussir. Une maquette validée et shippée sans mesure post-launch est un output sans outcome — à challenger.

Principes Bricks (V1)

Extraits et formalisés depuis la grille PD (pilier Craft & Exécution, pilier Collaboration) et l'ADN startup Bricks. À challenger / enrichir avec le PD à l'arrivée.

  1. Démarrer en zoning ou wireframe — jamais en Figma final. Le pixel perfect d'emblée bloque les itérations cheap. Zoning sur papier ou cadres vides en premier (grille PD2 / PD3).
  2. 2-3 directions avant de détailler une. Élargir l'espace créatif en début de sujet, puis converger. Une seule direction = pas de comparaison possible, biais d'ancrage.
  3. Niveau de fidélité juste nécessaire pour apprendre. Sketch / wireframe si on veut tester une idée, mid-fi pour aligner tech, high-fi uniquement quand la solution est validée. Justifier la fidélité dans la spec.
  4. Timebox les phases d'UI. Ex : 2h max avant review, 1 journée max avant cadre tech, sinon arbitrage / découpage. Pattern grille PD2.
  5. Cadrer chaque feature avec un dev avant le design final. Intégration des contraintes tech tôt — évite les retouches massives en QA. Pattern PD2 / PD3.
  6. Maquette = spec dev. Le niveau de détail attendu en high-fi inclut tous les états, edge cases, transitions, copies finales. Le dev ne devine pas. Pattern PD3.
  7. QA design systématique avant ship. Pas de feature mise en prod sans vérification que l'implémentation respecte la maquette ET couvre les états spécifiés. Pattern PD2.
  8. Tester pour apprendre, pas pour valider. Prototype + ≥ 1 utilisateur réel en < 24h après le design pour les sujets à risque UX. 1 objectif clair par test, checklist de points à (in)valider. Pattern PD2 / PD3.
  9. Couvrir les états, pas seulement le happy path. Vide, chargement, erreur, partiel, edge. Listés explicitement dans la spec.
  10. Documenter pourquoi une solution est choisie. Compromis UX listés, alternatives évoquées, raisons du choix. Pattern PD2. Évite la re-discussion en design review N+1.
  11. Design system d'abord, one-off en dernier. Si un besoin n'est pas couvert par le DS, on fait évoluer le DS, on ne crée pas une variante locale. Pattern PD2 / PD3. (Garde-fou : sans PD owner du DS, ce principe est aspirationnel ; à l'arrivée du PD, à arbitrer.)
  12. Le risque design est distinct du risque tech. Un sujet Vibe peut porter un risque UX élevé (parcours irréversible, finance, KYC) et inversement. La lentille design s'applique indépendamment de la classification criticité features / AI Coding.

Cycle Bricks (référence)

flowchart LR
    discovery["Discovery design - 2-3 interviews + benchmark"]
    zoning["Zoning ou wireframe"]
    dirs["2-3 directions"]
    midfi["Mid-fi + cadrage tech"]
    review["Design review"]
    highfi["High-fi = spec"]
    handoff["Handoff dev avec 1-1"]
    qa["QA design"]
    ship["Ship"]
    measure["Mesure outcome"]
    discovery --> zoning --> dirs --> midfi --> review --> highfi --> handoff --> qa --> ship --> measure
    measure -.->|itération si outcome non atteint| zoning

Pas linéaire dans tous les sujets. Pour un patch DS ou une variante de composant existant, on saute directement à mid-fi. Pour un sujet à risque UX fort (finance, KYC, parcours irréversible), on insère un test utilisateur entre mid-fi et high-fi.

Checklist — 5 questions design (sujet UI/UX)

À appliquer en complément des 5 questions lean, une fois l'hypothèse formulée :

  1. Quel parcours user (entrée, happy path, sorties, retours arrière) ?
  2. Quels scénarios couverts (happy + edge cases identifiés explicitement) ?
  3. Quel niveau de fidélité retenu, et pourquoi celui-là (qu'est-ce qu'on cherche à apprendre / valider à ce niveau) ?
  4. Quel plan de test UX (qui teste, sur quoi, avec quel objectif, dans quel délai) ?
  5. Quels critères de QA design (états listés, edge cases, accessibilité minimale) ?

Marqueurs à insérer dans l'artefact si une réponse manque (voir Lexique).

Anti-patterns

Anti-pattern Signal Correction
Figma final d'emblée « J'envoie la maquette pixel perfect » sans zoning Demander le wireframe / 2-3 directions amont
Direction unique « Voilà la maquette » Demander 2-3 directions avant détail
Pas de QA design Feature mise en prod sans vérification vs maquette Bloquer le merge sur QA design passée
Edge cases en prod Bug remonté par user que personne n'avait imaginé Lister les états dans la spec avant build
Handoff sans 1-1 dev Maquette « partagée Figma », point Imposer 1-1 dev cadrage + 1-1 dev handoff
One-off à côté du DS Nouvelle variante créée localement par feature Faire évoluer le DS, pas contourner
Test pour valider Test post-design qui confirme ce qu'on voulait entendre Formuler les questions falsifiantes avant le test
Design avant problème Maquette d'une feature dont on n'a pas formulé le problème user Revenir à la lentille lean

Où la lentille s'applique dans le repo

Point de friction Artefact / règle
Conversations Cursor .cursor/rules/design.mdc
Agents cloud prompts/_SHARED_RULES.md § Lentille design
Ingest meetings prompts/ingest.md, prompts/meeting-summary.md
Projects wiki projects/TEMPLATE/README.md
Tickets / specs .cursor/rules/specs-pour-agent.mdc
ADR à impact UI prompts/adr-draft.md, decisions/TEMPLATE.md
Lint mensuel scripts/src/lint.ts, prompts/lint.md

Articulation avec les autres lentilles

flowchart TB
    lean["Lentille Lean PM - problème, hypothèse, outcome"]
    design["Lentille Design - parcours, états, fidélité, QA"]
    crit["Criticité features - Vibe/Engineer risque tech"]
    sujet["Sujet produit avec impact UI"]
    sujet --> lean
    lean -->|hypothèse formulée| design
    sujet --> crit
    design -.->|indépendant| crit

Ordre canonique : lean d'abord (problème → hypothèse → outcome), design ensuite (parcours → fidélité → QA), criticité tech en parallèle (Vibe/Engineer). Pas de design avant problème. Pas de criticité tech qui exempte d'une lentille design.

État actuel

Dernière mise à jour : 2026-05-29

  • V1 publiée le 2026-05-29 — canon initial extrait de la grille PD + co-construit avec Romain. Owner provisoire romain jusqu'à arrivée d'un Product Designer.
  • Lentille embarquée — règle Cursor [.cursor/rules/design.mdc](../.cursor/rules/design.mdc) alwaysApply, section dans AGENTS.md, entrée dans prompts/_SHARED_RULES.md.
  • Lien DS Figma : [URL DS Figma à renseigner avec Romain] — placeholder, à remplir Phase 1.
  • Heuristiques UX spécifiques Bricks (au-delà des 12 principes V1) : [à enrichir Romain] — V1 volontairement extraite de la grille PD pour ne pas inventer.
  • Articulation lentille lean ↔ design actée : lean d'abord, design après hypothèse formulée.
  • Phase 1 prévue : étoffer areas/design/index.md + créer concepts dérivés (DS, QA design, design review, handoff, discovery design).

Sources