Aller au contenu

Design Review

Définition

Rituel d'équipe pour challenger une maquette en cours de design (zoning, mid-fi, ou high-fi avant handoff). L'objectif est de challenger les décisions, lister les compromis, identifier les edge cases manquants, aligner produit ↔ design ↔ tech. Différent du QA design (qui vérifie l'implémentation post-dev).

Page concept V1 — validée avec Rémy (PD) le 2026-05-29.

Pourquoi

Sans design review :

  • Les compromis UX sont implicites et re-discutés à chaque review N+1.
  • Les edge cases sont découverts trop tard (en handoff ou en QA design).
  • Les contraintes tech ne sont pas intégrées au bon moment.
  • Le PD travaille en silo, sans challenge.

Place dans le cycle

flowchart LR
    midfi["Mid-fi"]
    review["Design review"]
    highfi["High-fi"]
    handoff["Handoff dev"]
    qa["QA design"]
    midfi --> review --> highfi --> handoff --> qa

Au moins une design review entre mid-fi et high-fi sur les sujets à impact UI. Pour les sujets à fort risque UX (finance, KYC, parcours irréversible), une review supplémentaire à l'issue du zoning / des 2-3 directions est utile.

Format proposé (V1)

Proposition de format à itérer (format V1 validé avec Rémy le 2026-05-29).

  • Cadence : ad hoc par sujet — une review est organisée quand un sujet le nécessite, pas de créneau fixe.
  • Durée : 30-45 min.
  • Participants : owner du design (PD ou PB), 1 PM (cadrage), 1 dev concerné (contraintes tech), 1 reviewer "frais" (pas impliqué dans le sujet — œil neuf).
  • Prep amont : 1 page de prep (problème + hypothèse + parcours + 2-3 directions + questions ouvertes) — uniquement sur les sujets significatifs (parcours complet, nouvelle surface). Pas de prep obligatoire pour une retouche ou un composant isolé.
  • Livrable post-review : décisions actées + compromis listés + edge cases identifiés à traiter + action items.

Critères de challenge (V1)

Questions standards à poser sur toute maquette en review :

  1. Quel problème user est résolu ? (rappel lentille lean)
  2. Quelles directions ont été écartées et pourquoi ? (vérifier qu'il y en a eu)
  3. Quels edge cases sont identifiés ? (vide, erreur, abandon, lenteur, donnée tronquée)
  4. Quels états sont prévus ? (vide, chargement, erreur, partiel, désactivé)
  5. Quelle accessibilité minimale ? (contraste, clavier, labels)
  6. Quelles contraintes tech ne sont pas encore intégrées ?
  7. Quel plan de test UX avant ship ?
  8. Quel niveau de fidélité est demandé, et pourquoi ? (justifier ce niveau-là)

Anti-patterns

Anti-pattern Signal Correction
Review = présentation Le designer montre, personne ne challenge Imposer les 8 questions ci-dessus
Review post-high-fi Review uniquement quand tout est figé Forcer une review intermédiaire mid-fi
Pas de prep Arrivée en review sans contexte écrit Imposer la 1 page de prep amont
Review = comité de validation « On valide ou on rejette » C'est un challenge, pas une porte de validation
Pas de trace Décisions orales perdues Livrable post-review obligatoire
Trop de monde 8 personnes en review → personne ne s'engage Cap à 4-5 max, dont 1 reviewer frais

État actuel

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

  • V1 stub créée le 2026-05-29 dans le cadre de l'embarquement composante Design Phase 1.
  • V1 validée le 2026-05-29 avec Rémy (PD) : cadence ad hoc confirmée, participants validés, prep limitée aux sujets significatifs (parcours complet / nouvelle surface).
  • À roder : appliquer sur les prochains sujets à impact UI significatif et itérer.
  • 2026-06-10 : marqueur « à valider Romain » retiré du § Format (format déjà validé V1 par Rémy le 2026-05-29).

Pages liées

Sources