mirror of
https://github.com/MaksTinyWorkshop/_Assistant_Lead_Tech
synced 2026-04-06 21:41:42 +02:00
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:
@@ -30,6 +30,7 @@ Patterns éprouvés en production ou en projets réels.
|
|||||||
|
|
||||||
- `10_backend_patterns_valides.md`
|
- `10_backend_patterns_valides.md`
|
||||||
- `10_frontend_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_backend_risques_et_vigilance.md`
|
||||||
- `10_frontend_risques_et_vigilance.md`
|
- `10_frontend_risques_et_vigilance.md`
|
||||||
|
- `10_ux_risques_et_vigilance.md`
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|||||||
70
10_ux_patterns_valides.md
Normal file
70
10_ux_patterns_valides.md
Normal 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**.
|
||||||
47
10_ux_risques_et_vigilance.md
Normal file
47
10_ux_risques_et_vigilance.md
Normal 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)_
|
||||||
@@ -309,7 +309,7 @@ En pratique :
|
|||||||
DATE — PROJET
|
DATE — PROJET
|
||||||
|
|
||||||
FILE_UPDATE_PROPOSAL
|
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 :
|
Pourquoi :
|
||||||
<raison en 1-2 phrases>
|
<raison en 1-2 phrases>
|
||||||
|
|||||||
@@ -57,13 +57,14 @@ Responsables de :
|
|||||||
Avant d'introduire un nouveau pattern, une nouvelle convention ou une nouvelle
|
Avant d'introduire un nouveau pattern, une nouvelle convention ou une nouvelle
|
||||||
architecture, les agents DOIVENT lire les fichiers Lead_tech correspondants.
|
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` |
|
| 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` |
|
| Frontend / mobile | `10_frontend_patterns_valides.md`, `10_frontend_risques_et_vigilance.md` |
|
||||||
| Architecture / design | `40_decisions_et_archi.md` |
|
| UX / design | `10_ux_patterns_valides.md`, `10_ux_risques_et_vigilance.md` |
|
||||||
| Debug / investigation | `90_debug_et_postmortem.md` |
|
| Architecture / design | `40_decisions_et_archi.md` |
|
||||||
| n8n / automatisations | `10_n8n_patterns_valides.md`, `10_n8n_nodes_a_risques.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
|
Règle : **si un pattern Lead_tech existe et couvre le besoin, l'appliquer
|
||||||
directement sans réinventer**.
|
directement sans réinventer**.
|
||||||
@@ -124,7 +125,7 @@ Un apprentissage mérite d'être remonté si :
|
|||||||
DATE — PROJET
|
DATE — PROJET
|
||||||
|
|
||||||
FILE_UPDATE_PROPOSAL
|
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 :
|
Pourquoi :
|
||||||
<raison en 1-2 phrases>
|
<raison en 1-2 phrases>
|
||||||
|
|||||||
@@ -29,7 +29,7 @@ Chaque proposition doit suivre ce format :
|
|||||||
DATE — PROJET
|
DATE — PROJET
|
||||||
|
|
||||||
FILE_UPDATE_PROPOSAL
|
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 :
|
Pourquoi :
|
||||||
<raison pour laquelle ce savoir mérite d'être capitalisé>
|
<raison pour laquelle ce savoir mérite d'être capitalisé>
|
||||||
|
|||||||
@@ -15,8 +15,10 @@ une solution dans leur domaine respectif.
|
|||||||
| ------------------------------------- | ---------------------------------------------- |
|
| ------------------------------------- | ---------------------------------------------- |
|
||||||
| `10_backend_patterns_valides.md` | Patterns backend validés en conditions réelles |
|
| `10_backend_patterns_valides.md` | Patterns backend validés en conditions réelles |
|
||||||
| `10_frontend_patterns_valides.md` | Patterns frontend/mobile validés |
|
| `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_backend_risques_et_vigilance.md` | Risques et anti-patterns backend |
|
||||||
| `10_frontend_risques_et_vigilance.md` | Risques et anti-patterns frontend |
|
| `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) |
|
| `40_decisions_et_archi.md` | Décisions techniques (mini-ADR) |
|
||||||
| `90_debug_et_postmortem.md` | Post-mortems et bugs capitalisés |
|
| `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_backend_patterns_valides.md`
|
||||||
- `10_frontend_patterns_valides.md`
|
- `10_frontend_patterns_valides.md`
|
||||||
|
- `10_ux_patterns_valides.md`
|
||||||
- `10_backend_risques_et_vigilance.md`
|
- `10_backend_risques_et_vigilance.md`
|
||||||
- `10_frontend_risques_et_vigilance.md`
|
- `10_frontend_risques_et_vigilance.md`
|
||||||
|
- `10_ux_risques_et_vigilance.md`
|
||||||
- `40_decisions_et_archi.md`
|
- `40_decisions_et_archi.md`
|
||||||
- `90_debug_et_postmortem.md`
|
- `90_debug_et_postmortem.md`
|
||||||
|
|
||||||
|
|||||||
@@ -103,7 +103,10 @@ build_memory() {
|
|||||||
bmm-pm)
|
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."
|
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."
|
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
|
esac
|
||||||
@@ -141,7 +144,7 @@ Format :
|
|||||||
DATE — ${PROJECT_NAME}
|
DATE — ${PROJECT_NAME}
|
||||||
|
|
||||||
FILE_UPDATE_PROPOSAL
|
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 :
|
Pourquoi :
|
||||||
<raison en 1-2 phrases>
|
<raison en 1-2 phrases>
|
||||||
|
|||||||
Reference in New Issue
Block a user