mirror of
https://github.com/MaksTinyWorkshop/_Assistant_Lead_Tech
synced 2026-06-28 01:53:40 +02:00
MaksTinyWorkshop
81fde91259
Triage et intégration des propositions workflow et UX du buffer 95_a_capitaliser.md. WORKFLOW : - risques/story-tracking.md : 24 risques de suivi de story (enabler AC non-bloquant, tests plumbing vs scénario, reformat hors scope, xit sans story de suivi, re-scope mid-PR, statut migré non vérifié, périmètre auto-déclaré vs git diff, composant/page livré sans câblage — reciblages venus de backend #21 et frontend #257) - patterns/general.md : audit cartographique pré-chantier, Go/No-Go par lot, sub-agent review fresh-context, sweep read-only délégué (#156), revue adverse de spec, audit-first migration UX (domaine amorcé — était vide) : - patterns/general.md : 9 patterns (mount-based read, fiche détail single-scroll, FAB étendu, ligne de contexte filtres, état read-only caché, avatar par hash, audit a11y touch targets) - risques/general.md : 5 risques (bouton retour dans ScrollView #108, lien sans handler, wording cross-écran divergent, token sans détection, padding multi-écrans) - READMEs ux/workflow mis à jour Vérifié : aucun doublon d'ancre/titre, fichiers racine 40_/90_ non modifiés (propositions réservées pour validation séparée). Source 95_ non purgée (purge en fin de capitalisation). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
120 lines
5.6 KiB
Markdown
120 lines
5.6 KiB
Markdown
---
|
|
title: UX — Risques & vigilance : Général
|
|
domain: ux
|
|
bucket: risques
|
|
tags: [mobile, navigation, handler, wording, tokens, a11y]
|
|
applies_to: [design, implementation, review]
|
|
severity: medium
|
|
validated_on: 2026-06-25
|
|
source_projects: [app-alexandrie]
|
|
---
|
|
|
|
# UX — Risques & vigilance : Général
|
|
|
|
> Extrait de la base de connaissance Lead_tech. Voir `knowledge/ux/risques/README.md` pour l'index complet.
|
|
|
|
---
|
|
|
|
<a id="risque-ux-back-button-dans-scrollview"></a>
|
|
## Bouton retour placé à l'intérieur du ScrollView
|
|
|
|
### Risques
|
|
|
|
- Sur une app mobile RN/Expo avec une TopBar globale sans back natif, un bouton retour ajouté localement dans le `<ScrollView>` disparaît dès que l'utilisateur défile
|
|
- Sur une page critique (gestion d'abonnement, résiliation, support), perdre l'accès au retour pendant le scroll est un piège UX direct
|
|
|
|
### Symptômes
|
|
|
|
- Le bouton retour est le premier enfant du contenu scrollable et défile avec lui ; il devient inaccessible plus bas dans une page longue
|
|
|
|
### Bonnes pratiques / mitigations
|
|
|
|
- Tout bouton retour local doit vivre **hors du ScrollView** : header local sticky en `<View>` parent (flex:1) + ScrollView frère.
|
|
- Stop conditions : ne PAS doubler `insets.top` (le header le consomme → `contentInset.top = 0`) ; ne PAS placer le bouton dans `contentContainerStyle`. Si l'app utilise `<Stack.Screen>` Expo Router avec header natif, préférer `headerBackVisible: true`.
|
|
- Filet de test : test statique vérifiant qu'un fichier avec `handleBack` ne place pas le `<Pressable accessibilityLabel="Retour">` dans un `<ScrollView>`.
|
|
|
|
- Contexte technique : RN/Expo + TopBar globale — app-alexandrie 28-05-2026 (ux-cleanup-2)
|
|
|
|
---
|
|
|
|
<a id="risque-ux-bouton-sans-handler-hors-scope"></a>
|
|
## Bouton/lien sans handler laissé dans l'UI ("hors scope")
|
|
|
|
### Risques
|
|
|
|
- Un bouton survit dans l'UI sans `onPress` (résidu de template ou de dépendance retirée) : il tapote sans rien faire → boucle de frustration, l'utilisateur conclut que l'app est cassée et abandonne (grave sur le flow auth, critique pour l'acquisition)
|
|
- "Hors scope" utilisé comme argument pour laisser passer → dérive de dette story après story
|
|
|
|
### Symptômes
|
|
|
|
- `<TouchableOpacity>` / `<Pressable>` visible sans prop `onPress` (ex. bouton "Facebook" sans OAuth côté API)
|
|
|
|
### Bonnes pratiques / mitigations
|
|
|
|
- **Règle** : tout bouton/lien visible doit avoir un `onPress` qui fait quelque chose. Si la feature n'est pas livrée : supprimer le bouton (défaut) ; OU le mettre derrière un feature flag interne ; OU afficher un toast/modal "Bientôt disponible".
|
|
- Garde-fou review : grep `<TouchableOpacity`/`<Pressable` sans `onPress=` → finding HIGH. "Hors scope" n'est jamais un permis : un bouton mort sur un écran qu'on édite est dans le scope.
|
|
|
|
- Contexte technique : RN/Expo — app-alexandrie 29-05-2026 (ux-cleanup-5, login.tsx)
|
|
|
|
---
|
|
|
|
<a id="risque-ux-wording-divergent-cross-ecran"></a>
|
|
## Wording divergent cross-écran pour le même état métier
|
|
|
|
### Risques
|
|
|
|
- Deux écrans/composants affichent le même état métier (`NOT_STARTED`, `OUT_OF_STOCK`) avec des libellés différents, souvent parce que livrés par des stories distinctes
|
|
- L'utilisateur traverse les écrans et voit deux mots pour le même état → confusion ; ne casse aucun test, dette qui s'accumule en silence
|
|
|
|
### Symptômes
|
|
|
|
- `CourseListItem` affiche "Nouveau" pour `NOT_STARTED`, `ProgressionInline` affiche "Pas encore commencé" pour le même état
|
|
|
|
### Bonnes pratiques / mitigations
|
|
|
|
- Centraliser le mapping état → libellé dans une seule fonction pure exportée (`statusLabel(state) => string`) consommée par tous les écrans.
|
|
- Review : grep les libellés de status sur les écrans du domaine ; > 1 wording par état = finding MEDIUM.
|
|
- Préférer les libellés courts et positifs ("Nouveau" > "Pas encore commencé").
|
|
|
|
- Contexte technique : RN/Expo — app-alexandrie 29-05-2026 (ux-cleanup-6/7)
|
|
|
|
---
|
|
|
|
<a id="risque-ux-regle-token-sans-detection"></a>
|
|
## Règle d'usage de token sans stratégie de détection
|
|
|
|
### Risques
|
|
|
|
- Un token décoratif (`outlineVariant` MD3 marqué "ne pas utiliser pour des séparations fonctionnelles") continue d'être utilisé pour des bordures fonctionnelles
|
|
- La règle reste écrite dans le README mais inappliquée → divergence README vs code
|
|
|
|
### Symptômes
|
|
|
|
- Callsites résiduels utilisant le token décoratif en `borderColor`/`borderTopColor` malgré la règle documentée
|
|
|
|
### Bonnes pratiques / mitigations
|
|
|
|
- **Une règle d'usage de token doit être assortie d'une stratégie de détection** : (1) lint custom qui flag le token dans une prop bordure/couleur ; (2) audit récurrent (CI cron qui liste les usages) ; (3) renommer le token (`outlineDecorative` rend l'intention explicite).
|
|
- Le coût "écrire la règle" est ~10 min, le coût "détecter les violations" est récurrent — investir dans la détection automatique.
|
|
|
|
- Contexte technique : design tokens MD3 — app-alexandrie 30-05-2026 (ux-cleanup-8/11)
|
|
|
|
---
|
|
|
|
<a id="risque-ux-touch-target-padding-composant-partage"></a>
|
|
## Augmenter le padding d'un composant réutilisé multi-écrans (touch targets)
|
|
|
|
### Risques
|
|
|
|
- Élargir un touch target en augmentant le `padding` d'un composant réutilisé multi-écrans casse le layout des callers (liste serrée, ligne d'icônes header avec gap fixe)
|
|
|
|
### Symptômes
|
|
|
|
- Une cible tactile passe sous 44pt ; la corriger par `padding` change la taille visuelle et décale les callers
|
|
|
|
### Bonnes pratiques / mitigations
|
|
|
|
- Pour un composant réutilisé, préférer `hitSlop` au `padding` : seul effet = zone tap étendue, taille visuelle inchangée (cf. pattern d'audit dans `ux/patterns/general.md`).
|
|
|
|
- Contexte technique : RN/Expo a11y — app-alexandrie 31-05-2026 (ux-cleanup-14)
|