feat: ajout couverture UX/UI dans Lead_tech

- Création 10_ux_patterns_valides.md et 10_ux_risques_et_vigilance.md
- Référencés dans 00_INDEX.md, _AI_INSTRUCTIONS.md, CLAUDE.md
- Tableau de lecture BMAD mis à jour (ligne UX ajoutée)
- Format Fichier cible mis à jour partout pour inclure les fichiers UX
- post-bmad-install.sh : memory bmm-ux-designer pointe vers les bons fichiers
This commit is contained in:
MaksTinyWorkshop
2026-03-08 19:27:08 +01:00
parent 8e8c1c4e1c
commit 18341c10a1
8 changed files with 138 additions and 11 deletions

View File

@@ -30,6 +30,7 @@ Patterns éprouvés en production ou en projets réels.
- `10_backend_patterns_valides.md`
- `10_frontend_patterns_valides.md`
- `10_ux_patterns_valides.md`
---
@@ -43,6 +44,7 @@ Situations connues pouvant entraîner :
- `10_backend_risques_et_vigilance.md`
- `10_frontend_risques_et_vigilance.md`
- `10_ux_risques_et_vigilance.md`
---

70
10_ux_patterns_valides.md Normal file
View File

@@ -0,0 +1,70 @@
# Patterns UX/UI validés
Ce fichier contient **uniquement** des patterns UX/UI :
- observés en conditions réelles,
- validés sur des projets livrés,
- utiles à réutiliser sur d'autres produits.
Objectif : éviter de redélibérer sur des sujets déjà tranchés et capitaliser
ce qui fonctionne du point de vue utilisateur.
Dernière mise à jour : 2026-03-08
---
## Règle d'or
Si ce n'est pas **validé par l'usage ou l'expérience projet**, ça n'a pas sa place ici.
- Pas de "bonnes pratiques" génériques
- Pas de conseils théoriques sans contexte
- Toujours préciser le contexte (type d'app, audience, plateforme)
---
## Périmètre couvert
- Patterns d'interaction (navigation, feedback, états)
- Formulaires et flows critiques (auth, onboarding, checkout)
- Gestion des états vides, d'erreur et de chargement
- Accessibilité au niveau design
- Conventions de design system
- Décisions UX structurantes validées
---
## Format standard d'un pattern
## Pattern : <Nom clair>
- Objectif : …
- Contexte : …
- Quand l'utiliser : …
- Quand l'éviter : …
- Avantage : …
- Limites / vigilance : …
- Validé le : DD-MM-YYYY
- Contexte produit : (obligatoire) ex. `App mobile / auth` ou `Webapp B2B / dashboard`
### Description
(comportement attendu, logique d'interaction, règles visuelles clés)
### Checklist (si pertinente)
---
## Index
_(à remplir au fil des validations)_
---
## Notes importantes
- On préfère 5 patterns solides à 50 "guidelines de design".
- Un pattern UX = une décision d'interaction assumée + son cadre d'application.
- La frontière avec `10_frontend_patterns_valides.md` :
ce fichier traite **l'intention UX et le comportement attendu**,
le fichier frontend traite **l'implémentation technique**.

View File

@@ -0,0 +1,47 @@
# Risques et anti-patterns UX/UI
Ce fichier recense les **erreurs UX récurrentes**, les pièges connus
et les anti-patterns observés en conditions réelles.
Objectif : ne pas répéter les mêmes erreurs de conception d'un projet à l'autre.
Dernière mise à jour : 2026-03-08
---
## Règle d'or
Chaque entrée doit être **issue d'un problème réel**, pas d'une opinion.
- Toujours préciser l'impact observé (abandon, confusion, support, bug signalé)
- Toujours proposer l'alternative correcte
---
## Périmètre couvert
- Anti-patterns d'interaction
- Pièges sur les flows critiques (auth, onboarding, formulaires)
- Erreurs fréquentes sur les états (vide, erreur, chargement)
- Accessibilité — erreurs courantes
- Décisions UX qui semblent bonnes mais posent problème
---
## Format standard
## Anti-pattern : <Nom clair>
- Problème : …
- Impact observé : …
- Contexte : …
- À éviter parce que : …
- Alternative correcte : …
- Observé le : DD-MM-YYYY
- Contexte produit : ex. `App mobile / onboarding` ou `Webapp / formulaire`
---
## Index
_(à remplir au fil des observations)_

View File

@@ -309,7 +309,7 @@ En pratique :
DATE — PROJET
FILE_UPDATE_PROPOSAL
Fichier cible : <10_backend_patterns_valides.md | 10_frontend_patterns_valides.md | 10_backend_risques_et_vigilance.md | 10_frontend_risques_et_vigilance.md | 40_decisions_et_archi.md | 90_debug_et_postmortem.md>
Fichier cible : <10_backend_patterns_valides.md | 10_frontend_patterns_valides.md | 10_ux_patterns_valides.md | 10_backend_risques_et_vigilance.md | 10_frontend_risques_et_vigilance.md | 10_ux_risques_et_vigilance.md | 40_decisions_et_archi.md | 90_debug_et_postmortem.md>
Pourquoi :
<raison en 1-2 phrases>

View File

@@ -57,13 +57,14 @@ Responsables de :
Avant d'introduire un nouveau pattern, une nouvelle convention ou une nouvelle
architecture, les agents DOIVENT lire les fichiers Lead_tech correspondants.
| Type de tâche | Fichiers à lire en priorité |
| ---------------------- | --------------------------------------------------------------------------------- |
| Type de tâche | Fichiers à lire en priorité |
| ----------------------- | --------------------------------------------------------------------------------- |
| Backend (API, services) | `10_backend_patterns_valides.md`, `10_backend_risques_et_vigilance.md` |
| Frontend / mobile | `10_frontend_patterns_valides.md`, `10_frontend_risques_et_vigilance.md` |
| Architecture / design | `40_decisions_et_archi.md` |
| Debug / investigation | `90_debug_et_postmortem.md` |
| n8n / automatisations | `10_n8n_patterns_valides.md`, `10_n8n_nodes_a_risques.md` |
| Frontend / mobile | `10_frontend_patterns_valides.md`, `10_frontend_risques_et_vigilance.md` |
| UX / design | `10_ux_patterns_valides.md`, `10_ux_risques_et_vigilance.md` |
| Architecture / design | `40_decisions_et_archi.md` |
| Debug / investigation | `90_debug_et_postmortem.md` |
| n8n / automatisations | `10_n8n_patterns_valides.md`, `10_n8n_nodes_a_risques.md` |
Règle : **si un pattern Lead_tech existe et couvre le besoin, l'appliquer
directement sans réinventer**.
@@ -124,7 +125,7 @@ Un apprentissage mérite d'être remonté si :
DATE — PROJET
FILE_UPDATE_PROPOSAL
Fichier cible : <nom_du_fichier>
Fichier cible : <10_backend_patterns_valides.md | 10_frontend_patterns_valides.md | 10_ux_patterns_valides.md | 10_backend_risques_et_vigilance.md | 10_frontend_risques_et_vigilance.md | 10_ux_risques_et_vigilance.md | 40_decisions_et_archi.md | 90_debug_et_postmortem.md>
Pourquoi :
<raison en 1-2 phrases>

View File

@@ -29,7 +29,7 @@ Chaque proposition doit suivre ce format :
DATE — PROJET
FILE_UPDATE_PROPOSAL
Fichier cible : <nom_du_fichier>
Fichier cible : <10_backend_patterns_valides.md | 10_frontend_patterns_valides.md | 10_ux_patterns_valides.md | 10_backend_risques_et_vigilance.md | 10_frontend_risques_et_vigilance.md | 10_ux_risques_et_vigilance.md | 40_decisions_et_archi.md | 90_debug_et_postmortem.md>
Pourquoi :
<raison pour laquelle ce savoir mérite d'être capitalisé>

View File

@@ -15,8 +15,10 @@ une solution dans leur domaine respectif.
| ------------------------------------- | ---------------------------------------------- |
| `10_backend_patterns_valides.md` | Patterns backend validés en conditions réelles |
| `10_frontend_patterns_valides.md` | Patterns frontend/mobile validés |
| `10_ux_patterns_valides.md` | Patterns UX/UI validés |
| `10_backend_risques_et_vigilance.md` | Risques et anti-patterns backend |
| `10_frontend_risques_et_vigilance.md` | Risques et anti-patterns frontend |
| `10_ux_risques_et_vigilance.md` | Risques et anti-patterns UX/UI |
| `40_decisions_et_archi.md` | Décisions techniques (mini-ADR) |
| `90_debug_et_postmortem.md` | Post-mortems et bugs capitalisés |
@@ -63,8 +65,10 @@ Après validation, le contenu est déplacé vers le fichier approprié :
- `10_backend_patterns_valides.md`
- `10_frontend_patterns_valides.md`
- `10_ux_patterns_valides.md`
- `10_backend_risques_et_vigilance.md`
- `10_frontend_risques_et_vigilance.md`
- `10_ux_risques_et_vigilance.md`
- `40_decisions_et_archi.md`
- `90_debug_et_postmortem.md`

View File

@@ -103,7 +103,10 @@ build_memory() {
bmm-pm)
echo "When a product decision, prioritization pattern, or recurring friction is identified, write a proposal to ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md (NUC: /srv/projects/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — ${PROJECT_NAME} / FILE_UPDATE_PROPOSAL / Fichier cible: <target file> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files."
;;
bmm-tech-writer|bmm-ux-designer)
bmm-ux-designer)
echo "When a reusable UX/UI pattern, interaction anti-pattern, or UX decision emerges, write a proposal to ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md (NUC: /srv/projects/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — ${PROJECT_NAME} / FILE_UPDATE_PROPOSAL / Fichier cible: <10_ux_patterns_valides.md | 10_ux_risques_et_vigilance.md | 40_decisions_et_archi.md> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files."
;;
bmm-tech-writer)
echo "${base}, write a proposal to ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md (NUC: /srv/projects/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — ${PROJECT_NAME} / FILE_UPDATE_PROPOSAL / Fichier cible: <target file> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files."
;;
esac
@@ -141,7 +144,7 @@ Format :
DATE — ${PROJECT_NAME}
FILE_UPDATE_PROPOSAL
Fichier cible : <10_backend_patterns_valides.md | 10_frontend_patterns_valides.md | 10_backend_risques_et_vigilance.md | 10_frontend_risques_et_vigilance.md | 40_decisions_et_archi.md | 90_debug_et_postmortem.md>
Fichier cible : <10_backend_patterns_valides.md | 10_frontend_patterns_valides.md | 10_ux_patterns_valides.md | 10_backend_risques_et_vigilance.md | 10_frontend_risques_et_vigilance.md | 10_ux_risques_et_vigilance.md | 40_decisions_et_archi.md | 90_debug_et_postmortem.md>
Pourquoi :
<raison en 1-2 phrases>