Aller au contenu

Patterns UX Bricks

Bibliothèque de patterns UX réutilisables observés et nommés chez Bricks. Pattern librarian : chaque entrée renvoie vers les screens Figma, les ADR, et les retours users qui l'ont validée — jamais de re-description longue.

Démarrage Phase 3 — bibliothèque vide. À enrichir au fil des observations, ingests, et discoveries design. Owner provisoire Romain jusqu'à arrivée d'un Product Designer.

Pourquoi cette bibliothèque

Les patterns UX qui marchent chez Bricks (confirmations lourdes pour les actes financiers, transparence pré-signature, réassurance avant abandon, etc.) sont aujourd'hui tacites. Ils émergent dans les conversations design, dans les choix sur tel ou tel parcours, mais ne sont jamais formalisés.

Conséquences :

  • Chaque nouveau sujet UI ré-invente la roue ou copie sans nommer.
  • L'arrivée d'un nouveau dev / PB / PD signifie 3 semaines à comprendre "pourquoi on fait comme ça ici".
  • Les arbitrages UX sont re-discutés à chaque review parce que personne ne peut pointer "le pattern X qu'on applique systématiquement".

Cette bibliothèque capitalise.

Convention d'un pattern

Chaque pattern est une page dédiée dans resources/patterns-ux-bricks/<nom-kebab>.md avec la structure :

---
title: <Nom du pattern>
type: resource
owner: <member ou auto>
last_updated: YYYY-MM-DD
tags: [pattern, ux, <domaine: finance | onboarding | care | navigation | ...>]
---

# <Nom du pattern>

## Problème user résolu
<1-2 phrases.>

## Quand l'appliquer
<Contexte d'application, critères de déclenchement.>

## Quand NE PAS l'appliquer
<Anti-contextes — éviter le sur-emploi.>

## Variantes
<Si plusieurs déclinaisons existent.>

## Exemples Bricks
- **<surface>** — [frame Figma](url) — [ADR si applicable](path)
- **<surface>** — ...

## Retours users / mesures
- [friction remontée](../../journal/ux-frictions.md#<ancre>) — date
- [test user / observation](path) — date
- [métrique bougée](path) — date

## Anti-patterns associés
- Le faux ami : <variante qui semble similaire mais ne marche pas>

## Sources
- [ADR / meeting / Slack / observation]

Patterns identifiés (V1)

[à enrichir] — pistes initiales repérées dans le wiki existant, à formaliser comme pages dédiées au fur et à mesure :

  • Confirmation lourde pour actes financiers irréversibles — KYC update, signature contrat, versement, retrait. Pattern observable dans plusieurs surfaces ; jamais formalisé.
  • Transparence pré-signature — afficher frais / engagement / risque AVANT le clic CTA, pas après. Lié au cadre conformité.
  • Réassurance avant abandon — KYC, parcours longs (signature, formulaires multi-étapes). Anti-pattern : ghosting silencieux.
  • Notification de fin de processus asynchrone — fin de scan IA, fin d'analyse, mise à disposition d'un dashboard. Où notifier (Slack vs CRM vs in-app) et comment. Lié à l'outil d'analyse.
  • Gestion des états vides côté back-office — quand un AM ouvre un dossier vide / partiel. Pattern observable dans plusieurs surfaces.
  • Co-branding chaîne (Fitness Park, Eva GG) — pattern UI à formaliser, lié au concept partenariats chaînes.

Ces pistes sont des suggestions à valider avant création des pages dédiées. Aucune n'est encore formalisée.

Comment alimenter cette bibliothèque

  1. Lors d'un ingest (prompts/ingest.md, meeting-summary.md) — si un pattern UX revient ≥ 2 fois (transcripts, ADR, observations), proposer la création d'une page dédiée.
  2. Lors d'un lint (prompts/lint.md) — section "Gaps design" peut suggérer un pattern à formaliser.
  3. Sur demande explicite — Romain ou le futur PD nomme un pattern observé et demande sa formalisation.
  4. Depuis le journal des frictions UX — une friction récurrente peut révéler un pattern correctif à formaliser.

État actuel

Dernière mise à jour : 2026-06-10

  • V1 squelette créée le 2026-05-29 dans le cadre de l'embarquement composante Design Phase 3.
  • Aucun pattern formalisé à ce jour — 6 pistes identifiées dans le wiki existant, à valider avant création.
  • À enrichir au fil des observations + à reprendre avec le PD à son arrivée.
  • 2026-06-10 : owner basculé romain → remy (Rémy owner du domaine design).

Pages liées

Sources